I was the best coder on my team. Bugs nobody else found, I found in twenty minutes. Features nobody else shipped on time, I shipped early. So when the company needed a lead, my name came up first.
I said yes before I understood the question being asked.

The Job I Was Good At
For years, my value was easy to measure. Lines shipped. Bugs fixed. Systems built. I sat down, solved a problem, and by the end of the day I had proof I'd done good work: a pull request, a merged branch, a feature running in production.
The promotion took all of it away and handed me nothing to replace it with. My calendar filled with meetings. My inbox filled with questions I didn't always have answers for. At the end of my first week as a lead, I hadn't written a single line of code, and I felt like a fraud sitting in someone else's chair.
So I did what any strong engineer does when the requirements aren't clear: I fell back on what I already knew how to do. I kept coding. Late at night, after the team had logged off, I'd quietly fix the bug someone had been stuck on all day, then merge it before morning stand-up. I told myself I was helping.
I was not helping. I was competing with the same people I was supposed to be developing, and I was winning every time.
The Day It Turned
The shift happened in a one-on-one. A developer on my team walked me through a design problem she'd been wrestling with for two days. I saw the fix immediately. I wanted to grab her keyboard and show her. Instead, I asked a question. Then another. She got there herself, twenty minutes later, and the look on her face was worth more than any pull request I'd ever merged.
Here's the part nobody warns you about: it didn't feel like a win. It felt like I'd done nothing. No commit, no proof, no dopamine hit from watching tests go green. I walked out of the room unsure whether I'd led the meeting or simply sat through it.
It took months before I trusted the pattern. The teams where I stopped fixing things myself started fixing more things, faster, without me. The teams where I kept swooping in to save the day stayed dependent on me swooping in. Every rescue I performed was a lesson in helplessness for the person I'd rescued.
Laurence Peter named this pattern decades ago: organizations promote people until they land in a role they're bad at, then leave them there because the promotion itself was the reward for the last job. Engineering has its own brutal version of it. The Peter Principle shows up constantly in software teams, and the fix isn't "try harder at management." It's recognizing the skill which got you promoted has almost nothing to do with the skill the new job needs.

Letting Go Is Not the Same as Giving Up
I want to be precise here, because this gets misread constantly. Letting go of the keyboard doesn't mean losing your technical judgment. It means changing what you do with it.
Before, I used my technical judgment to produce code. After, I used it to ask better questions, to spot the design flaw three steps before it became a production incident, to know which battles were worth fighting in a review and which ones were ego. The judgment stayed. The output changed shape entirely.
I built a short list of rules for myself during my first year as a lead, and I still follow most of them:
- If someone on my team is able to solve it without me, I don't touch it, even when I'm faster.
- If I catch myself opening a pull request simply to "fix it quickly," I close the tab and ask why they're stuck instead.
- I measure my week by what my team shipped, not by what I shipped.
- I write down the questions I ask in one-on-ones. If I'm not asking any, I'm not leading, I'm managing a to-do list.
None of these came naturally. Every one of them fought against a decade of identity built around being the person who solves the hard problem fastest.
The payoff showed up slowly, then all at once. Six months in, my strongest engineer solved an outage at 2am without paging me. A year in, two people on my team were mentoring newer hires the same way I'd been trying to mentor them, asking questions instead of grabbing keyboards. The habit had spread past me, which is the entire point of leading a team instead of carrying one.
What Nobody Tells You About the Trade
Here's the uncomfortable math. The better you were at the job you're leaving, the harder this trade is. Weak engineers make the jump to leadership almost gladly, because there's less identity wrapped up in the switch. The strongest engineers resist it the longest, because the switch feels like a demotion in the currency which made them who they are.
I wrote about the structural side of this problem in Your Best Engineer Is Not Your Next Manager, where the numbers back this up. Roughly one in ten people naturally have the skills to manage others well, and organizations get the promotion decision wrong the majority of the time. This earlier piece is about the org chart. This one is about the mirror.
If you're reading this as someone who recently got the promotion, the numbers won't save you. Only the daily discipline of stepping back will. My own survey work found 99.5% of people have worked for at least one bad boss in their career, and I promise you, at some point in year one, you will be a candidate for the list. The developer whose keyboard you almost grabbed will remember whether you grabbed it.

The Question I Ask Now
These days, when I sit down with a struggling engineer, I ask myself one question before I open my mouth: am I here to solve this, or to help them solve it? Only one of those answers builds a team which doesn't need me in the room.
I still miss the clean, simple proof of a merged pull request some days. There's nothing quite like watching your own code run clean in production. But I've traded it for a slower, quieter feeling: watching someone I once had to guide through every decision now make the harder call without me, correctly, and never knowing I almost took the choice away from them.
If you're standing at the same fork in the road right now, keyboard in one hand and a struggling teammate in front of you, here's my honest advice: put the keyboard down. The work you built your name on was never the point. The people you build up become it.
Which one are you optimizing for this week, your output or theirs?