Last year I was promoted to be the tech lead of a large project at my job. Since this role involved more personal management than I was used to, I thought it would be a good idea to read up on the subject. The first book I picked out was “The Manager’s Path”, by Camille Fournier, which came highly recommended.

The book is a comprehensive, often high level, overview of different managerial roles at modern software companies, from mentor, tech lead, and all the way up to senior management. Each role is given a chapter where managerial duties and common challenges are discussed, including things like team cohesiveness, one on ones and more. It differs from other management books in that the focus is on more on the technical aspects of the job, rather than personnel management or business strategies.

Book Summary

Starting with tech lead and going up to senior management (“the big leagues”), the book spends a chapter describing each general level of management in a tech company. Each section has advice tailored to challenges you might face at that level. For example, the tech lead chapter has a section on deciding if you even want to be a manager (“Stay on the technical track or become a manager”), while the “managing multiple teams” chapter has a few pages devoted to measuring team health.

In terms of material, a wide variety of topics are covered at a high level. While the book does go into slightly more detail for a few topics, like performance reviews and one on ones, you won’t find a complete guide to any one subject. It is more of a broad overview of all of the different challenges you could face, as well as high level solutions to those problems.

While the book is mostly linear in its progression from the bottom to the top of the management chain, many topics are touched on multiple times throughout the book. Recurring topics include retaining technical skills, advice for project management, and team dynamics.

Content is broken up throughout each chapter so that you aren’t reading long continuous blocks of text. Many sub-sections are broken into lists where appropriate and there are frequent asides, like “Ask the CTO” or excerpts from other authors. Many chapters also have a “Good Manager, Bad Manager” examination of a theoretical management scenario.

Strengths

• The early chapters on mentoring and being a tech lead are perfect for anyone considering moving into a management role, or who have just transitioned into one (such as myself). It gave me a lot of immediate insight into some of the processes I’ve just started doing, like holding one on ones or giving performance reviews.
• Also scattered throughout the early chapters were discussions on the merits of becoming a manager, such as “Stay on the Technical Track or Become a Manager”. I was already aware of the tradeoffs, but anyone who isn’t would be well served to read these sections.
• The early chapters were the most relevant to me, but I also gained insight from the chapters on higher management rungs (like VP and CTO). The book gave me a framework to better understand the senior roles. For example, I had no idea that a CTO or VP could have such different sets of responsibilities.
• I really enjoyed the emphasis on and discussion around the goal of staying technical as long as possible. I had read elsewhere that managers should stay away from code for a number of reasons. This book presented a much more nuanced discussion of staying involved at different levels of the career ladder.
• Each chapter was broken up into multiple sections, asides, and lists, which made it a lot easier to read in gradual increments.
• The structure of the book makes it easy to refer back to specific sections for reference, so you can look up guidance on specific issues when you need it, IE debugging a team you’re in charge of.

Critiques

• Some of the material felt unnecessary and obvious, especially in the later sections. For example, the section on managing your time had a chart illustrating the need to spend time on “urgent-important” work and ignore “unimportant, non-urgent”, work. I realize that a lot of management advice can feel “obvious”, but a few sections were a bit too vacuous.
• I would have liked to see more detail given to addressing problem scenarios. There are a few sections dealing with potential problems, like “team cohesion destroyers” or debugging teams, but they seemed very theoretical. I would have liked more concrete examples and anecdotes of actual problems from engineering managers.
• While it talks about team and organization culture, it doesn’t address office politics. I would imagine that once you get into “the big leagues”, this becomes a much more important topic, one that is at least worth mentioning.
• Following from the last point, I’m not sure how valuable this would be to somebody who is already managing multiple teams or in a senior management role. While I gleaned many insights from the later chapters, I would imagine (or hope) that many folks in these positions would already have an understanding of subjects like “how to deliver bad news” or “working with a non-technical boss”.

Ask the CTO: Should I Read This Book?

Yes! Unless you’re already an experienced senior manager, this book has plenty to offer. I found several sections that were immediately applicable to me in my current position as a tech lead. The well structured format made it easy to read and reference. I would recommend it to anyone in an engineering management role, especially those who just entered management or are considering it.