Hierarchies, bottlenecks, and high-leverage time💡

Monday Ideas — Edition #111

🎟️ WeAreDevelopers 2024 — get 25% off!

This year we are proud to partner with the WeAreDevelopers World Congress, which will be held in Berlin from July 17th to 19th, 2024.

The conference will unite 15,000 developers, decision-makers, and experts for discussions on software trends, with 500+ speakers.

Notable speakers include:

• Prashanth Chandrasekar • CEO of Stack Overflow,

• Thomas Dohmke • CEO of GitHub,

• David Heinemeier Hansson • Creator of Ruby on Rails,

• Denis Yarats, Co-founder and CTO of Perplexity.

As a Refactoring reader, you get 25% off 🎁 the full ticket price by using the link below:

Back to this week’s ideas! 👇

---

1) 🏗️ Hierarchy can actually help communication

As long as your team is small, there isn’t much need for a formal organization — 5 to 10 people can work pretty well without much structure.

The main problem, when teams grow larger, is communication. Large teams have a hard time doing things like:

• Keeping people on the same page

• Coordinating and allocating resources

• Making good, participated decisions

When you grow your team from 5 people to, say, 15 or 20, it seems that these problems get worse — at first gradually, and then suddenly.

But why?

As by Metcalfe’s Law, the complexity of communication is proportional to the square of the number of users involved. So, while people grow linearly, complexity grows geometrically 👇

To tame communication complexity, companies usually introduce hierarchies. Hierarchies have several advantages:

• They provide clear communication paths, ensuring alignment is obtained across the organization.

• They reduce the number of lines each person has to manage, allowing the company to scale.

• They provide a simple way for making decisions, by assigning responsibility to people up in the hierarchy.

Same 7 people, different configurations

However, they also bring drawbacks:

• Overhead — communication has a longer way to travel to a destination, which makes you slower. Longer paths also create all kinds of “work’s work”, like traffic control, managing up, presentations, and more.

• Inflexibility — once in place, it is hard to reconfigure roles and processes. This in turn reduces agility, resilience to turnover, and velocity, too.

There exist companies who have successfully scaled without introducing hierarchies.

I wrote a two-part series about them 👇

Unconventional Team Structures (Part 1) 🏰

---

2) 🛑 Hire because of bottlenecks

When it comes to hiring, I tend to be extremely conservative.

So, I believe you should mostly hire because of bottlenecks, rather than opportunities.

Just like with funding—you should only raise money when you know exactly how you would spend it—you should only hire people when you are clearly bottlenecked on something, rather than to chase new things.

For example, let’s say your product relies on integrations with external APIs, and the more integrations you build the more customers your sales people are going to win. It is a proven process where higher development velocity brings more business, so you may go for it with confidence.

Now, let’s make a different example — your product relies on sales and word of mouth, and you think you should now invest in SEO because it looks promising: decent volume and low-competition.

This is not a bottleneck, this is a new opportunity that may or may not play out the way you think. My preferred way of chasing it would probably be:

• Learn the basic skills yourself (your existing team).

• Prototype the work and get some initial results.

• Get to the point where the opportunity turns into a bottleneck — that is, you validate the value that would be brought by a specialist.

• Hire a specialist to do 10x better work.

You may also work with an agency / consultants in the initial stages to bring in expertise while keeping risk low.

Overall your final decision on hiring somebody should be a double no-brainer:

• Position — no-brainer to hire for that position.

• Candidate — no-brainer to hire that candidate for that position.

I wrote a full guide about the signs (and anti-signs) that you should hire engineers and/or managers 👇

When Should You Hire? 🤔

---

3) ⏱️ High-leverage time management

We often talk about what you should spend your time on, and much less about how.

I have found that the best teams are intentional, at a company level, about how people spend their time, and apply what I call high-leverage time management.

Here is what you should pay attention to:

Minimize waiting ✋

Minimize the time people spend waiting for others to do stuff.

1. More waiting leads to more context switch — people move to other tasks in the meantime

2. More context switch leads to more work in progress — which is detrimental to quality, productivity, and morale.

But why do people wait for others in the first place? In my experience, it’s mostly two things:

• 🤝 Collaboration — things that need contribution from multiple people, like a design doc.

• 🏅 Approvals — things that need to be reviewed and signed off by somebody, like a PR.

To reduce waiting you can try two things:

• Make high-bandwidth activities sync — for creative tasks that require a lot of back and forth, consider doing them synchronously in a meeting, instead of passing them around on Slack or a doc. E.g. create that design doc all together with your team, or do pair programming on that thorny issue.

• Switch from an approval workflow, to a revert one — default to trusting your co-workers to go ahead with their decisions, and reviewing only after the fact, not to block them. This does wonders for both productivity and accountability.

Meetings are short & few 💬

Meetings are the easy default to get things done, but easily turn into a low-leverage way of spending your time.

I have written about meetings many times, including a full guide about how to reduce them:

How to Reduce Meetings 🪚

A good rule of thumb for when to use a meeting is to follow the ☕ CUP Rule. Use meetings when the matter is:

• Complex — we need to brainstorm and figure this out together.

• Personal — improve bonding, 1:1s

• Urgent — there is an incident happening right now

The truth is very few things happen regularly that meet any of these criteria. So, be especially suspicious of recurring meetings.

You apply continuous delegation 🔀

An investor once told me that as a founder I had to continuously replace myself.

Once I understood how to do something, my job was to delegate or automate such work.

I have found this to be a good mindset for everybody, not just founders. You can ask yourself continuously:

1. Can I remove this? — Is this really needed? You would be surprised by how much work can be safely removed and not be replaced by anything. This should always be the first option.

2. Can I automate this? — Automate aggressively any manual work that is not high-leverage. These days, you have plenty of ways to do so: chatOps, internal tools, AI, and workflows are easy to build even without code.

3. Can I delegate this? — Are you the best person to do this? Sometimes, what looks like a chore for you, is an opportunity for a younger co-worker to prove themselves.

Also, order matters. No work that can be removed should be automated, and no work that can be automated should be delegated.

High-leverage time management was part of a wider checklist I wrote for startup teams. You can find it below 👇

The Startup Healthcheck 🩺

---

And that’s it for today! If you are finding this newsletter valuable, consider doing any of these:

1) 🔒 Subscribe to the paid version — if you aren’t already, consider becoming a paid subscriber. 1500+ engineers and managers have joined already! Learn more about the benefits of the paid plan here.

2) 🍻 Read with your friends — Refactoring lives thanks to word of mouth. Share the article with your with someone who would like it, and get a free membership through the new referral program.

I wish you a great week! ☀️

Luca