Look at the three people we've followed through this series.
Marc, who opens every 1-1 with "how's the sprint going?" — not because he doesn't care about his engineers, but because the sprint is concrete and the person is harder to navigate, and nobody ever told him the 1-1 wasn't a project sync.
Camille, who reviews every PR within the hour, who has the best technical answer in every room she's in, whose team ships consistently — and who is only now, sitting with a question asked over a drink in Lyon, beginning to notice that two of her engineers have quietly stopped thinking for themselves.
Dimitri, who typed his real questions into a notes app and deleted them on the way back to his desk — not because he's passive, but because he'd already learned, through accumulated experience, that the all-hands wasn't a place where real questions got real answers.
None of these situations involve bad people. None of them involve malice or laziness or indifference. What they share is an incomplete picture of what engineering leadership is actually for.
The incomplete picture looks like this: the job is to keep things moving. Ship the sprint. Review the code. Run the meetings. Handle the escalations. Keep the team productive and the stakeholders informed.
That's not wrong — those things matter. But they're the surface of the job, not the substance of it. And when the surface becomes the whole picture, something quietly goes wrong. Engineers stop growing. Teams become execution machines rather than thinking systems. People leave, and the exit interview reveals things that were visible for months to anyone who'd been paying attention — which nobody was, because everyone was watching the sprint.
The substance of the job is this: you are responsible for the conditions in which your engineers do their best work and become more capable over time.
That's it. Everything else is in service of that.
Conditions means a lot of things in practice.
It means that your engineers understand the context they're operating in — why the current priorities are what they are, where the company is in its story, what's changing and what isn't. They can't make good decisions in a vacuum, and a surprising amount of engineering management is just closing information gaps that leadership doesn't realize exist.
It means that the friction in the system — the unclear ownership, the recurring incident nobody has fixed, the collaboration that keeps breaking down between two teams — gets named and addressed rather than worked around. Engineers are remarkably good at adapting to friction. They'll find a way. But adaptation has a cost, and over time that cost accumulates in morale, in workarounds, in the quiet conviction that leadership doesn't actually see what's hard about the work.
It means that each person on your team has a trajectory — not a performance rating, a trajectory. Where they are now, where they want to go, what the next six to twelve months could look like if you're both paying attention. That trajectory doesn't manage itself. Someone has to hold it, ask about it, create the conditions for it to move. That someone is you.
And it means, maybe most importantly, that you are developing the judgment of the people around you rather than substituting your own judgment for theirs. The PR you review but let through because the growth is worth the imperfection. The technical discussion where you wait — uncomfortably, for longer than feels natural — because Ann is almost there and getting there herself will matter more than arriving faster. The 1-1 where you ask where Bob wants to be in a year and actually listen to the answer.
None of this is soft. It's some of the hardest work in a company, and it's largely invisible until it's absent.
When it's absent, you feel it in the signals that are easy to dismiss individually: the engineer who's gotten quieter in meetings, the retention problem that appears suddenly and wasn't sudden, the team that ships but never proposes anything, the town hall where nobody asks the real questions. Each of these is a readout of conditions. Each of them was visible earlier, to someone who was looking.
The shift from engineer to engineering manager — or from manager to leader — is not primarily a skill acquisition. You don't need to learn a new technical domain. What you need is a different relationship to your own usefulness. The thing that made you excellent before — being the person with the best answer, the clearest diagnosis, the fastest path through a hard problem — is now only part of the job, and possibly the smaller part. The larger part is making sure the people around you are developing those same capabilities, and that they have the context, the space, and the conditions to use them.
Marc is learning what a 1-1 is actually for. Camille is sitting with a question that's slowly reorienting how she runs her team. The company that gave Dimitri forty-three slides might not figure it out in time.
The difference between them isn't talent or intention. It's whether anyone gave them an honest picture of what the job was before they had to learn it the slow way.
That's what this series has been about. Not a critique of the people in these roles — most of them are doing their best with the picture they were given. A better picture. One that starts with the people, not the output. One that treats the conditions you create as the work, not the byproduct of it.
The sprint will always be there. The person in the room won't wait.
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.