Most engineers who move into management are handed a new title, a new set of problems, and almost no guidance on what the job actually is. The Manager's Path exists to fix that. It is the most practically useful book on engineering leadership ever written - not because it is inspirational, but because it is specific. It maps the full arc from tech lead to CTO, describes what each role actually requires, and names the mistakes people make at each transition.
Camille Fournier spent years as a CTO and engineering leader before writing this book. It shows. Every chapter reads like advice from someone who has been in the role, made the mistakes, and developed genuine conviction about what works. It is not theoretical. It is experiential, structured, and honest.
Most leadership books are written for leaders in general. This one is written for engineering leaders specifically. That distinction matters enormously. The dynamics of managing engineers - the technical credibility required, the tension between hands-on work and management, the particular challenges of hiring and growing technical talent, the way technical decisions and people decisions are intertwined - are not well-served by generic leadership advice.
The Manager's Path treats engineering management as a discipline with its own skills, failure modes, and learning curve. It does not assume you already know how to manage. It does not skip past the difficult transitions. And it covers the full career arc - which means you can use it both as a guide for where you are now and as a map for where you are going.
The engineers who most need this book are the ones who just became tech leads and have not yet worked out that the job has fundamentally changed.
The transition from senior engineer to tech lead is the most underestimated transition in engineering. On paper, the scope of responsibility has expanded. In practice, the nature of the work has changed completely. You are no longer measured purely on what you build. You are measured on what your team builds.
Fournier is direct about what this requires: you have to be willing to be less productive as an individual contributor in order to be more effective as a multiplier. The engineers who struggle most in this transition are the ones who keep trying to do both - who hold on to the best technical work because they are good at it, rather than developing the people around them who need to grow into it.
The tech lead role is not a reward for being a great engineer. It is a different job that requires a different skill set, and the sooner you internalise that, the better.
Fournier dedicates significant attention to 1:1s - not because they are complicated, but because most managers do them badly. The most common mistake: treating the 1:1 as a status update. The manager asks what the engineer is working on, the engineer reports progress, the meeting ends. This is not a 1:1. It is a standup with an audience of one.
A genuine 1:1 is a dedicated, consistent space for the things that do not surface anywhere else: how the person is feeling about their work, what is frustrating them, what they are worried about, what they need to grow. The 1:1 is not for your information - it is for them.
The best 1:1s are driven by the direct report, not the manager. If your team member has nothing to bring, that itself is information worth exploring.
One of the most honest sections of the book covers feedback - specifically the tendency of new managers to avoid it. Positive feedback feels awkward. Corrective feedback feels risky. The result is that most engineers receive far less feedback than they need, and by the time a manager addresses a performance issue it has often been brewing for months.
Fournier's advice is straightforward: make feedback a habit, not an event. Small, timely, specific observations given regularly are far more effective than formal reviews delivered once a year. Praise in the moment reinforces behaviour. Correction in the moment has context. Neither works as well when delivered weeks after the fact.
The managers who avoid feedback are not being kind. They are accumulating a debt they will eventually have to pay - usually at the worst possible time.
The book traces a clear pattern across every leadership level: what made you successful at the previous level will not make you successful at the next one. The brilliant senior engineer who joins a team as a tech lead and continues to individually own the most complex work will struggle. The strong tech lead who becomes an engineering manager and continues to solve technical problems instead of developing people will plateau. The new director who stays in the delivery weeds of one team will fail to see the organisational patterns that are now their responsibility to address.
Each transition is an identity change, not just a scope change. The skills that earned you the role are not the same skills required to excel in it. Recognising this - and actively shedding the previous identity rather than clinging to it - is one of the most difficult and necessary things engineering leaders do.
The final chapters of the book address the shift from managing engineers to managing managers - a transition most leadership books ignore entirely. Fournier is clear that this requires a different model of oversight and accountability. You can no longer see the work directly. You cannot attend every conversation, observe every dynamic, or evaluate every technical decision. You are dependent on your managers to surface the right information, and your job is to create the conditions in which they can do that effectively.
This means your calibration of what is happening shifts. You are reading signals rather than observing directly. You are developing your managers' judgement rather than substituting your own. And you are making more decisions with less certainty - which requires a very different tolerance for ambiguity than most engineers started with.
At your current level, what is the work that only you can do? Now ask: what are you doing that someone on your team could be doing - and would benefit from doing? The gap between those two lists is your development backlog as a manager.
Think about the last piece of corrective feedback you needed to give. How long did you wait before giving it? What were you waiting for? What did that delay cost?
Who on your team has the most potential to grow into a leadership role? What are you actively doing to develop them? If the answer is "not much," what would need to change?
The best test of whether your 1:1s are working: could your team member cancel the next one without feeling like they had lost something important? If yes, the meeting is for you, not them.
How much of your time are you spending on the things your level requires, versus the things your previous level made you comfortable with? Comfort is not a useful signal at leadership transitions.
Audit your last five 1:1s. How much of the talking did you do? How many of the topics were driven by you versus your direct report? What would a meeting look like if you came in with no agenda of your own?
Identify one piece of feedback you have been sitting on. Deliver it this week, specifically and clearly, with enough context that the person understands what changed and what you need to see differently. Notice whether it was as difficult as you had made it in your head.
List the three most important technical decisions your team is working through. For each one, ask: do they need me to make this decision, or do they need me to make space for them to make it well? Push at least one decision fully to the team.
If you are a tech lead, block two hours this week for deliberate people work - a career conversation, a genuine check-in on how someone is feeling about their role, a piece of direct feedback. Not a task, not a project, not code review. People work.
Re-read the chapter relevant to your current level. Fournier's book rewards re-reading at each career stage because what you notice changes as your experience grows. The VP and executive chapters in particular read very differently once you are in the room they describe.
"The best managers I've worked for have all been very good at giving feedback. They didn't let things fester. They were honest without being cruel. And they made me feel like my growth mattered to them personally."
- Camille Fournier