How I Broke My Best Engineer
I gave my best engineer the promotion's workload without the promotion, then cheered from the sideline while the organization ate him. The project shipped. The engineer didn't. The lesson has a name: cover, not cheerleading.
The fastest way to lose your best engineer is to promote him. I know, because I did something worse. I gave mine the promotion's workload without the promotion. No title. No authority. No cover. Just the work.
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 the fix out before the rest of us finished reading the alert. Not once. As a habit.
We were the offshore team of a French company. Paris made the decisions. The remote team found out afterward. I assume there was a process. I never saw it.
Everything that follows happened inside that physics. It's the same world I wrote about in one company, many cultures.
The project he didn't want
Nir was ready for more. Everyone saw it. So I did the standard thing. I handed him a project.
Not the one he wanted. He wanted the meaty streaming pipeline, the one 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 nobody 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 signal said "this project is wrong for me." I heard "this engineer needs a pep talk." He went quiet. I filed it under attitude.
A coordination nightmare in an engineering costume
On paper, a migration. In practice, the code was the smallest load on the truck.
He needed the iOS and Android SDK teams, whose deadlines kept slipping. He needed three separate backend teams who owned the stack he had to change. And he needed the French teams to communicate in a language the rest of us could follow. They resisted that.
Count the surfaces. Five teams before you reach Paris. Zero authority.
Nir held the accountability of a lead with the standing of an IC. Every dependency conversation ran uphill. And with no mandate, every hit lands twice: once as the problem, once as evidence you can't handle the role you don't officially have.
He delivered. I didn't.
Nir delivered. On time. Costs down, stability up, support tickets way down.
I don't have the exact numbers anymore. I have the silence from the support channel.
He also picked up a new skill along the way: writing Slack messages that stayed polite.
He absorbed all of it. The missed dependencies. The politics. The people who phased in and out of existence like ghosts with calendars.
And where was I? On the sideline. Encouraging. "You've got this." Mistake number two.
What he needed was a body between him and the organization, taking the hits that weren't his to take. That job has a name on the org chart. It was mine.
Cover, not cheerleading
The lesson has a name: cover, not cheerleading.
A stretch assignment splits into two loads.
The engineering load: design, code, tradeoffs, the 2am fires. That one was his, and he carried it brilliantly.
The organizational load: slipped commitments, turf, escalations, ghosts. That one was mine. I outsourced it to him with a smile and called it growth.
Week to week, cover looks like this:
- An SDK team misses a date? He reports the slip. I make it expensive. The chase is mine.
- A backend team stalls on a stack they own? My meeting, my chips. He should not spend credibility he hasn't been issued yet.
- A stakeholder phases out of existence mid-dependency? I find the missing stakeholder. He keeps building.
- Paris moves the ground under the project? I catch the decision before it reaches him. Or at least stand next to him when it lands.
- And one standing question in every 1:1: "Which hit landed on you this week that should have landed on me?"
This is the boring part of the job: I spend my standing so he doesn't have to spend his.
Cheerleading costs nothing and transfers nothing. Cover costs meetings, favors, political capital.
The bill
The project shipped. The engineer didn't.
The 2am fixes stopped. He started double-checking things he used to just do. 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. "Just throw them in the deep end" is advice from people who have never watched a strong swimmer go under.
Stand in the doorway
Spot the leadership instinct early. Grow it on purpose, before the hard project shows up.
I wrote a whole post on preparing a lead before the job breaks them; this one is what happens when you skip that chapter.
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.