Camille was, by any measure, an excellent engineer. Five years at the same company, respected by everyone who worked with her, the person you wanted on the hard problems. When the engineering manager role opened up, the decision felt obvious to everyone — including Camille.
That was fourteen months ago.
Her team of five ships consistently. PRs get reviewed thoroughly — by Camille, usually within the hour. The codebase is in better shape than it's ever been. On paper, things look fine.
What Camille doesn't see yet is that two of her five engineers have quietly stopped proposing solutions in technical discussions. They've learned that Camille will get there first, and that her answer will be better, and that the fastest path through any technical conversation is to let her lead it. They're not disengaged — they still care. But they've started to shrink.
Camille doesn't know this because she hasn't built the map yet. She's running 1-1s, but they're mostly technical — code quality, architecture decisions, what's coming up in the sprint. She means well. She's just doing the only job she's ever been taught to do well.
The promoted-engineer failure mode is the most common in engineering management, and the least discussed, because it doesn't look like failure from the outside. The team ships. The technical quality is high. The manager is visibly competent and clearly cares. There's nothing obviously broken.
What's broken is underneath: the engineers on the team are being managed as if they were the manager's hands rather than their own minds. Their growth is stalled. Their judgment isn't being developed because it isn't being asked for. And the manager, who is doing all the technical heavy lifting, is too busy to notice that she's doing the job of five people while nominally having a team.
The transition from senior engineer to engineering manager is one of the most under-supported in the industry. There's usually a conversation with a VP or founder — we'd love for you to take on the team — and then the calendar changes, the title changes, and not much else does. Nobody explains that the job is now fundamentally different. That the output is no longer code but people and conditions. That the pull request you should be reviewing most carefully is the one that lets someone else grow, even if it's slower and messier than doing it yourself.
So you default to what you know. The technical work feels solid under your feet. The human work — the career conversations, the noticing when someone is quietly shrinking, the decision to hold back your answer so someone else can find theirs — that work feels uncertain, occasionally awkward, and very hard to measure.
Camille ran into a former CTO at a conference in Lyon, someone she'd worked under briefly early in her career. They found themselves at the same table after the afternoon sessions, and she mentioned, almost in passing, that she'd moved into management.
He asked one question: "What are your engineers getting better at?"
She started to answer — deployment pipeline, the new observability setup, the refactor they'd just shipped — and stopped herself halfway through. She'd described what the team had done. She hadn't described what anyone had learned, or stretched toward, or taken ownership of that they hadn't owned before.
He didn't press it. They talked about other things. But she sat with the question on the train back.
What are her engineers getting better at — because of how she manages them, not despite it?
The shift Camille is beginning to make isn't about doing less. It's about doing differently. Holding back the answer in a technical discussion long enough for Ann to find her own. Asking Bob in a 1-1 what he wants to be able to do in a year that he can't do today. Letting a PR go through with a suboptimal approach and using the review as a teaching moment rather than a correction.
None of this comes naturally after five years of being rewarded for having the best answer fastest. It requires a kind of deliberate restraint that can feel, at first, like underperforming.
It isn't. It's the job — just not the one she was doing before.
The former CTO's question wasn't a critique. He probably didn't know it would land the way it did. But it named the gap between managing engineers and developing them, in five words, over a drink, in a conference hall in Lyon.
Camille has been sitting with it ever since.
Thomas Riboulet is a Fractional VP of Engineering working with European tech companies. He writes about engineering leadership, team structure, and sustainable delivery at insights.wa-systems.eu.