cat posts/2017-05-09-book-review-the-managers-path.md
Book review: The Manager's Path
The first time I managed people, nobody gave me a book. I got a list of names and a recurring meeting on my calendar, and I spent about six months doing what most new engineering managers do, which is keep writing the hardest code on the team myself while everyone waited on me. If someone had handed me Camille Fournier’s The Manager’s Path that week I’d have saved myself, and the people on that team, a fair amount of grief.
Fournier was the CTO at Rent the Runway, and before that spent years as an engineer, so she writes from both sides. The book came out from O’Reilly this spring. It’s organized as a ladder, which turns out to be exactly the right structure: each chapter is one rung, in the order you’re likely to climb them. It starts with being managed yourself, then mentoring, then tech lead, managing people, managing a team, managing multiple teams, managing managers, and finally what she calls “the big leagues”, the VP and CTO jobs. There’s a chapter on culture at the end.
The tech lead chapter is the one I’d make every senior engineer read, whether or not they want to manage. Her description of the job matches what I’ve seen: it’s the role where you’re still expected to write code, but your real output is the team’s output, and you have to learn to split your time between your own work and unblocking everyone else’s, which will feel like a step backwards for a while. I’ve watched good engineers take a tech lead role and quietly fail at it by staying heads-down, because nobody told them the job had changed. I was one of them.
The managing-people chapter has the practical stuff on one-on-ones, feedback and career conversations, and it’s practical in the right way. It doesn’t pretend there’s a formula. It’s much closer to “here’s what tends to go wrong, here’s what usually helps” than to a framework with a two-by-two in it, which I appreciated.
The chapters that I got the most out of this time, though, were the middle ones on running multiple teams and managing managers, because that’s the transition I’ve found hardest and have seen the fewest people write about honestly. The shift is that you’re now too far from the code to judge it directly, and your information comes through other people who have their own reasons for telling you things. Fournier is good on how to keep your technical judgment useful at that distance without turning into the director who parachutes into code reviews and rewrites people’s designs. It also made me think again about the part nobody warns you about, which is that at that level some of the people reporting to you will be much better engineers than you ever were, and your job is to make them more effective, not to win arguments with them.
The big leagues chapter is shorter and more general, which is probably unavoidable, since what a CTO does at a 30-person startup and at a 3,000-person company have very little in common. Her take on the difference between a CTO and a VP of Engineering is the clearest I’ve read, and I’ve read a lot of blog posts arguing about it.
A couple of complaints. The book is short for the ground it covers, so some sections end just as they get interesting, and I’d happily have traded the culture chapter for twice as much on managing managers. And it’s written for people in reasonably healthy organizations. If your company is on fire, it’ll tell you what good looks like, but it won’t tell you much about how to survive the next quarter. That’s a different book, and maybe not one anyone can write.
None of that stops me recommending it. I’ve already bought two copies for people on my team who are about to take on their first reports, and I’m going to ask them to read the chapter for the rung above the one they’re stepping onto, so they know what their manager is supposed to be doing for them. That was the thing I most lacked the first time around. I didn’t know what good management felt like from the receiving end, so I had nothing to compare myself against.