Leadership progressionManagement craftScaling organizations
The Manager’s Path
A Guide for Tech Leaders Navigating Growth and Change
Camille Fournier
Every rung is a new job. Prepare for the next one before you stand on it, and let go of what got you here.
Overview
My interpretation
Why it's on my shelf
Every step of my career, from enterprise engineer to manager of managers to founder, has been a different job that looked like a promotion of the last one. Fournier is the only author who maps that ladder honestly, rung by rung, for technical people.
Book's argument
What this book is about
Technical leadership is a ladder of distinct jobs: being managed, mentoring, tech lead, managing people, managing teams, managing managers and senior leadership. Each level asks a leader to let go of some of what made them successful at the last one and build new skills, so knowing what the next level demands is the best preparation for it.
Book's argument
The ladder, rung by rung
- 1Being managedOwn your career and bring the agenda; getting the most from your manager is the first leadership skill.
- 2MentoringHelping one person grow is the first time your success depends on someone else’s.
- 3Tech leadBalance hands-on work with coordinating the project and representing the team.
- 4Managing peopleOne-to-ones, feedback and careers become the job.
- 5Managing a teamProcess, delivery and team health, while staying technical enough to judge the work.
- 6Managing multiple teamsYou lose direct visibility and have to manage through priorities and leads.
- 7Managing managersYou diagnose teams through their leaders and skip-levels, not through the code.
- 8The big leaguesSenior leadership: technical strategy, alignment with the business, shaping the organization.
Key Ideas
Key ideas
Book's argument
01Learn to be managed
Getting the most from your own manager, by owning your career and bringing the agenda to one-to-ones, is the first leadership skill.
Caveat It assumes a manager who is willing to engage; with an absent manager, people have to look for mentorship elsewhere.
Book's argument
02Tech lead is its own role
A tech lead balances hands-on work with coordinating the project and representing the team, and has to accept writing less code.
Caveat How much coding a tech lead keeps varies widely between companies.
Book's argument
03Managing managers changes how you see
Once you manage managers you lose direct visibility, so you rely on skip-level conversations and on diagnosing teams through their leaders.
Caveat Skip-levels can undermine a manager if they turn into a back channel.
Book's argument
04Senior leadership sets direction
At the executive level the job becomes setting technical strategy, aligning with the business and shaping the organization.
Caveat Titles such as CTO and VP of Engineering mean different things at different companies.
Book's argument
05Culture is built on purpose
As a team grows, its culture should be shaped deliberately, by writing down values and building processes that reflect them.
Caveat Written values that do not match how decisions are actually made can do more harm than none.
My Notes
My application
How I apply it
- When someone joins my team, I ask them which rung they are aiming for, then give them work from the rung above, with cover.
- As a manager of managers, I run skip-levels on a schedule, not when something is on fire, so I hear about problems before they become escalations.
- As a founder and fractional CTO, I use the “big leagues” chapters as a checklist: am I setting technical strategy, or just being the most senior engineer in the room?
- I write culture down early. My agent fleet has a public operating manual for the same reason a growing team needs written values: what isn’t written gets reinvented badly.
My interpretation
Where I agree
The core insight, that each level asks you to let go of what made you good at the last, is true and under-taught. The tech lead chapter is the best description I know of the most misunderstood role in engineering.
My critique
Where I push back
It is written from inside fast-growing startups in one city and one era, and the later chapters on executives are thinner than the early ones. It assumes a single ladder, when many great engineers should never take it, and it says little about leading in very large companies or through the arrival of AI agents as teammates, which is changing what a tech lead and a team even are.
My interpretation
My reflections
Each rung is a different job
Every promotion I’ve had looked like more of the same job and turned out to be a new one. The skill that got me promoted was usually the one I had to put down first.
Takeaways
My interpretation
Takeaways
- Each rung is a new job; prepare for the next one before you’re on it.
- Letting go of your old strengths is part of the climb.
- The tech lead role is its own discipline, not a halfway house.
- Manage managers through skip-levels and written expectations.
My application
Questions for your team
- What is each person on the team trying to become next, and do they know what that rung actually asks of them?
- Which of my old skills am I still using because it feels good, not because the job needs it?
- How do I find out about problems on teams I don’t manage directly?
- Is our culture written down anywhere a new hire could read it on day one?
- Who on the team is ready to be a tech lead, and who is being pushed there because they code fastest?
My interpretation
Read it with
Read it with Become an Effective Software Engineering Manager for the daily craft, and An Elegant Puzzle for the organization around you as you climb.
My critique
Who should skip it
Senior executives will find the last chapters light. And it misleads anyone who reads the ladder as the only way up: a staff engineer’s path is a different book.
Drafted with AI assistance from the book and its published material, edited and published by me. Nothing here quotes the book at length; get the book itself for the real thing. Cover image: Open Library. Ads & privacy.


