The Manager's Path

I recently finished the book The Manager’s Path, which I very much enjoyed, and have been wanting to write up my thoughts on it so that I better remember my takeaways. Authored by Camille Fournier, it was published only a few years ago, and unlike many leadership books I found it extremely relevant and in line with my own experiences. I’ve begun recommending it to any of my senior developers who are interested in going into leadership. The following are some sections that I found particular value in.

Real vs. Imagined Life of Senior IC & Manager

This was perhaps my favorite section of the book. It’s early on, and was the part of the book where I knew for sure that I would finish it. In my experience, it is an extremely accurate summary, and had me laughing at parts such as this description of the imagined life of a senior developer:

Because of your seniority, the managers ask you for your advice on how to approach development before it begins, so you know everything that’s going on but you don’t really need to deal with the details of the people building it. You’re invited to just the right set of meetings where the important decisions are made, but not so many as to disrupt your flow.

Anyone who has been involved in software development for a while can likely see the unrealistic optimism in that sentiment - but it is absolutely one that I’ve seen before, and that I had myself as an IC. In most companies, being present only for the “right” meetings is a pipedream. We all have to deal with some inefficiencies at the individual level - one could argue this helps the efficiencies of the group as a whole (by not having to bring people in/out of meetings all the time and the logistics involved there), but whether it’s that or just poor planning, it’s a fact of life.

Similarly, I’ve found when talking about the possibility of going into leadership, most people focus almost exclusively on the positives - training, coaching, having more decision making authority, etc. Very few realize the potential downsides that I had to learn the hard way. This section from the real life of a manager sums up a few particularly important points:

Your team does not naturally just agree with you, respect you, or even like you. You realize that authority requires more than a title. You find yourself scrambling to motivate them through tough periods when the projects aren’t going well, or when you have to tell individuals that they aren’t ready to be promoted just yet, that they aren’t getting a raise, that there’s no bonus this year.

The first main point is that being given a title does not equate to leadership. People have to want to follow you. Manager Tools, another great management/leadership resource that I frequently use, talks about it in terms of three forms of power: Relationship Power, Expertise Power, and Role Power - power meaning being able to get things done, or in leadership terms, the influence one has. They’re more or less what they sound like - relationship power is based on trust and interpersonal skills, expertise power is due to others knowing about your knowledge, and role power is based on title and comes from the organization. Ideally, you want to use them in that order - rely on relationship power as much as possible, expertise power when you have to, and role power when you have no other choice. You have some control over your relationship and expertise power, but not role power. In addition, using role power is basically a strong-arm move, and will leave the other party displeased; if you’re having to resort to “do it this way, because I’m the boss,” there’s likely something wrong with what you’re asking for. Even if you’re promoted to be “the boss,” you still have to work (hard) on relationships and knowledge.

The second part is about tough conversations. There are a lot of those that I’ve had to have over the years. From dealing with interpersonal conflicts, to explaining to someone who isn’t as self-aware the things they are doing wrong, to giving bad news about the company (like low/no raises), there are a lot of situations in which you will have to deliver bad news or deal with non-engineering matters that will upset your directs. In addition, early on I sometimes delayed having these tough conversations, because I was dreading how they would go. I’ve learned over time to “run to my problems” and get them over with sooner rather than later. Your team will normally want to know as early as possible, and leaving it for later just makes the stress last longer.

Practical Advice for Delegating Effectively

In this section, Camille goes into some detail on tips to delegate properly, and in a way that will be successful for both you and your direct. As someone who wasn’t always the best at delegating - and is still trying to improve - I found some good reminders in it. One of those was setting standards to be met. I find this extremely helpful for myself - for example, there’s a standard in my team that all code needs to be reviewed by a peer before shipping it to production. Everyone on the team is aware of it and has bought in. That allows me to keep my nose out of a level of detail I probably shouldn’t be in, and let the team do their best work, knowing that those peers will be enforcing quality standards with each other.

Another point that I’ve been personally working on lately is looking at the systems of record before asking for updates from individuals. If you’re a fan of something like Cal Newport’s idea of “Deep Work,” you probably want to leave your team alone as much as possible, so as to not cause additional disruptions that reduce productivity. Most software engineering teams have systems like Git and Jira that can be checked for updates, and where you as the manager can see how things are going. If the team is not updating those tools, that’s a different problem that should be addressed (back to setting standards). Ideally, tools like these are linked together, so it’s obvious what code changes are being made for each ticket, and a manager or peer can easily jump in and see what’s going on.

Finally, the encouragement of sharing information - no matter if it’s good or bad - is a big one for me. I’ve been involved in projects where team members were afraid to give a negative update and it almost always results in even worse problems. As a manager, you should want to know what’s going on as early as possible, so corrections can be made, resources added, etc. If you blow up on someone when they give you bad news, you’re discouraging them from coming forward with those things before it’s too late. Be understanding, trust your team, and look to how the issues were caused so you can think of how to prevent them in the future.

The Shield

The final section from the book I’ll visit is The Shield. It covers the idea that one of the roles of management is to protect the team from drama going on in the workplace, and unnecessary distractions. I agree with the author’s point that while this is often helpful, there are some situations where you need to address things head-on, even if it’s outside of your control, will be a drain on the team, or is even something you disagree with. Typically, this is because either knowing consequences for success or failure can be helpful motivation for the team - even if scary - or because the team is going to find out about the topic one way or another, and it’s better to hear it from their boss. Otherwise, it can feel like the organization doesn’t think it is important, doesn’t understand why they would care, or is pretending that it isn’t happening.

A recent example of this for me has been COVID-19, and some of the drama/issues that came from that as a result. There were many conversations like this during that time - how the company was doing financially, how our employees were doing health-wise, if and when we’d start working from home, when we’d be coming back to the office, and so on. I knew that these topics were going to be of great importance to the team, even if we had no real control over them, and I wanted to get in front of it and be available for questions to be asked - even if I didn’t know the answer, or if I had to deliver news I didn’t agree with or I knew would upset some folks. All in all, I know that was appreciated, and tried to deliver the news in a matter-of-fact way and prepare for questions that I knew would be coming.

On a related note to the drama, one part of my current role is to try to reduce the amount of projects my team is committed to. We are frequently dealing with being overextended and having too many projects going on at once, and I work to get potential projects declined when they are less business-critical, wouldn’t be worth the investment, and so on. Historically I’ve mostly done this behind the scenes so as not to distract my team, and keep them focused on the things we did commit to. However, that has an unintended consequence of the team thinking that we say “yes” to everything - since they only hear about those projects. As such, I’ve worked more recently to let at least the leads/seniors know about some of the projects we’re getting shut down for their sake.

Conclusion

All in all, I found this an enjoyable, practical read, with a lot of real-world advice. As someone who isn’t a big fan of the “inspirational quote”-type of leadership materials, I got a lot out of this, and appreciated the fact that it was relatively short and to-the-point. I’d recommend anyone who is interested in becoming a manager, or who already is one but wants to continue progressing, pick up a copy.