What Helicopter Leadership Costs You

Most engineering managers have seen the pattern. You start reviewing code and commenting on every issue, then move on to second-guessing design decisions. Before long you are the bottleneck for the whole team, and your teammates are frustrated with you. It is easy to convince yourself you are just keeping quality high, but the real effect is a team that never gets a chance to own its work.

A team of strong engineers will outgrow you. If you are involved in every minor decision, the team ends up under-utilized. You want engineers, not code-monkeys, so give them room to do their job. The best way people learn and grow is through ownership, mistakes, and the lessons that follow. That is far more valuable than anything they will read in a blog post.

There is also a selfish reason to let go. If you spend all your time on day-to-day decisions, you have no time left for longer-term strategy. And nobody else is going to handle that for you.

Autonomy Needs Standards

This is not permission to let your team break things casually. The point of allowing "papercuts" is to produce a net benefit to the company. People need autonomy to reach their full potential, and they need organizational air-cover while they make small mistakes. But nobody learns anything without accountability for quality and execution. Autonomy has to go hand in hand with setting expectations, agreeing on completion dates, and reviewing whether work actually succeeded.

You do not have to fake agreement with your team. Some of the most motivating phrases you can say to an engineer are:

I don't know if I agree with you, but this decision is on you. You can do this. Roll with it, but this is what I expect...
Let me know if you need any input but otherwise I'm going to stay out of this one. You know what we need and when we need it by. You're in charge here.

Engineering productivity is critically tied to motivation. Autonomy coupled with high standards is a huge motivator for talented engineers.

Type 1 Versus Type 2 Decisions

The hard part is deciding which decisions are safe to delegate. Give your team autonomy and a disaster happens? That is your fault. You are accountable for direction and execution, and you cannot just take your hands off the wheel.

The middle ground between micromanagement and chaos requires sorting decisions into two buckets. Jeff Bezos calls them Type 1 and Type 2 decisions. Type 1 decisions are big, hard to reverse, and carry serious consequences for getting them wrong. Type 2 decisions are not such a big deal; you can back out or change course later. You need to be on top of Type 1 decisions, but do not obsess over Type 2.

There is no easy checklist for which is which, but in software engineering these tend to be Type 1:

  • External APIs, at least the major details.
  • Distributed systems protocols.
  • Standards for correctness, validation, and reliability.
  • Security decisions.
  • Whether to devote major resources to a project, such as a system rewrite.
  • Long-term team strategy.

Everything else is probably fine as long as a smart person is held to high standards. Want to swap an internal library for another? Go for it.

Senior engineers in a design review should consider telling people a decision is Type 2 instead of being heavy-handed. Junior engineers looking for feedback should first ask whether the decision is Type 1 or Type 2. If you just ask for design feedback, you will get it whether you want it or not.

You Are Probably Wrong Sometimes

Giving people room to make papercuts often reveals that they were not papercuts at all. Your engineers likely know more about their part of the stack than you do, and they have probably thought about a decision more than you have. They may lack experience, but often they will prove you wrong.

Usually the outcome is that the decision did not matter much anyway. Or you wasted some time, but the engineer worked much harder because they had ownership. Focus on the medium-term output of the team, not the short-term. Being proven wrong is a way to achieve more collectively than you could alone.

Start with People Who Are Ready

None of this means throwing everyone in at the deep end. Junior team members will need hand-holding even with Type 2 decisions. You still have a responsibility to give advice and guidance on issues large and small. If team members are feeling overwhelmed, you have gone too far. Do not throw your intern to the sharks.

Give your team autonomy for decision-making and let them accumulate some papercuts, but keep the bar high. Exercise judgment about which decisions are critical and which are reversible. Teams grow faster and are more productive when people are given ownership and accountability. And if you waste a little time now and then? Step it up next time.