The Manager's Path

A Guide for Tech Leaders Navigating Growth & Change

Author(s): Camille Fournier

View on thriftbooks

View on Amazon

Managing teams is a series of complex black boxes interacting with other complex black boxes. -@skamille

This post is not a comprehensive review or summary of The Manager’s Path, but rather my interpretation of the key takeaways for me at this point (two-years in) in my career as a software engineer at a hyper-growth company. As I’ve said before, I read a lot of management books (e.g., The Hard Things About Hard Things, An Elegant Puzzle, etc.) to both help me understand the perspective of and navigate situations with my manager and skip-level management.

My interest in reading more about engineering management was sparked when a great manager of mine taught me how to influence the change that I wanted to see in ways other than lobbying. He explained that a foundational principal of a product-driven technology company is managing the balance between product and engineering-focused work.

Influencing Change

The only person that you can change is yourself. -@skamille

Often what you will have to do is motivate technical changes through value added to the product (e.g., performance, reliability, reduced on-boarding costs, etc.). In my first year in industry, I would lobby for technical change, which often resulted in projects never becoming a priority. Instead of lobbying for change, you should make the change, share with a small group of people, gather feedback, tweak as you see fit and then iteratively share with larger groups.

Evangelizing your current and completed work is also foundational in your career growth. The angle at which you evangelize your work should be tailored to your audience. If the room is full of engineers, you may not need to motivate adding a test suite and integrating it into the continuous integration (CI) workflow. However, if you are in a room with the product team, you absolutely need to motivate these types of changes from their perspective e.g., improved reliability, reduced on-boarding costs of new engineers to the project, faster feature cycles. Otherwise, to product, the equivalent time spent adding the test suite and integrating into CI could have been spent elsewhere.

Understanding the Why

Understanding why you are doing something will help improve your mental health. If you know you are working on something important and of value to the company, you will probably be happier than someone who doesn’t know why they are doing something. The responsibility of understanding why you are working on something shouldn’t fall entirely on your manager. You should feel empowered to ask, “why?”, if you don’t understand why what you are doing is valuable or valuable at this point in time.

You should help others understand why they are working on something if you see that they are struggling with understanding why. Evangelizing the work that others are doing while they are working on it is something that I have tried to do more. When I hear them say, “I didn’t do anything important this sprint”, I remind them that they just finished a huge value add. I think the responsibility of voicing the importance of work falls on team members looking out for each other and on the engineering manager.

It may be the case that occasionally you have to work on something that you don’t value — e.g., maybe the hacky system, or the project written in a language that you despise — but, your work “needn’t always be self-sacrificing.”

[a]utonomy…is an important element of motivation. -@skamille

Honestly, in my experience, people aren’t working on what they want because they haven’t expressed their interests or they haven’t motivated their interests in a way that adds immediate value. Often what I will hear is, “I want to rewrite this system because it’s poorly written.” Even if every single new feature in this system takes a week to add, no matter how trivial, and there is a lot of risk associated with changes, this might be a price that product is willing to deal with to avoid a multi-month rewrite. You have to break these large changes down into “bite-size” or sprint-size pieces, which will help the change seem more achievable. The product team is driven by completion. Additionally, if you are able to break these pieces down and have them align with the product roadmap, you will have a higher chance of them being prioritized.

Many technical projects are supported on the strength of their ability to enable new features more easily. -@skamille

Expectations of a Manager

In my experience, defining and upholding expectations is a core function of being a software engineer. From engineering career ladder level setting to task estimation. Similarly, there are things that you can and should expect from a “good” manager, such as frequent and “productive” one-on-one meetings (1:1s), rapid feedback (especially things that are not going well, but also praise) and finally, action i.e., the manager listens to what you are saying and actually addresses the problems. Fournier starts the book with a section titled, “What to Expect from a Manager”, where she mentions that there are engineers who have never had a “good” manager. Either their manager took the approach of “benign neglect” and held infrequent 1:1s or they were actively abusive and only held 1:1s to yell at them.

One-on-One Meetings (1:1s)

In my experience, surprisingly, many engineers prefer benign neglect over the frequent 1:1s. I, on the other hand, especially being remote, prefer weekly 1:1s with my direct manager and less frequent 1:1s with skip-level managers and peers. I’ve scheduled the bi-weekly 1:1s with skip-levels and peers such that each week is evenly distributed with meetings rather than one week being “bloated” with meetings and the next being “light”.

Knowing yourself is step one. Step two is going after what you want. -@skamille

These 1:1s are in addition to daily stand-ups. I’ve heard some engineers try to argue that stand-ups are an adequate replacement for 1:1s. Fournier talks about this too, but 1:1s should not just be time for project status updates, especially at the individual contributor level. Instead, 1:1s with direct managers/reports should be a place where you talk about personal issues or things preventing you from being (or enabling you to be) the best contributor that you can be (e.g., a communication issue due to poor team structure, etc.). Fournier isn’t the only one that has said that you, especially the more senior you are, should be defining the agenda of 1:1s. If you don’t know where to start, I personally suggest starting with the sprint retrospective format i.e., “What went well”, “What didn’t go well and how to improve” and “Action items”. Defining the agenda for your 1:1s aligns with the notion that as you become more senior, you “bring solutions, not problems”.

One of the best things that you can do in 1:1s is to listen to what the other person is saying. Fournier says that, “[l]istening is the first and most basic skill of managing people.” She goes on to say that listening is the “precursor to empathy.” In the episode, Decoding Difficult Conversations of The Knowledge Project with Shane Parrish podcast, guest, NY Times best selling author, Harvard Law School lecturer and negotiation expert, Sheila Heen, discusses how listening is an often underutilized and weak skill for many people. Both Fournier and Heen discuss how often people “pretend” to listen, while really they are spending that time thinking about what they are going to say next.

I am now cognizantly aware of when I am preparing my next statement instead of actively listening. Something that has helped me actively listen more is having a shared Google Doc up or some form of note taking so that I can jot my thought down quickly so that I don’t forget it when it is my turn to share. Most of the time, people won’t mind if you do this because conversations should be about sharing knowledge and if you have something important to the conversation, they wouldn’t want that thought to be lost either. I do let people know when I start taking notes on video chats or in person that I am taking notes about the conversation and not doing other work. I mainly do this because it bothers during 1:1 video chats when I clearly see someone doing something on their computer. My first thought is checking email or Slack, but if you let people know that you are actually taking notes, I think it helps avoid the perception that you are doing other work.

Going back to the idea of conversations being a means for sharing knowledge, Fournier makes a phenomenal point about this notion of the “hive mind” and how most peoples’ (primarily engineers’) written and spoken language is often lacking. When ideas or concerns can’t be effectively shared through written or spoken language, progress isn’t made.

We have yet to achieve Borg hive mind or Vulcan mind meld, so we’re constantly pushing complex ideas through the eye of the needle of language. -@skamille

Being Able to Say, “No”

Fournier describes in one of the “Good Manager, Bad Manager” sections the “people pleaser” and how this individual typically says, “yes” to everything but can’t feasibly act on all of the things they’ve said yes to. Being able to say, “no” is important in upholding “agreements”. In a recent long car drive, I listened to episode #60 of the Knowledge Project with Shane Parrish and guest Jim Dethmer. The episode starts with Dethmer stating that most people in organizations keep between 40 and 60 percent of their agreements. Most of the agreements that aren’t upheld are because agreements are accepted without clear terms.

He does describe the commonality in organizations to expect acceptance or rejection to an agreement immediately after the agreement has been proposed. Rather than giving people the opportunity to think and reflect on whether upholding the agreement is feasible. This is precisely when you should feel empowered to say “no”, using one of the strategies proposed by Fournier. Your response doesn’t have to explicitly be “no”. Instead, it could be, “give me until the end of the day to get you a response” or “yes, but we can’t do this piece in this time frame. Either change the time or we can drop this piece.”

Asking for the rest of the day gets you out of the situation of giving a response with people in the room where you aren’t clearly thinking about what all the task entails. The second makes sure that you are aligning expectations. You display you understand the importance of doing the task, but you are helping align their expectations on when and what will be delivered. As a manager, you should make sure that you are establishing a culture where people shouldn’t feel that it is necessary to give a response immediately after something has been proposed, but also should be empowering your team to say “no”.

If you were only allowed to work 45 hours this week, what would you do with those 45 hours? -@skamille

Fournier makes this point when she is discussing picking your battles. For example, if you are a senior engineer, is it worth nitpicking every single little detail in a junior’s code? This point is also helpful when deciding what you are going to say “yes” to. Every task isn’t so important that it must be done this week. When you are saying “yes” to tasks, make sure you are thinking about what you are saying yes to and make sure that it aligns with your personal roadmap and the company roadmap. If it doesn’t align with either of these, make sure that you ask why you are doing the task. Could you be working “smarter” instead of working longer? For example, instead of every week saying yes to manually creating a report, propose automating the process. Even repetitive easy tasks are a waste of time. Sometimes it is good to “be lazy” and not put up with repetitive, manual, “toil” tasks forever.

Appendix

Personal Action Items