I Stayed in the Sprint Too Long. Here Is the Fix.

Stay close to the craft without being load-bearing

Black-and-white illustration of the same bearded man in a baseball cap shown twice: in the background he strains to maneuver a large angular part into tall industrial framing, while in the foreground a bust of him faces away with a serious, reflective expression; thick white border on black.

Early in leadership, I treated being in the biggest project like proof I was still credible. I wanted the craft. I wanted the team to trust I was not a tourist. Then a senior director of product said something that sounded flattering and was actually a diagnosis ... when I was involved, projects went well. When I was not, they did not.

I took it as a compliment at first. That was ego dressed up as humility.

The real read was simpler. I had become load-bearing in a way that felt like leadership and functioned like risk. If my presence was the difference between success and drift, I had not built enough leverage through other people. I had built dependency with a nicer label on it.

Call it whatever you want in a blog tag, the shape is the same. Decisions run through you. The wins cluster on the work you touch. You read that as proof you add value. It is actually proof the system is fragile, and you are the single point of failure wearing a title.

So I did the harder work. I got out of the sprint as the default owner. I appointed real leads per squad. I operated through them instead of around them. That correction mattered. It also did not mean I stopped being a practitioner.

Writing code was never the hard part for me. Leaving space for other people to carry the hard part ... that was the hard part. I said the rest from the floorboards, not the slide deck.

I keep arguing this in public, and I am not going to soften it for people who want the hard part left off the page.

Leaders should keep a pulse on the craft. Not because every director should ship production code every week like a staff engineer, but because scale without taste turns into mandates you cannot defend. You end up approving work you do not understand. Teams smell that faster than any skip-level survey will ever print out.

The opposite failure mode is what I lived. I stayed so deep in the critical path that I became the safety blanket and the ceiling at the same time. Your engineers feel supported in the moment and underdeveloped across quarters. You feel useful in the moment and exhausted across quarters. That is not Radical Candor cosplay. That is a systems mistake.

Kim Scott helped me because Radical Candor names a trap I actually lived ... being so invested in the relationship that I postponed the hard challenge because I did not want the room to get sharp. It felt kind at the time. It also let problems stay fuzzy longer than they should have. The growth I needed was not switching into jerk mode. It was learning to say the uncomfortable thing precisely enough that someone could act on it the same day ... which turns out to be a different muscle than being good in a crisis thread.

If your involvement is the difference between order and chaos, you are not leading yet. You are still carrying the org on your back.

Where hands-on helps, and where it turns into substitution

I still want leaders touching the real work, with boundaries that protect multiplication.

Hands-on helps when you are going first into something genuinely new ... new tech, new failure modes, new constraints ... and someone has to map the landmines before you ask the team to march. It helps when you are calibrating, not substituting ... checking that estimates, designs, and tradeoffs match reality instead of rewriting other adults' work for sport. It helps when you are modeling standards in review, architecture, and operational discipline so "good" is not a vibe floating in the air.

Hands-on stops helping when it becomes substitution. You turn into the default solver because it is faster today and more expensive every week after. Substitution feels like leadership because it reduces immediate pain. It also teaches the team that escalation is the plan, and that plan collapses fast when more than one lane needs you at once and the clock is not negotiable. You stop looking like a leader and start looking like a router, and your calendar becomes the real system diagram.

That was my loudest mistake for a long time. It is not the only mistake.

When I have drifted too far out

I have also screwed this up the other way. Not as a dramatic resignation story. More like silent drift ... the slow kind where your calendar fills with "important" meetings and your Git history goes quiet and you start nodding along in technical conversations where you used to ask uncomfortable questions.

I track a few signals now because I do not trust my own feelings to warn me early enough. When my 1:1s become status rituals and never reach growth, I am drifting. When I go too long without being surprised by something in the codebase, I am drifting. When I catch myself approving architecture because the room sounds confident instead of because the tradeoffs land in my gut, I am drifting. None of that means I need to become the lead engineer again. It means I am too far out ... and my judgment is about to start running on memory instead of reality.

Guardrails I use on both sides

These are not universal laws. They are what I needed after I paid tuition on both sides of the line ... staying in the sprint too long, and floating above it long enough to lose smell.

When I am too far in, the guardrail is about ownership, not heroics. If I am in execution mode for more than a sprint-shaped window, something is wrong with staffing, ownership, or my own inability to let go. Status and sequencing should not require me in the room. If it does, I fix the lead channel, not the tickets myself. If the team cannot name who owns a domain without me, I have not finished the leadership job.

When I am too far out, the guardrail is about contact, not takeover. I do not sprint myself back into the critical path to prove a point. I do force bounded re-entry ... read pull requests, sit with a lead through one real tradeoff, ask one uncomfortable question in a review I would have skipped. That habit is not nostalgia. It is how I plug judgment back into reality while I am still accountable for outcomes I cannot personally ship.

Those rules sound small. They are the difference between building leaders and building fans.

The payoff nobody warns you about

When I stopped being the human router, projects did not get worse. They got more honest.

Breakage showed up earlier because it was not hidden behind my personal heroics. People grew faster because decisions had to land in the team, not in my head. Politics went down because the shortest path stopped being "get Jono in the thread."

The career side of this shows up when you stop being the person everything routes through. Decisions used to run through me in a way that felt like value and functioned like dependency I had to untrain.

When you build a career map like a contract instead of a pep talk, leveling stops being a surprise. When you ignore how brittle the roadmap is when one person steps away, titles do not save you. And when your strongest IC is quietly carrying the whole failure budget, staying embedded in every thread is how you reward extraction without meaning to.

What I tell managers who are scared to let go

The fear is real. If I step back, quality drops. If I step back, timelines slip. If I step back, people will discover I was never as essential as I told myself. I have heard every version of that fear, mostly from good people.

Here is what I answer now, without pretending fear is irrational.

If quality drops when you step back, you have learned something true about ownership and standards. That is information you can fix with coaching, clearer definitions of done, and review culture that teaches instead of performs. What you cannot fix is a team that only knows how to win with your hands on the keyboard. That is not a team. That is a temporary staffing hack with health insurance.

Timelines slip for two different reasons. Sometimes the schedule was fantasy and your involvement was the compression algorithm hiding reality. Sometimes the team is genuinely learning a new muscle and short-term slip buys long-term capacity. Your job is to know which movie you are in, and not to confuse the two because panic feels like leadership.

And if people discover you were never as essential as you thought ... good. That is called building an organization. Your job was never to be the hero. Your job was to be the multiplier.

The uncomfortable mirror

If you are a director or VP who has not shipped anything meaningful in a quarter but still calls yourself technical because you used to, this paragraph is for you.

Technical is not a tattoo. It is a practice. You do not have to commit every week. You do have to commit often enough that your judgment stays connected to reality, not to memory.

Leadership is not being the strongest engineer in the room. It is building a room where the system survives without you playing every instrument.

What I would do differently if I could mail a letter backward

I would tell younger me that the compliment about involvement was not free. It had a price tag attached in other people's growth and in my own sustainability.

I would still choose the craft. I would just choose it with boundaries earlier, because boundaries are how you love the work without accidentally teaching your team that heroics are the strategy.

If you are in the middle of this now, start smaller than a manifesto. One squad. One real lead. One week where you refuse to be the first resolver. See what breaks. Fix that. Repeat.

The through line is the same ... replacing yourself is not a one-time humility line. It is how the org scales without turning you into the bottleneck that feels good until it does not.