Book Review: The Manager's Path

I recently finished reading Camille Fournier’s The Manager’s Path: A Guide for Tech Leaders Navigating Growth and Change (warning affiliate link) and here is my review of the book.


As a senior engineer / tech lead, with no or little aspiration to be a manager, I found only the first half of this book is useful and relevant. The topics covered on the first half resonated with me, some of them are: management 101, mentoring, tech leading, managing people and managing team. I found the 2nd half the book to be dry and a slog to read, it could be due to my disinterest on the topics covered, which are: being a manager of multiple teams, being a manager of managers, C level leader, setting up company culture.

Would I recommend this book? I’d say yes, for the following reasons:

  • The book has some really good advice on for engineers on all levels, especially the management 101 chapter.
  • It is beneficial to put yourselves on the shoes of your manager and your reports above that. The book does well in exposing some of the things that people in these roles have to deal in their work - this will lead you to appreciate the people who lead you (hopefully).

But I’d personally be borrowing this book from a local library or accesssing it via O’Reilly Learning rather than buying it.

OK, so here are some takeaways from the book - intermingled with commentary from my own experience.

Management 101

My favourite chapter of the book, it has really good and fundamental advice. I wish I have read this chapter earlier in my career. I like it so much, I would this chapter a recommended reading for everyone (especially for 2 groups of people: early career engineers and managers).

This chapter is useful for me as it reinforces the useful habits and mindset that I’ve observed on my career in tech.

1 on 1 meetings are an essential feature of a good working relationship.

I can definitely agree with this. In my career, I don’t always get 1 on 1s with my manager. And when I do, they don’t always working.

So, what’s the why behind 1 on 1s?

1-1s … they create human connection between you and your manager. The bedrock of strong teams is human connection, which leads to trust.

1-1s are not status meetings. Speaking from experience again, one of my worse 1-1s was just this, my manager used our 1-1s to talk about deliverables and roadmap (which he already talked about during sprint planning and in other ceremonies).

I finally told him that I would like to use 1-1s to be more focused on my career progression and thankfully he took it well and our 1-1s improved after that.

This leads to another point that Camille made, you should come with an agenda on things you would like to discuss. It is not your manager’s job to completely control the 1-1 agenda.

I have taken this advice to heart, for me this means 2 things:

  • Keeping a note with bullet points of what I want to talk about during 1-1, also recording any decisions or things to follow up.
  • Making it a habit to prepare for 1-1s where I would go over that document - it does not take long, perhaps 15-30 mins on the day of the 1-1.

Know what you want to do

Whether you are brand new to workplace or 20 years into your career, the onus of figuring out what you want to do, what you want to learn, and what will make you happy rests on your shoulders.

This is something that I have to learn the hard and long way, your managers are not mind readers. You need to advocate for yourselves and work with your managers.


Conclusion on management 101:

  • Build strong relationship with your manager
  • Spend some time figuring out what you want out of your career and make sure your manager knows

If you do this, you will be happier and more productive which will have positive impact on your manager and your company.


I didn’t get much from this chapter, but I like the following statement on the benefit of mentoring - which is sharpen the communication skills of the mentor:

.., you must be able to listen and communicate in a way that person can understand, even if you have to try several times to get it right. Software development is a team sport in most companies, and teams have to comunicate effectively to get anything done.

I know personally communication is something that I still have a lot to improve on, so I really welcome mentoring opportunities at work.

Tech Lead

The most relevant chapter of the book for me.

What is a tech lead?

I should probably write about my thoughts on tech lead on its own post, as I found tech lead is one of the most confusing positions with different companies can have a widely different definition on what a tech lead is.

In my career tech lead has sometimes been defined as a moment in time role which various definitions:

  • A role (or a hat) that a person takes for a period of time. This role is not a promotion, no renumeration reward for taking this role - however it is a pre-requisite for promotion.
  • A lead engineer for a project. The tech lead in this case directly responsible for the deliverables of the project and be the main point of contact for all things technical.

The vagueness can be attributed on the size of the company too.

In this book, the tech lead being described is similar to the point no 1 above, here’s what she said:

The tech lead role is not a point on the ladder, but a set of responsibilities that any engineer my take on once they reach the senior level. This role may or may not include people management… The tech lead is learning how to be strong technical project madnager and as such, they are scaling themselves by delegating work effectively …

What does a tech lead do

  • Strong technical project leaders
  • Still expected to code although not as much (30% is her recommendation)
  • May include people management
  • Focus on team’s productivity
  • Project managing

Tech Lead != Best Engineer

The idea that the tech lead role should automatically be given to the most experienced engineer,.. ,is a common misconception that even experienced managers fall for. Tech lead is not the job for the person who wants the freedom to focus deeply on the details of her own code. (emphasis mine)

This section is still to be continued - it is an excellent chapter of the book and I will need to re-read it again.

So stay tuned - for the future update of this post.