How I Broke My Best Engineer

The fastest way to lose your best engineer is to promote him. I know, because I did it.

Nir was the kind of backend engineer you don't deserve to have on the team. Production would catch fire at 2am and he'd have it out before the rest of us finished reading the alert. We worked offshore for a French company, the kind where Paris made the decisions and the remote team found out afterward. I assume there was a process. I never saw it.

So when Nir was "ready for more," I did the standard thing. I handed him a project. Not the one he wanted, of course - he wanted a meaty streaming pipeline with real depth. I gave him the other one: drag an ancient Spark batch system for Mobile Session Replay into the streaming era, a system no one could quite explain was still running. He wasn't thrilled. I read his lack of enthusiasm as something to coach him through. Mistake number one.

The work was a coordination nightmare wearing an engineering costume. He needed the iOS and Android SDK teams, who treated deadlines as a vibe. He needed three separate backend teams who owned the stack he had to change. And he needed the French teams to talk to him in a language the rest of us could follow, which they experienced as a personal attack.

And Nir delivered. On time. Costs down, stability up, support tickets way down. Genuinely excellent work. He also picked up a new skill along the way: writing Slack messages that are technically polite.

Here's the part I got wrong. While he absorbed all of it - the missed dependencies, the politics, the people who phased in and out of existence like ghosts with calendars - I was on the sideline. Encouraging. "You've got this." What he needed was not a cheerleader. He needed someone standing between him and the organization, taking the hits that weren't his to take. That someone was supposed to be me.

By the end, the project shipped and the engineer didn't. The spark was gone. Tired, flat, unsure of himself. I had taken the most capable person I had and spent him on a migration.

This is not "leadership is hard, be kind to people." Being great at code tells you nothing about whether someone is ready to absorb organizational damage. Different muscle entirely. "Just throw them in the deep end" is advice from people who have never watched a strong swimmer go under.

The bottom line

Promoting your best engineer is not a gift you hand them. It is a risk you take together, and the cover is your job, not theirs. Spot the leadership instinct early, grow it on purpose, and when you finally hand over something hard, stand in the doorway and eat the damage that isn't theirs.

Nir, if you're reading this: you survived my whiteboard diagrams and my Confluence pages, which I'm told are still used to frighten new hires. I owe you. Sorry it took breaking you to teach me the thing.