Growing ownership without becoming the bottleneck

A team can be capable, busy, and still slow, because too many meaningful decisions pass through one person. Usually that person is the lead, and usually nobody designed it that way. It accumulates: a question goes up once, the answer comes back quickly, and asking becomes the habit.

From the outside, the lead looks indispensable and the team looks like it needs more oversight. Both readings are wrong: the constraint is the lead. The fix is to change where decisions get made, not to add process around them. This is the operating model I use to keep that from happening, and to undo it when I inherit it.

1. 01Delegate decisions, not only tasks

   Handing someone work isn’t the same as handing them ownership. A task says what to build. Ownership includes deciding how, judging when it’s good enough, and choosing what to do when the plan stops matching reality.

   That takes four things: the context behind the work, the authority to make calls within it, the boundaries of that authority, and a shared picture of what a good outcome looks like. Leave one out, and decisions drift back to the lead.

2. 02Protect engineering focus

   Status doesn’t automatically need a meeting. Progress, plans, and blockers travel well in writing, and a written update is still there for whoever missed it.

   Time together is expensive, so I keep it for what needs people in the same conversation: decisions, design, collaboration, difficult problems, and real blockers. If a meeting ends without a decision made, a design moved forward, or a problem solved, it probably didn’t need everyone in it.

3. 03Stay technically close without taking over

   I stay close enough to the work to review architecture, understand implementation constraints, help debug difficult problems, challenge assumptions, and reason through tradeoffs with the people making them.

   The line I watch is ownership. Reviewing a design is different from rewriting it, and pairing on a hard bug is different from taking the ticket. If I solve every hard problem myself, the team learns that hard problems belong to me.

4. 04Make escalation boundaries clear

   Autonomy without boundaries feels risky to everyone, so people check in by default. I’d rather draw the lines in advance, so engineers know:

   • What they own
   • What they can decide on their own and share afterwards
   • What needs alignment with other owners first
   • When a risk needs to reach me, and how early

   Clear lines make escalation cheaper, not rarer. When people know exactly what to bring up, they bring it up sooner — and everything else stops waiting for approval.

5. 05Grow future leaders

   Leadership should increase the number of people who can own broader outcomes: a service, a release, a cross-team dependency, a technical direction. Delivering the current project matters. So does finishing it with more people ready to lead the next one.

   In practice, that means giving people decisions a little larger than the last ones they made, staying available while they make them, and letting the result be theirs.

6. 06Avoid lead dependency

   The honest test is what happens when I’m not there. If decisions queue, releases wait, or every difficult call still needs me, the team hasn’t become more capable. It has become dependent on one person — a risk for the team, and a sign that my own time is going to the wrong things.

The goal of leadership is not to make yourself indispensable. It is to make good decisions possible without you in the room.