Every leadership book tells you the same thing. Let go. Delegate. Step back.
I bought it for a while. The narrative is seductive. You've earned the title. You've done your time in the codebase. Now your job is strategy, alignment, stakeholder management. Leave the keyboard to the people you hired.
That's how you become useless.
I've watched it happen to engineering leaders across every company I've worked at. They follow the playbook. They stop touching code. They stop reviewing architecture. They attend strategy meetings and produce slide decks and use words like "synergy" without irony.
Then one day they're in a room making a commitment to a VP about a timeline, and they have absolutely no idea whether the thing they're promising is even possible. Because they stopped understanding how the systems work six months ago.
Their team knows. Teams always know.
The Trust Problem Nobody Talks About
Here's what happens when an engineering leader stops being technical.
The first week, nothing changes. You're still operating on recent context. You know the codebase. You know the patterns. You know where the bodies are buried.
By month three, you're relying on secondhand information. Your tech lead tells you the migration will take six weeks. You have no basis to challenge that. Maybe it's right. Maybe it's padded by 3x because the last three estimates got cut in half by leadership and they've learned to play the game. You can't tell the difference anymore.
By month six, your team has stopped bringing you technical problems. Not because the problems went away. Because they've learned you can't help. You'll listen, nod, say something encouraging, and then they'll go solve it themselves anyway. Your one on ones become status updates instead of problem solving sessions.
By year one, you're a project manager with an engineering title.
I've been that person. Not for a year. But long enough to feel the ground shift under me. Long enough to watch an engineer's eyes glaze over when I asked a question that revealed I didn't understand the system anymore.
That look is the most expensive feedback you'll ever get.
The Trap on the Other Side
So you stay technical. You stay in the code. You stay in every decision.
And you create a different disaster.
A senior director of product once told me, "Projects go well when you're involved, Jono. But they don't when you're not."
She meant it as a compliment. I heard it as a system failure.
Because if projects only work when I'm in the room, I'm not a leader. I'm a bottleneck with a title.
I'd built myself into the critical path of everything. Every architecture decision ran through me. Every escalation landed on my desk. Every sprint review needed my context to make sense.
My team wasn't slow. They were waiting. For me.
And I was proud of it. Nobody talks about this part. Being essential feels good. Being the person everyone needs is addictive. You tell yourself it's leadership. It's not. It's a single point of failure wearing a lanyard.
So I started removing myself. First from code reviews. Then from architecture decisions with clear precedent. Then from sprint reviews where the team already knew the answer but wanted permission to say it.
Every time I removed myself, two things happened. First, something went sideways. Not catastrophically. But real. A team chose a caching strategy I wouldn't have chosen. It worked. It just wasn't how I would have done it. And I had to sit with the discomfort of "different" when my instinct was screaming "wrong."
I almost stepped back in. Almost pulled rank. Almost said "let me show you a better way" which is leadership speak for "let me take this back."
I didn't. And three months later that engineer was making architecture decisions across two teams without asking anyone. The space I left didn't stay empty. Someone grew into it.
That's the tension every engineering leader lives in. Stop being technical and you lose credibility. Stay too hands on and you become the constraint. Both sides feel like leadership. Neither one is.
Why Leaders Actually Step Away
Before I tell you what I do now, I want to be honest about something. Because the answer everyone gives for why leaders stop being technical is "I don't have time." And it's almost never true.
The real reason is that it's uncomfortable.
When you were an IC, you were the expert. You knew more about your domain than anyone. That felt good. That was your identity.
As a leader, staying technical means constantly confronting how much you don't know. Your team is deeper in the code than you. They see things you miss. They know patterns you've forgotten. Staying technical means being the person in the room who knows less than everyone else about the specific implementation ... and being okay with that.
That's hard. It's much easier to retreat to strategy and stakeholder management, where nobody can prove you wrong with a stack trace.
I've retreated. More than once. Not consciously. You don't decide to stop being technical. You just stop making time for it. One week you skip the PR reviews because you're in back to back stakeholder meetings. The next week it's easier to skip them again. A month later you couldn't read the code with confidence if you tried.
The drift is silent. The consequences aren't.
The Three Things I Never Stopped Doing
After 15 years of getting this wrong in various ways, I've landed on three practices that keep me technical without making me a bottleneck. The thread that connects all three ... I'm never doing my team's job. I'm building the context I need to do mine.
I read pull requests. Not to approve them. To learn.
I don't review PRs to catch bugs. My team has linters, SonarQube, automated security scans, and code review processes for that. I read PRs to understand how my teams are thinking about problems.
When I see a PR that restructures an API layer, I'm not checking the syntax. I'm asking myself ... does this team understand the downstream impact? Are they thinking about the services that depend on this contract? Is the approach consistent with how the other team on the other side of the world solved a similar problem last month?
That's the context only a leader has. Not the code ... the connections between the code.
I prototype before I promise.
Before I commit a timeline to a VP or a stakeholder, I build a rough version of the hardest part myself. Not production code. Not something that ships. A pressure test.
Can this actually be done in the timeframe I'm about to promise? Where are the hidden complexities that won't show up in a planning meeting but will blow up in week three? What assumptions are we making about the platform that I can verify in two hours instead of discovering are wrong in two sprints?
I never show the prototype to the team. It's not their deliverable. It's my gut check. The goal isn't to prove I can still build. It's to make sure I'm not promising something the system can't deliver.
The gap between what a system can theoretically do and what it can actually do in your specific environment with your specific data and your specific integrations is where timelines go to die. You can't see that gap from a slide deck.
I jump into incidents. Not to fix them. To understand what broke.
Last week a "bug" came in. Instead of shielding my team and deflecting to production support, I dove in. Checked the logs. Found a data issue. Fixed the customer experience in 30 minutes instead of letting it sit in an incident queue for days.
But the fix wasn't the point. The point was that I now understand a failure mode in our system that I wouldn't have known about otherwise. And next time my team proposes an architecture change that touches that area, I'll ask the right question. Not because I read it in a status report. Because I saw it break.
The moment I stop understanding how our systems break, I lose the ability to make good decisions about them.
What Credibility Actually Buys You
Engineers are allergic to authority without competence. They've all worked for the person who stopped coding five years ago and now makes pronouncements about technical direction based on whatever they read on Hacker News that morning.
They'll comply. They won't follow. And there's a canyon between those two things.
Compliance means they do what you asked. Following means they trust your judgment enough to execute when you're not in the room. One scales. The other caps your impact at whatever you can personally oversee.
Every time I ask a question in a PR review that my team didn't consider, every time I catch a risk in an architecture proposal because I actually understand the system, every time I push back on a timeline with specific technical reasoning instead of gut feel ... those moments register. Your team is keeping score whether you know it or not.
And when the moment comes that actually matters ... when you need a team to trust a hard decision, when you need engineers to follow a direction they disagree with, when you need someone to grind through a weekend because the situation genuinely requires it ... that's when you find out if your account has anything in it.
I've worked for leaders who had that credibility and leaders who didn't. The teams are different. The velocity is different. The retention is different. It's not subtle.
The Counterargument (And Why It's a Cop Out)
The pushback I get on this is always the same ... "That doesn't scale."
At Director level, sure, you can read PRs and prototype. But VP? SVP? You're managing managers. You can't possibly stay close to the code.
I think that's a rationalization. And I think the people saying it know it.
The altitude changes. The method doesn't.
At VP level, you're not reading individual PRs. You're reviewing architecture proposals. You're sitting in system design reviews. You're asking "what happens when this fails at 10x our current traffic" and actually understanding the answer.
You're staying close enough to the craft that when a Director tells you something will take six months, you know whether that's an engineering estimate or a political one.
The executives I respect most in this industry never fully disconnected. They read code less frequently, but they never lost the ability to read it. They stopped debugging production issues, but they never stopped understanding how production breaks.
There's a sharper version of this objection that I think about more. It goes like this ... "You're not staying technical for better decisions. You're staying technical because letting go feels like losing your identity. The PR reading and prototyping isn't about your team. It's about you."
I'd be lying if I said that's entirely wrong. There's a part of me that reads code because I miss writing it. There's a comfort in the craft that strategy doesn't provide.
But here's the test I apply ... does this make my team better or does it make me feel better? When I read a PR and it changes nothing about how I lead, I'm indulging. When I read a PR and it shapes a decision I make the next day, I'm doing my job. The line is real. I don't always land on the right side of it. But at least I'm asking the question.
"It doesn't scale" is what people say when staying technical stopped being easy and they'd rather have a reason than a solution.
The Line I Draw
Here's my rule, and it's simple.
If I can't read a pull request on my team's primary codebase and understand what it's doing and why, I've drifted too far. If I can't sketch the architecture of our core systems on a whiteboard without looking anything up, I've drifted too far. If I can't have a technical conversation with my most senior engineer where I hold my own ... not by knowing more, but by asking the questions that matter ... I've drifted too far.
The honest problem with this rule is that the drift I described earlier is invisible from the inside. I said the consequences aren't subtle, but the onset is. So I don't trust myself to catch it alone.
I default to staying in the code rather than waiting for evidence that I've drifted. The cost of reading a PR I didn't need to read is 20 minutes. The cost of discovering I've lost technical context when a critical decision depends on it is immeasurable. The asymmetry makes the choice obvious.
And I pay attention to the signals. When my one on ones start feeling like status reports instead of problem solving sessions, that's a flag. When I catch myself nodding along to a technical explanation I don't fully understand, that's a flag. When I haven't been surprised by something in the codebase in weeks, that's the biggest flag of all ... because it usually means I've stopped looking, not that there's nothing to find.
The best engineering leaders I've known never stopped being engineers. They stopped shipping code and started shipping decisions. But they never lost the ability to understand what ships.
The day you stop building is the day you start guessing.
And your team will know the difference long before you do.