My review of camille fournier's book the manager's path cross posted from the dxw blog
The Manager’s Path – a book review
This is cross-posted from the dxw blog - where I work. Thanks to dxw for making the time for me to write this and to Dawn Kofie for editing it.
When new developers start working at dxw they’re given some books to welcome them to the team. One of them is The Manager’s Path by Camille Fournier.
What’s it about?
The book details the author’s experiences climbing up the management ladder and what to expect at each level. It goes all the way from their first steps in a career in software development, and being mentored and managed, right through to:
- being a manager
- managing managers
- managing managers who manage managers! Then it talks about how to be a good CTO/VP. Fournier suggests reading the chapters that relate most closely to your current role and then skimming through or skipping the following chapters until you find yourself at the level they describe. As I’m fairly early in my career this would result in me only reading the first 10 pages so I respectfully ignored this advice and read the whole thing - I’m glad I did.
The book is full of advice that, even though it might not always be practical to implement given your current job title, is at least useful to ponder. There are plenty of summaries of the book available online, and it’s hard for me to criticise too much of the book’s content past the first 10 pages as I’ve not been in the positions that Fournier is describing. So I thought I’d highlight some of my favourite pieces of advice from the book instead.
Following the people management route
The Manager’s Path gave me a good picture of how a career in development could progress if you choose to go down the management route. Personally I’m not that eager to do so (at least not currently). And one of the things I really like about the software developer progression framework at dxw is once you’re past junior, there’s no expectation to progress further.
Fournier describes each level as building on the one that came before but having a distinct skillset, so it stands to reason that not everyone is going to be best suited to progressing through all of the levels. Some people may be best suited to being a developer and others an engineering manager. But it doesn’t mean either is less skilled, just differently skilled. Whilst the expectations of (and salary for) different levels of technologists is clearly mapped out for developers at dxw in our progression framework, the book does give insight on how the different roles might look in the wider industry, at least from Fournier’s perspective.
Time management
Fournier shares how difficult she found managing her time when she made the jump from managing a single team to managing multiple teams. And she suggests that if the reader wants to progress to start working on their time management skills early on. Early on in your career she suggests that you have more control over your time but, if you progress to management, your daily schedule can be taken up with unplanned work and often it feels like you’re struggling to make any progress. She suggests using The Eisenhower Matrix (also called the Urgent-Important Matrix) which helps you decide on, and prioritise, what to work on by urgency and importance:
| Not Urgent | Urgent | |
|---|---|---|
| Important | Strategic: Make time | Obvious work |
| Not Important | Obvious avoid | Tempting distraction |
When I read it seemed so obvious. But, without even trying, I now think about every day when I’m deciding whether to spend time on something.
The value of curiosity
One of the most profound pieces of advice feels almost thrown away right at the end of the book, when Fournier says she found her path to leadership a ‘series of difficult lessons, mistakes and challenges’. Obviously this would take its toll on anyone. In order to be able to deal with the frustrations of her work, and interpersonal relationships at work, Fournier suggests trying to be as curious as possible. If someone is disagreeing with you, try and imagine what they might want, what their values are and what they are trying to do and life will be easier. Since reading this I’ve tried out this technique and found it to be really useful, not only at work but in life outside of work too.
An observation about feedback cycles
The final piece of wisdom I got from the book is that the higher up the ‘path’ you go, the slower the feedback cycles become and the more of your work seems to be based on past experience.
If you’re someone who spends most of your time writing code you can make feedback cycles incredibly short: write some code and within seconds you can find out if it works. There are longer cycles in play, the lifecycles of tickets, features, epics, projects but generally we can get feedback and change course relatively quickly.
If you’re responsible for managing a team above the tech lead level (you’re not writing much code) and you don’t want to micro-manage as Fournier suggests, then you’re reliant on your team implementing your suggestions and following your coaching towards what you think is the right path. Not only is the feedback cycle longer here, but you’re also no longer in control of how long the work takes - you’re reliant on other people delivering.
It also seems that because feedback cycles are longer and there are more other variables at play (different teams, products, roadmaps, product teams, ops teams etc.) it’s harder to apply knowledge between different scenarios. For example, just because something worked for team X at time Y doesn’t mean that it will work the same for team Y at time X.
A book to dip back into
Although whilst reading the book I didn’t think I was getting too much out of it, sitting down to write this has made me realise how much great advice the book contains. I think it’s a worthwhile read for developers at any stage of their career and a book that I’m looking forward to revisiting as my career progresses - even if I don’t follow the manager’s path.