The Manager`s Path: A Guide for Tech Leaders Navigating Growth and Change Paperback – 24 March 2017
Enhance your purchase
Frequently bought together
How to Read This Book
This book is separated into chapters that cover increasing levels of management complexity. The first chapter describes the basics of how to be managed, and what to expect from a manager. The next two chapters cover mentoring and being a tech lead, which are both critical steps on the management path. For the experienced manager, these chapters have some notes on how you might approach managing people in these roles. The following four chapters talk about people management, team management, management of multiple teams, and managing managers. The last chapter on the management path, Chapter 8, is all about senior leadership.
For the beginning manager, it may be enough to read the first three or four chapters for now and skim the rest, returning when you start to face those challenges. For the experienced manager, you may prefer to focus on the chapters around the level that you’re currently struggling with. Interspersed throughout are sections with three recurring themes:
Ask the CTO
These are brief interludes to discuss a specific issue that tends to come up at each of the various levels.
Good Manager, Bad Manager
These sections cover common dysfunctions of engineering managers, and provide some strategies for identifying these bad habits and overcoming them. Each section is placed in the chapter/level that is most likely to correspond to the dysfunction, but these dysfunctions are often seen at every level of experience.
Starting in Chapter 4, I take some time to discuss challenging situations that might come up. Again, while these are roughly placed with the level that is most appropriate, you may find useful information in them regardless of your current level.
Chapter 9 is a bit of a wildcard, aimed at those trying to set up, change, or improve the culture of their team. While it was written from a perspective of a startup leader, I think that much of it will apply to those coming into new companies or running teams that need an uplift in their culture and processes.
More than an inspirational leadership book for a general-purpose audience, I wanted to write something worthy of the O’Reilly imprint, something you can refer back to over time in the same way you might refer to Programming Perl. Think of this book as a reference manual for engineering managers, a book focused on practical tips that I hope will be useful to you throughout your management career.
About the Author
No customer reviews
|5 star (0%)||0%|
|4 star (0%)||0%|
|3 star (0%)||0%|
|2 star (0%)||0%|
|1 star (0%)||0%|
Review this product
Most helpful customer reviews on Amazon.com
Previous contenders have included Peopleware, High-Output Management, The Mythical Man-Month, Good To Great, and others you've probably heard of. They are fine books, but they are either somewhat out of date, overly general, or a combination of both. This book is different. Fournier's book is a comprehensive overview of all the roles on the career path of modern technical management (starting from "senior engineer mentoring an intern" all the way up to CTO) and how to deal with the challenges at every step of the way.
What sets this book apart, other than being comprehensive, is that it is the product of direct and highly relevant experience. Fournier has worked at huge companies, small startups, and medium-sized companies, all in hyper-competitive industry settings. You've probably read other management books and it always goes like this: they give you a piece of general advice about how to deal with an issue. You try it (assuming it is even specific enough to put into action and isn't just a feel-good HR platitude), you run into a snag, and now the advice is useless because the rosy assurances in the book about how employees were going to act reasonably didn't really work. You throw the book away and think there is something wrong with you because everyone keeps on talking about how the book is great and it's just your fault that you couldn't make this great advice work.
Fournier's advice is not like that.
She starts with the general outlines of the strategy, but then tells you about times when she had to confront the issue herself, how she tried to apply the strategy and screwed up (there are instances in the book where she openly admits "The first time I tried this I fell flat on my face"), what kinds of problems kept the strategy from working, how she modified the strategy and overcame the problems, and finally and most importantly, wraps up with a summary about how context and trade-offs affect how you apply the advice. Acknowledging and explaining how common variations and implementation details determine how a general strategy will play out is what makes this book unusually useful and relevant.
Because everyone's job and situation are a little bit different, Fournier does an excellent job of breaking down broad strategies into their core principles, while separating out which details you can change based on individual situations, so that you can choose between trade-offs when you apply the strategy to the specific challenge you are confronting.
Lastly, this book will give you confidence. Confidence that you're not alone, that others have faced the same problems and surmounted them, that you can do it too. Confidence that you can screw something up but still pick up the pieces and try again, that you'll still get it right the second or third time, and that you are going to get to where you want to go.
This book is the product of years of tough lessons and hard-won success. Buy it. You won't regret it.
Camille provides a great, unvarnished and hands-on tour of her own career from an engineer to a tech lead, to manager (lead and manager are often confused and conflated, but are very different roles), to manager of managers (a MoM :)), to executive leader responsible for aligning product and technical execution. As you would expect, the story is a rollercoaster with many wins and just as many setbacks and lessons along the way. The good news is, we can all learn from Camille's experience without repeating all (or some, at least) the same mistakes.
The strength of this book is that it takes you all the way from engineer to CTO, with hands-on illustrations in major role and expectation (both the good and the bad) shifts along the way: we all know that Director or VP that clings on to writing code at a detriment to their team; a TL that hordes decision making; a MoM that lost touch with technical foundation of the product; etc. This book will help you avoid these traps, both in your own career and on your team.
In short, a modern hands-on manual for both the aspiring and existing technical leaders, and a sound time investment — read it.
After reading the book I am a bit confused for some areas. For example, what a typical day looks like for middle management because this is one area I saw the difference.
In Chapter 3 "Tech Lead" she described quite some responsibilities a tech lead has except for leading technical decisions, which are actually my responsibilities, i.e. managing a project, "tech leads will be working on one major new technical skill: project management. The work of breaking down a project has a lot of similarity to the work of designing systems..."
In Chapter 5. "Managing a Team" she wrote "while the product manager is responsible for the product roadmap, and the tech lead is responsible for the technical details you are usually accountable for the team’s progress..."
But what does a typical day look like then if product, technics and project are someone else's responsibilities? I mean do 1-1, performance reviews, interact with HR, meeting with other departments/teams can't take your whole day, right? Or will it? Creating a culture in the team is our responsibility too, but how does it map to your daily job ?