Scan barcode
A review by rbruehlman
The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change by Camille Fournier
4.0
The Manager's Path explores the common managerial career path for technologists, from tech lead to engineering manager to VP to CTO, what the job responsibilities and expectations are at each level, and, at a high level, what to focus on and achieve at each point.
Fournier aptly notes this book fills a very specific niche within the already crowded management skills section of a bookstore. There are a lot of common techniques, approaches and skills inherent to management regardless of field, and this book doesn't attempt to cover those bases--it's been done before, many times, and far better. However, tech management is a specialized subset, and general management books will miss much of the nuance. I think this is very true. Tech is its own weird beast, and it comes with its own challenges. Non-technical managers often are out of their depth managing tech teams, and yet tech is not exactly known for attracting people with great social skills. The capacity to lead and mange is a wholly different skillset than software engineering, and being the smartest technical person in the room doesn't mean you'd be any good leading. It's also very challenging for "good people skills" managers who like software engineering to let go of their craft, which they must do to be an effective leader. These challenges just don't have a lot of parallel in most industries insofar as management is concerned.
I agreed with everything Fournier said; it was all spot on. I've had a wide spectrum of managers over the years, ranging from incompetent to forgettable to okay to excellent. My first few managers were ... not good, but my first ever manager when I switched into software engineering was amazing. It was the first time I ever realized just how powerful a good manager can be, and how much of an impact good management has on a team's performance and people's career trajectories. I am not sure I was blown away by any of the book because so much of what she recommended had already been modeled to me. However, I think unremarkable tech managers are pretty common, so I could see this book being really eye-opening for software engineers who didn't have the luxury I did.
I really appreciated that Fournier talked about the challenges and struggles people face as they step into each type of role. For instance, many engineering managers struggle with the fact that they no longer can write a substantial amount of code. And managers who lead multiple engineering teams may feel like they are underwater for months when they first start, their attention ping-ponging everywhere between competing priorities. Fournier really normalizes the experience at all levels, being blunt and honest about the likely learning curve and associated struggles.
She also won big brownie points for me for admitting that small talk and team cohesion is really important. She admits herself that she isn't naturally inclined towards such things, but realized its importance as she climbed up the ladder. It's super, super, super common for software engineers to scoff at small talk or team bonding activities or to otherwise be antisocial and introverted. If you are an individual contributor, your asocialness affects (mostly) you; if you are a team leader, being all about efficiency will make people feel like cogs in the machine. It's not that you need to be best friends with your team outside of work. But you do need to remember to treat your team members like human beings. Express interest in their kid's baseball game. Ask them how their house remodeling is going. A little bit of human-ness goes a long way.
One thing I wish the book had discussed was why there is often a distinction between engineering managers and tech leads. I have done matrix reporting before, working on a team not within my manager's purview, and it sucked. My manager at the time had very little insight into what I did on a day-to-day, so how was he supposed to coach me? Matrix management felt like a glorified HR admin relationship. I still, to this day, don't understand how matrix management is supposed to be effective. Was my department just doing it wrong? Or were the pitfalls I saw legitimate flaws?
I also wish this book was updated for the post-pandemic tech world. Most of tech is now remote, and that comes with its own challenges...
Fournier aptly notes this book fills a very specific niche within the already crowded management skills section of a bookstore. There are a lot of common techniques, approaches and skills inherent to management regardless of field, and this book doesn't attempt to cover those bases--it's been done before, many times, and far better. However, tech management is a specialized subset, and general management books will miss much of the nuance. I think this is very true. Tech is its own weird beast, and it comes with its own challenges. Non-technical managers often are out of their depth managing tech teams, and yet tech is not exactly known for attracting people with great social skills. The capacity to lead and mange is a wholly different skillset than software engineering, and being the smartest technical person in the room doesn't mean you'd be any good leading. It's also very challenging for "good people skills" managers who like software engineering to let go of their craft, which they must do to be an effective leader. These challenges just don't have a lot of parallel in most industries insofar as management is concerned.
I agreed with everything Fournier said; it was all spot on. I've had a wide spectrum of managers over the years, ranging from incompetent to forgettable to okay to excellent. My first few managers were ... not good, but my first ever manager when I switched into software engineering was amazing. It was the first time I ever realized just how powerful a good manager can be, and how much of an impact good management has on a team's performance and people's career trajectories. I am not sure I was blown away by any of the book because so much of what she recommended had already been modeled to me. However, I think unremarkable tech managers are pretty common, so I could see this book being really eye-opening for software engineers who didn't have the luxury I did.
I really appreciated that Fournier talked about the challenges and struggles people face as they step into each type of role. For instance, many engineering managers struggle with the fact that they no longer can write a substantial amount of code. And managers who lead multiple engineering teams may feel like they are underwater for months when they first start, their attention ping-ponging everywhere between competing priorities. Fournier really normalizes the experience at all levels, being blunt and honest about the likely learning curve and associated struggles.
She also won big brownie points for me for admitting that small talk and team cohesion is really important. She admits herself that she isn't naturally inclined towards such things, but realized its importance as she climbed up the ladder. It's super, super, super common for software engineers to scoff at small talk or team bonding activities or to otherwise be antisocial and introverted. If you are an individual contributor, your asocialness affects (mostly) you; if you are a team leader, being all about efficiency will make people feel like cogs in the machine. It's not that you need to be best friends with your team outside of work. But you do need to remember to treat your team members like human beings. Express interest in their kid's baseball game. Ask them how their house remodeling is going. A little bit of human-ness goes a long way.
One thing I wish the book had discussed was why there is often a distinction between engineering managers and tech leads. I have done matrix reporting before, working on a team not within my manager's purview, and it sucked. My manager at the time had very little insight into what I did on a day-to-day, so how was he supposed to coach me? Matrix management felt like a glorified HR admin relationship. I still, to this day, don't understand how matrix management is supposed to be effective. Was my department just doing it wrong? Or were the pitfalls I saw legitimate flaws?
I also wish this book was updated for the post-pandemic tech world. Most of tech is now remote, and that comes with its own challenges...