The Manager’s Path — Book Summary For Engineering Managers

Learn from one of the classic must-read management books

The Manager’s Path (book cover)

I really enjoyed reading The Manager’s Path (by Camille Fournier). It’s a small easy-to-read book. You will learn something from this book whether you are an experienced or new manager. Camille Fournier covers a wide range of management: mentoring, leadership, tech lead, and more.

I took notes when I read this book. This article is those notes, somewhat cleaned up. It may not be perfect, but I hope you find it helpful.

I’ve also added some links to a few external resources I use personally.

How to be a great leader

• Understand the architecture: learn it, get a sense of it, and visualise it.
• Be a team player: don’t keep all the interesting work for yourself, take some of the hardest tasks.
• Lead technical decisions: solicit the input of your team, determine which decisions must be made by you, and communicate the outcome.
• Communicate: pay the price of communication overhead so your team can crack on. Write well, read carefully, and speak. Don’t forget to listen. Rephrase.

Starting a new reporting relationship off right

• Build Trust and Rapport: ask questions such as:
  – How do you like to be praised, in public or in private?
  – What is your preferred method of communication for serious feedback? (writing, less verbal…)
  – Why did you decide to work here? What are you excited about?
  – How do I know when you are in a bad mood or annoyed? Are there things that always put you in a bad mood that I should be aware of?
  – Are there any manager behaviours that you know you hate?
  – Do you have any clear career goals that I should know about so I can help you achieve them?
  – Any surprises since you’ve joined, good or bad, that I should know about?

I like to use this document from Lara Hogan:

Questions for our first 1:1

• Create 30/60/90 day plan: getting up to speed with the code, first commit, etc. Set realistic milestones. That will help you to quickly be in a position to evaluate the engineer.
• Encourage participation by updating the new hire documentation: write /update the onboarding documentation.
• Communicate your style and expectations: how often do you meet, what information do you share, when should they ask for some help, etc.
• Get feedback from new hires: fresh eyes might pick things other people won’t see.
• Regular 1–1s: adjust the comms and the topics. Be a good listener, mentor, and coach.

Practical advice for delegating properly

• Gather information from the systems before going to the people: use metrics, don’t waste their time, and avoid micromanagement.
• Adjust your focus depending on the stage of the project: different details are important at different stages.
• Establish standards for code and systems: the amount of unit testing, coding standards, technical documentation templates, etc.

Performance reviews

• Use 360 feedback (get feedback regularly)
• Give yourself enough time for the session
• Start on time
• Try to account for the last year, not the past 2 months
• Use concrete examples/facts
• Spend plenty of time on accomplishments and strengths, and write them down
• When it comes to areas for improvement, keep it focused
• Make sure the feedback you are seeing makes sense before delivering it (filter)
• Avoid big surprises: continuous feedback
• Schedule enough time to discuss the review

When it’s about giving I like to use this document from Lara Hogan:

Feedback Equation

Debugging dysfunctional teams

• Not shipping:
  – Roll up your sleeves and help
  – Check tools and process
• People drama:
  – Make it clear the behaviour has to change (describe the impact)
  – Toxic mindset -> act quickly
• Unhappiness due to overwork:
  – Slow down the product roadmap
  – Regularly reduce the technical debt
  – Support the team
  – Recognise the team effort
  – Push back
  – Organise social activities to boost morale
• Collaboration problems:
  – Touch base with the different members regularly
  – Organise team building, team lunch

The dos and don’ts of managing conflict

• Don’t rely exclusively on consensus or voting: the voting process is rarely impartial. People have different levels of expertise.
• Do set up a clear process to depersonalise decisions: foster a shared understanding of goals and risks.
• Do address problems from the beginning: don’t wait!
• Do address issues without courting drama: identify the problems and resolve them, you are not a therapist.
• Don’t take it out on other teams: be accountable!
• Do remember to be kind: kind is different from nice. Nice is good in casual conversations, as a manager, you need to be kind.
• Don’t be afraid: make decisions, don’t fear what others think.
• Do get curious: do some training and ask for feedback.

Radical Candor is a great reference when it’s about “being kind”:

Project management rules of thumb

• You have 10 productive engineering weeks per engineer per quarter not 13 (vacation, meetings, etc.).
• Budget 20% of the time for generic sustaining engineering work across the board: testing, debugging, technical debt, etc.
• As you approach deadlines it’s your job to say NO: see “Strategies for saying NO” section further down.
• Use the doubling rule for quick estimates: but push for planning time to estimate longer tasks.
• Be selective about what you bring to the team to estimate: don’t waste their time.

Prioritizing your time

Source: https://reclaim.ai/blog/eisenhower-matrix

Strategies for saying NO

• “Yes, and”: Yes we can do that project and all we will need to do is delay the start of that other project….
• Create policies: hard requirements that must be met to say yes.
• “Help me say yes”: questioning helps people come to realise that their plan isn’t a good idea.
• Appeal to budget and time: numbers speak for themselves.
• Work as a team: act together with your peers to say no.
• Don’t delay the NO: it’s better to say it quickly than to delay.

Measuring the Health of Your Development Team

• Frequency of releases
• Frequency of code check-ins
• Frequency of incidents
• Cycle Time

Delivering bad news

• Don’t blast an impersonal message to your team: the worst way to communicate bad news is via impersonal mediums. Your team deserves to hear the message coming from your mouth directly.
• Do talk to individuals as much as possible: adjust the message for the people who will have the strongest reaction.
• Do be honest about the likely outcomes: acknowledge this is not fun but insist on the positive outcome.
• Do think about how you would like to be told (or not to be told).

I hope you enjoy this article. Here are some other articles you may like:

My Top 5 Takeaways From Management Books

Craft Memorable Presentations — Summary of “Made To Stick”

Secrets of Power Negotiating — book summary

Thank you for taking the time to read this article. If you enjoyed it, I would greatly appreciate your support with a round of applause (don’t be shy, you can give up to 50 👏).

Feel free to stay connected for more exciting content in the future by following me. Your feedback and readership mean the world to me! 😊

Hungry for more software engineering management insights? Dive into my Twitter feed and explore my Gumroad resources!