The Manager's Path – Summary With Notes and Highlights

In my notes on Staff Engineer, I wrote that I read two books back to back to decide which direction to grow in: the technical track or the management track. Staff Engineer talked me out of the first one. The Manager's Path by Camille Fournier is the book that convinced me about the second, and this post explains why.

Where Staff Engineer is a map of one destination, The Manager's Path is a map of the whole ladder: mentor, tech lead, manager of people, manager of a team, manager of managers, and finally the executive floor. Fournier spent years as a CTO, and it shows. The book is short on theory and long on "here is what this job actually feels like."

I read it right after Staff Engineer, because I wanted my answer while the question was still fresh. My usual method: I listen to the audiobook while following along and highlighting in the paper copy. The combination keeps my focus high and helps me understand faster, and when I think a book could be useful to other people, I sit down afterwards and write a summary like this one.

1. Management in tech is not one job but a ladder of very different jobs, and each rung requires dropping habits that made you good at the previous one.
2. The core skills are unglamorous and learnable: consistent 1-1s, honest continuous feedback, real delegation, and debugging teams the way you'd debug a system.
3. Engineering managers can't coast on authority; they earn trust through technical credibility and lose it the moment they stop understanding the work.

This book is organised exactly like a career ladder: each chapter is one rung, starting from "how to be managed" and ending at CTO. That structure is its biggest strength, because you can read the chapter for the rung you're on plus the one above it, and the book has already paid for itself.

Fournier is refreshingly unsentimental. She doesn't sell management as a reward for good engineers. She describes it as a career change with real costs: less code, less flow, a calendar full of meetings, and problems that don't compile or return errors. She also has no patience for common failure modes; the sections on micromanagement and on managers who hide behind "shielding the team" are quietly brutal.

At one point I actually laughed out loud, because I was reading an exact description of a previous manager's behavior. You rarely laugh at a professional book; it only happens when you've lived the thing on the page. That's part of why this book landed harder for me than Staff Engineer: I've worked under bad managers and occasionally good ones, and here was a book calmly flagging everything I'd experienced as an anti-pattern. It also made me notice something about myself. In every company with a weak manager, teammates ended up coming to me with their frustrations, like unofficial 1-1s. I've talked people out of quitting, helped them push for raises, and mediated conflicts, all without any title. After my previous manager left, those conversations only increased. Somewhere in the middle of this book I realised I've been doing pieces of the EM job for years, just without the name or the authority.

• Engineers deciding between the IC and management tracks. Read this together with Staff Engineer and you have both maps side by side. That's exactly what I did.
• New tech leads and first-time engineering managers. Chapters 3 to 5 are essentially an operating manual for your first two years.
• Every engineer, honestly, for chapter 1 alone. "What to expect from your manager" teaches you how to be managed, how to use your 1-1s, and what you're entitled to ask for. I wish I'd read it in my first year of work.

Who should skip it: nobody entirely, but if you're already a director or VP, the early chapters will be review and only the later ones (managing managers, bootstrapping culture) will earn their time.

This is where the two-book experiment ended with a decision. What this one changed:

• It settled the track question. Staff Engineer showed me a path that depends on org shape, sponsorship, and a bit of luck. This book showed a clearer ladder, and something more personal: the day-to-day it describes, the 1-1s, the feedback, growing people, is work colleagues have been bringing to me unofficially for years. The people side isn't the unknown for me; it's the part I've already been practicing.
• It upgraded my "why." I'll be honest: after years under bad managers, part of my motivation was wanting the authority to do it right. Fournier reframed that. Authority is the smallest part of the job. What I actually believe is that a manager who stays technically credible removes a ceiling from the whole team: better decisions, fewer blockers, and in the end a better experience for the customer. I'm confident enough in my technical side now; I want to add the other half.
• It named the gap I need to close. I'm good at the listening side of management, people open up to me easily, and I've been practicing that for years without a title. The other half I've never done at all: delivering bad news to managers and leadership, and making problems clear to them early. It was never my job, so I never built the muscle. The book made me see that this is half of what an EM exists for; the role stands between the team and the organisation and carries uncomfortable truths upward. I'm learning management deliberately for the first time, and this is where I'll start.
• It changed how I'll choose my next company. I now interview the management as much as the job: does a real ladder exist, do managers stay close to the work, are 1-1s a habit or a formality. Having seen both good and bad management up close, I know exactly what the difference costs.

• Becoming a manager is not a promotion. It's a career change, and your old job's output is no longer your job.
• Delegation is not abdication: you hand over the work, not the accountability. Handing over both is how teams silently rot.
• Dysfunctional teams should be debugged like systems: look for the pattern producing the behavior, not a person to blame.

The book's spine is a progression: being managed, mentoring, tech lead, managing people, managing a team, managing multiple teams, managing managers, and senior leadership, with a closing chapter on bootstrapping culture and process. Fournier's repeated warning is that each rung is a different job. The skills compound, but the instincts don't transfer automatically; the hands-on habits that made you a great senior engineer will actively hurt you as a manager of managers.

The first chapter is written for the report, not the manager, and it's quietly one of the most useful. The main tool it hands you is the 1-1: not a status meeting, but the place where trust is built and problems surface early. Fournier's advice is to bring your own agenda, raise things while they're small, and treat your manager as someone you actively manage a relationship with rather than weather to endure.

My note: reading this chapter as a report is also the cheapest possible interview prep for EM roles. Every question about how you'd run 1-1s or handle feedback has its foundations here.

The tech lead chapter describes the strangest rung of the ladder: a role where you're responsible for the team's technical delivery but manage nobody. You have influence, not authority. You still code, but you're now also doing project management, unblocking people, and communicating for the team, and your output is judged by the team's results.

Fournier is clear that this is where the two tracks first split, and that doing the role well means giving up being the fastest coder in the room. It's also, notoriously, a role many companies leave undefined.

Reading this chapter was like reviewing my own calendar. During my unofficial Team Lead period I did almost everything Fournier describes: checking sprint health and blockers before the daily standup, unblocking people, sometimes with code and sometimes with a conversation, protecting the sprint by parking new bugs as tickets for later, reporting progress to the CTO in a weekly meeting, even running informal 1-1s. The difference was in the foundation. Fournier's tech lead has influence granted by the organisation; mine was granted verbally by one manager. When he left, I discovered the role had never existed anywhere: no ladder, no defined levels, and a shrug about what title I used. The responsibility had been real, but the influence was borrowed from a person rather than the structure, and it left with him. That taught me something this book only confirmed: a leadership role that lives in one person's promise isn't a rung on a ladder, it's a favor. I stepped back from the extra responsibility, and that experience is a large part of why my next step is a formal EM role at a company where the ladder actually exists.

Once you have reports, the book gets very tactical. The pieces that stuck with me:

• Delegation is the core skill. Give people problems, not tasks, and let them own the outcome. Taking work back at the first mistake teaches your team to stop trying.
• Micromanagement is usually fear. Fear of losing technical relevance, fear of being blamed. The fix is trust plus clear expectations, not more control.
• Continuous feedback beats the annual review. If anything in a performance review is a surprise, the manager failed months earlier.
• Care about people's careers, not just their output. The manager's real product is people who grew on their watch.

Two ideas from the team chapter earn the price of the book. First, engineering managers must stay technical. Not coding daily, but close enough to the work to ask real questions, smell risks, and keep the respect of engineers. Managers who drift into pure process become ballast.

Second, her framing of team problems as debugging. A team that doesn't ship, a team full of drama, a team that's quietly miserable: treat each like a defective system. Gather evidence, look for the pattern, form a hypothesis, test it. It's the same skill engineers already have, pointed at people and process, and it beats the usual instinct of finding someone to blame.

There's also a warning I appreciated: shielding your team from organisational noise is good, but over-shielding infantilises them. Adults do better with context.

The later chapters cover ground most readers won't stand on for years: skip-level meetings, coaching first-time managers, debugging whole organisations, and what CTOs and VPs actually do. I read them the way you read a map of a country you might visit someday. The one durable lesson: the higher you go, the more your job becomes choosing what the organisation pays attention to, and the longer the delay before you learn whether you were right.

The thread through the whole book: management costs you things engineers love. Flow, code, the clean feedback of tests passing. Fournier never pretends otherwise, and that honesty is exactly what makes her case credible. If you want the title but not the calendar, the 1-1s, and the people problems, the book will show you that before an actual team pays for the lesson.

If Staff Engineer showed me the terrain I decided not to walk, The Manager's Path showed me the one I chose. It's the most practical book I've read on tech leadership: no theory of leadership, just the actual jobs, rung by rung, with the costs printed on the label.

Read chapter 1 no matter what you do. Read the rest if there's any chance people will report to you someday, and preferably before they do.

As for my own preparation: both books showed me that my knowledge is deep but self-shaped. I studied Mining Engineering at university; everything I know about software I built on the job. So before my first EM role, I'm putting structure under it. I'm currently reading Designing Data-Intensive Applications to strengthen the foundations, with ByteByteGo courses and algorithm practice lined up next, and after that An Elegant Puzzle, Will Larson's book on engineering management systems, which closes the circle back to the author who started this whole two-book experiment. Meanwhile I've already stolen one habit from Fournier: my informal 1-1s now have a structure, because I want the juniors around me to grow while I'm still their colleague. The applications start soon. If you've read both of these posts, you already know which title they'll be for.