The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change

by Camille Fournier

Great managers notice when your normal energy level changes, and will hopefully care enough to ask you about it.

Being an introvert is not an excuse for making no effort to treat people like real human beings, however. The bedrock of strong teams is human connection, which leads to trust.

You should expect your 1-1s to be scheduled with some predictability so that you can plan for them, because it is not your manager’s job to completely control the 1-1 agenda.

I encourage you to share the responsibility of having good 1-1s with your manager. Come with an agenda of things you would like to discuss.

Ideally, the feedback you get from your manager will be somewhat public if it’s praise, and private if it’s criticism.

Good managers know that delivering feedback quickly is more valuable than waiting for a convenient time to say something.

Asking your manager for advice is also a good way to show that you respect her. People like to feel helpful, and managers are not immune to this sort of flattery.

Your manager should be the person who shows you the larger picture of how your work fits into the team’s goals, and helps you feel a sense of purpose in the day-to-day work. The most mundane work can turn into a source of pride when you understand how it contributes to the overall success of the company.

In whatever way promotions happen, your manager should have an idea of whether you are qualified to be promoted. When you are interested in being promoted, it’s very important to ask your manager for specific areas to focus on in order to get that promotion.

Developing a sense of ownership and authority for your own experiences at work, and not relying on your manager to set the entire tone for your relationship, is an important step in owning your career and workplace happiness.

When you are persistently unhappy, say something. When you are stuck, ask for help. When you want a raise, ask for it. When you want a promotion, find out what you need to do to get it.

you find yourself starting to actively resent your manager for whatever reason, you probably need to move to a different team or look for a new job. If you find yourself resenting every manager you work for, you may need to think about whether the cause is them or you. Perhaps you’d be happier in a job where you don’t have a manager.

Especially as you become more senior, remember that your manager expects you to bring solutions, not problems. Try not to make every 1-1 about how you need something, how something is wrong, or how you want something more. When you have a problem, instead of demanding that your manager solve it for you, try asking her for advice on how she might approach the problem. Asking for advice is always a good way to show respect and trust.

weak mentors who do little but ignore their charges, waste their time with trivial projects, or, worst of all, intimidate and belittle them out of ever wanting to join the organization.

when your mentee is speaking to you, pay attention to your own behavior. Are you spending all your time thinking about what you want to say next? Are you thinking about your own work? Are you doing anything other than listening to the words coming out of his mouth? If so, you’re not listening well.

if the intern does spend too much time asking you for help, without ever looking for help himself? Well, that gives you an opportunity to work on another management skill: communicating what needs to happen. If you expect him to do research on his own before asking you a question, tell him so! Ask him to explain a piece of code to you, or some product or process, and point him to the documents that you believe explain it. If he can’t do it even with pointers, well, you’re starting to learn something about the potential of this intern. If all else fails, give him the first milestone of the project and tell him to work on it alone for a day or two. Therein lies the value of breaking the project down before the intern starts working on it: you’ve taken on some of the harder thinking up front. He may surprise you by finishing everything much faster than you anticipated, but what a happy surprise to have! Generally, you’ll need to provide some nudging and clarity along the way to keep the intern going in the right direction.

I promise you that interns who feel like the company appreciated their work are the ones most likely to come back after they graduate.

We did some pair programming so that I could learn the code base, and the way that testing worked for this project (my first taste of unit testing!).

She tends to undermine the people who work for her by belittling their mistakes and, at her worst, redoing the work of her teammates without warning.

Because this is an additional responsibility, treat it as you would any other important additional responsibility you might hand out. Look for someone that you believe can succeed in the role, and who wants to distinguish herself beyond her coding ability.

Don’t hire interns who are not going to graduate in the year after their internship.

pragmatic urgency was the deciding factor.

I watched him go down rabbit hole after rabbit hole, and in the meantime, the product manager took advantage of his absence to railroad the rest of the team into committing to feature delivery that was both poorly designed and way too aggressive.

not only do I have to influence my peers, but I also have to influence up to my manager to ensure we are prioritizing the right work.

Teams often fail because they overworked themselves on a feature that their product manager would have been willing to compromise on. As a large project nears its delivery date, there will be compromises on functionality.

How would we make it work in the complex testing framework we depended on?

I want to be building and getting value, not trying to think about how to break down a project that still has very fuzzy implementation details. I’m afraid that I will be held accountable and that I could miss something important in the process that will make the project fail. But the alternative is the project failing slower, not faster.

you enforce the self-discipline to think about the project in some depth before diving in and seeing what happens. A degree of forethought, in places where you can reasonably make predictions and plans, is the goal. The plan itself, however accurate it turns out, is less important than spending time on the act of planning.

only because I had taken the trouble to explain the basic ideas of the problem space and the motivations behind my ideas. I have never forgotten this lesson. Since then, after many years working in software and in large organizations, I have come to appreciate those comments even more.

If the changes add significant risk to the project, necessitate a bunch of new planning, or simply require a lot of additional work, be clear about the cost of those changes.

constantly push new tools and processes on the team as solutions to the messier problems of human interactions.

It’s almost impossible to lead projects well when you don’t understand the architecture you’re changing.

Look at the tricky, boring, or annoying areas of technical need and see if you can unstick those areas. Working on the less exciting parts of the code base can teach you a lot about where the process is broken.

you needn’t always be self-sacrificing in what you choose to work on. Give yourself a fun task occasionally, as long as you know you have the time to do it well.

Determine which decisions must be made by you, which decisions should be delegated to others with more expertise, and which decisions require the whole team to resolve.

If you start focusing a lot of energy on hearing reports’ complaints and commiserating, you’re quite possibly making the problem worse. You don’t have to have a to-do list, but problems in the workplace need to be either dealt with or put aside by mutual agreement. There is very little value to repeatedly focusing on drama.

The worst micromanagers are those who constantly ask for information they could easily get themselves. It’s OK to ask for status summaries and OK to use your team as a way of surfacing the most important information from all of these sources, but use a light touch.

Even better, look for something to recognize weekly for everyone who reports to you.

Try to account for the whole year, not just the past couple of months This will be easier if you keep notes on what has happened with each person throughout the year. One tactic is to keep a running summary of your 1-1s,

Here are some examples of themes that I have seen. There are people who: Struggle with saying no to distractions and end up helping with other projects instead of finishing their own Do good work but are hard for others to work with, tending to be overly critical or rude in meetings, code reviews, or other collaborative activities Struggle to break their work up into intermediate deliverables, and don’t balance planning and design with getting things done Work well with other engineers but do not work well with other departments or teams Struggle to follow the accepted best practices of the team, cut corners, or otherwise do sloppy work

Your job with this group is to make sure that they’re learning how to estimate their own work, getting it done roughly within the estimates, and learning from their mistakes. The evidence for promotion often takes the form of projects or features they’ve completed independently, participation in on-call rotations or other support, and engagement in team meetings and team planning.

Generally, you want to make sure that long-term employees are capable of doing their day-to-day work independently, without a lot of oversight or help. However, once people have gotten past these up-or-out career points, what do you do when they get stuck?

This book is for engineering managers. It’s not a generic management book. Engineering management is a technical discipline, not just a set of people skills. As you progress in your career, even though you may stop writing code, your job will require that you guide technical decision making. Even with architects who design the systems or other senior technical staff who are in charge of the details, as the manager of a team, you have the job of holding those people accountable for their decisions, of making sure that the decisions pass the technical smell test and have been balanced against the overall context of the team and the business. Technical instincts honed over years of doing the job are very important for guiding that process.

However, at this level, if you don’t stay in the code, you risk making yourself technically obsolete too early in your career. You may be on a management career path, but that doesn’t mean that you should wash your hands of technical responsibilities. In fact, I mention specifically in my engineering lead job description that I expect managers at this level to implement small features and bug fixes.

A common example is that your team only tries to release changes to production once a week or less. Infrequent releases can hide pain points such as poor tooling around releases, heavily manual testing, features that are too big, or developers who don’t know how to break their work down. Now that you’re managing the team, start to push for the removal of these bottlenecks.

Toward the end of the process, I pushed the team to make improvements that allowed us to release daily. The impact of this change on the team was immediate. It turns out that releases can be a point of resource contention. When people are contending for a scarce resource, conflicts and unhappiness among team members are almost inevitable. Making the code-shipping resource far less scarce immediately improved team morale.

My advice is to dedicate 20% of your time in every planning session to system sustainability work (“sustainability” instead of the more common “technical debt”). In a case where overwork is due to a pressing, time-critical release, remember two things. First, you should be playing cheerleader. Support the team however they need supporting, especially by helping out with the work yourself. Order dinner. Tell them you appreciate the hard work. Make it clear that they’ll have explicit break time after the push. Make it as fun as you can in the moment. Sometimes a crunch period can serve as a bonding experience for a team. But they’ll remember whether their manager was with them during the stressful period, or off somewhere else, doing her own thing.

When put in such stark terms, it seems pretty clear that Jason is not handling conflict well, while Lydia is taming it. While it seems like Jason’s democratic style should lead to an empowered team, his inability to say no or to take the responsibility for any decisions means that no one feels very secure. It’s hard to know what’s going to happen next on Jason’s team because instead of guiding the team, he’s having the team guide itself. Having a team that is constantly bickering and disagreeing is painful, and can be very dysfunctional.

Don’t rely exclusively on consensus or voting.

The third type of toxic individual is the person who simply doesn’t respect you as a manager, or who doesn’t respect her teammates. Addressing this person will be difficult and you may require some help from your manager, but if you can handle this yourself, it’s a sign of great character. Simply put, if your team member doesn’t respect you or her peers, why is she working there? Ask her if she wants to be working on your team. If she says she does, lay out what you expect, clearly and calmly. If she says she doesn’t, start the process to move her to another team, or help her leave the company. That’s it? That’s it. You can’t have a person working for you who doesn’t respect you, or doesn’t respect your team. It will eat away at the cohesion of the rest of the team as they wonder whether that person is right in not respecting you. The sooner you pull off the Band-aid, the better.