There is a specific kind of meeting that happens at startups in their awkward teenage years – you know the ones. The company is past “scrappy little team” but nowhere near “we have process for this.” Jobs exist that nobody has been hired to do yet. Problems get solved by whoever is willing to stand in the gap.

This is the meeting where a very talented person gets handed something very large to deal with.

I watched this happen once with a project that had been a long time coming. The company’s infrastructure was straining under its own weight, and without some significant changes to the monolith, we were looking at running out of road on our hosting infrastructure. Not a drill. A real problem with a real deadline attached to it.

A very senior developer was asked to lead it.

This person was exceptional – one of the most technically capable people I’ve ever worked with. If you needed to understand anything about our codebase, they had the map in their head. If you needed to know where the bodies were buried, they knew. There was nobody better suited to understand what needed to happen.

And so, they tried to do all of it.

Every area that needed to change, they were there. Every ticket, every decision, every check-in. They set up & defined the work. They also did a lot of the work. The team around them was full of talented people who were ready to contribute, and instead of distributing ownership across that talent, this person tried to hold the whole thing together through sheer force of presence.

The project was stretching. Progress was murky. The team was capable but directionless, waiting for a person who was too thin to lead and too proud to stop trying. To be clear – this was not arrogance. This person was not on a power trip. They were doing what a decade of being really, really good at something teaches you to do. They were solving the problem the only way they had ever been rewarded for solving problems.

They just had the wrong scoreboard.

At some point, I got pulled in because someone finally noticed that a project this size needed management support, not just technical leadership. Classic startup problem. The job had existed for months before anyone put a name on it.

My job was not to take over, but instead to figure out what was missing. What was missing was not talent or effort. What was missing was a shared understanding of what winning looked like and who owned which part of getting there.

So, we sat down and did something simple. We divided the architecture into areas of ownership. Each person got a piece of the map that was theirs. We talked about what done looked like in each area. We set up clear checkpoints that were about sharing progress and raising concerns, not about reporting status to a single person who was trying to hold everything in their head. Further, we defined the specific gates we’d want to go through to say a phase of the project was done and the sequence those gates needed to be navigated through. And then, it happened. The dev began to truly lead.

Not manage everything. Lead. They got out of the weeds and into the space where their actual value lived: knowing the whole system well enough to see how the pieces connected, catching things before they became problems, making the calls that only they could make. The team got focused. Goals became visible. People were making decisions inside their area without waiting for permission.

I take (almost) no credit for this. The talent was always there – I just helped remove what was in the way of it. What’s interesting to me isn’t the story, itself, but what it reveals about the leadership journey for many of us.

The metric changes

When you are an IC, your value is tangible. You shipped the thing. You fixed the bug. You closed the tickets. The feedback loop is short and the scoreboard is obvious. That clarity is genuinely one of the best things about being really good at an individual craft. You always know where you stand.

The moment you step into any kind of leadership role – staff developer, manager, tech lead, whatever – that scoreboard goes dark.

Your output is no longer what you personally produce. In the book High Output Management, Andy Grove puts it like this: a manager’s output is the output of their organization plus the output of the organizations under their influence. You are now measured by what the team produces, not what you produce. Trying to do everything yourself tends to negatively impact the amount of impact you can actually make in this new world.

But here is what gets people. Nobody hands you a memo about this. You get the new role and you bring the old scoreboard with you, because it is the only one you have ever used. And when things feel uncertain or slow or out of control, you do what you have always done when that feeling shows up. You dig in and do the work yourself. You take everything on, and start to drown.

Which is exactly the wrong move.

The highest leverage version of you is not the one writing the most code or touching every ticket. It is the one who makes it obvious what the most important thing is right now, and then removes whatever is standing between the team and that thing.

That is the whole job.

Not the meetings. Not the status updates. Not the decisions you can make for people. The job is clarity of purpose and just enough structure to let smart people do creative work without burning their energy on coordination overhead. David Marquet calls it “moving authority to the information instead of information to the authority”. The people closest to the problem usually have the best read on how to solve it. Your job is to make sure they know what they are solving for and that nothing is in their way.

When you start filtering your decisions through that lens, you find out pretty quickly that most of what feels urgent is not high leverage. And a lot of what feels like stepping back is actually the most important thing you could be doing.

Letting Go

Letting go is hard.

I mean genuinely, stubbornly hard in a way that does not go away just because you understand the theory. You have spent years building an instinct that says “if something is important, be close to it.” Leadership asks you to rewire that instinct. That takes time and it does not always feel like progress while it is happening. Until you build up a system that makes this possible though, it feels like abdication, and that’s what has always been most challenging for me.

The thing that actually has helped me was learning to “inspect what you expect”. Not hovering, and definitely not checking every ticket. But being deliberate about what the right checkpoints are, what you are actually looking for when you check in, and what signal would tell you something needs your attention versus something is just running the way it should.

The goal is not detachment – instead, it’s replacing your presence with the right process, light enough that it does not become the thing people are doing instead of the work. When you get that balance right, something shifts. It’s not immediately, but the anxiety decreases. People start surprising you. The project starts moving in ways that do not depend on you being in every room.

That senior dev figured this out. Took some time. Was not comfortable for either of us. But once they found the version of leadership that fit what they actually were, which was one of the most technically capable people in the room, they were genuinely hard to stop. Once they understood how to keep score in this new role, we were able to get things on track.

Not right away. But eventually.