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

by Camille Fournier

But as a manager, you will have relationships that go deeper, and it’s more important to be kind. It’s kind to tell someone who isn’t ready for promotion that she isn’t ready, and back that up with the work she needs to do to get there. It’s unkind to lead that person on, saying “Maybe you could get promoted,” and then watch her fail. It’s kind to tell someone that his behavior in meetings is disrupting the group.

Don’t be afraid. Conflict avoidance often arises from fear. We’re scared of the responsibility of making the decision. We’re afraid of seeming too demanding. We’re afraid people will quit if we give them uncomfortable feedback.

Do get curious. Thinking about your actions is the best way to combat fear of conflict.

This is the underpinning of a successful team. The work of gelling a team begins by creating the friendliness that leads to psychological safety. You can encourage this by taking the time to get to know people as human beings and asking them about their extracurricular lives and interests. Let them share what they feel comfortable sharing. Ask how their child’s birthday party went, how their ski trip was, how their marathon training is going.

The best thing you can do for your team, in the context of having a brilliant jerk, is to simply and openly refuse to tolerate bad behavior. This may be one of the few instances where “praise in public, criticize in private” is upended. When a person is behaving badly in a way that is having a visible impact on the team, and a way you don’t want your culture to mimic, you need to say something in the moment to make the standard clear. “Please do not speak to people that way; it is disrespectful.” You’ll want to have tight control of your own reaction because delivering this in public is walking a fine line. If you seem emotional, it may undermine you. The offender may write off your feedback as just emotion, or you may come off as picking on the person. Keep the feedback neutral but to the point if you are going to deliver it in the moment, in public.

Your first goal is to protect your team as a whole, the second is to protect each individual on the team, and your last priority is protecting yourself.

The Noncommunicator Another very common problem team member is the noncommunicator — the person who hides information from you, from his teammates, from his product manager.

If possible, address the root cause of the hiding. If the hider is afraid of being criticized, does your team have a harsh culture that needs to be addressed? Does your team have that psychological safety in general? Is the rest of the team treating this person like an outsider, perhaps because he has a different background or skill set?

The Employee Who Lacks Respect 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.

Advanced Project Management As an engineering manager, you will help set the schedule for your team. As the larger organization tries to figure out what the plans for the quarter or year might look like, you’ll estimate whether your team can do certain projects, how much work those projects will be, and whether you have the right people to complete the work. You might be asked if your team can take on the support of old systems in addition to their current commitments, or how many people you’d need to hire in order to support a new initiative. The organization will expect you to be capable of doing both off-the-cuff estimation and more concrete project planning.

day. As the manager, you’re not trying to disrupt or even own that part of the execution process. However, you are responsible for the larger picture — the accomplishments that are measured in months instead of weeks — and this is where you have to start exerting some higher-level planning.

You have 10 productive engineering weeks per engineer per quarter There are 52 weeks in a year, or about 13 per quarter. However, realistically your team will lose a lot of that time. Vacations, meetings, review season, production outages, onboarding new employees — all of these things take away from focus. Don’t expect to get more than 10 weeks’ worth of focused effort on the main projects per team member per quarter. It’s likely that Q1 (immediately after the winter holidays) will be the most productive and Q4 (the quarter that includes winter and the end-of-year holidays) will be the least productive. Budget 20% of time for generic sustaining engineering work across the board By “generic sustaining engineering work,” I mean testing, debugging, cleaning up legacy code, migrating language or platform versions, and doing other work that has to happen.

As you approach deadlines, it is your job to say no You will almost certainly have occasional deadlines, either goal dates that you’ve set or goal dates that came down from on high. The only way to achieve these goals is to cut scope at the end of the project. That means that you, as the engineering team lead, will partner with your tech lead and the product lead/business representative to figure out what “must-haves” are not actually must-haves. You will have to say no to both sides.

There will be product features that require significant engineering complexity to implement, and you’ll need to work with the product team to figure out the real must-haves while explaining the cost to get to their vision. When push comes to shove, you’ll be the person to give the team options as to what can realistically be implemented, or how much more time getting everything in will require.

Use the doubling rule for quick estimates, but push for planning time to estimate longer tasks The popular doubling rule of software estimation is, “Whenever asked for an estimate, take your guess and double it.” This rule is appropriate and good to use when you’re asked for an off-the-cuff guess. However, when you’re talking about projects that you think will take longer than a couple of weeks, go ahead and double the estimate, but make it clear that you’ll need some planning time before you’re sure about the timescale.

Part of the reason that I stress your role in this estimation and planning process is that it’s distracting and stressful for engineers to have a manager who’s constantly asking them for random project estimates. As the manager, you’re responsible for handling uncertainty and limiting how much of that uncertainty you expose to your team. Don’t be a telephone between the engineers and the rest of the company, parroting messages back and forth and distracting people who are busy with the important tasks you’ve already committed to do. But you’re not a black hole, either. Try to get a teamwide process in place for talking about new features and customer complaints, and limit estimations that occur outside of this process.

Ask the CTO: Joining a Small Team I’m a newly hired manager for a team of five engineers. I have been a manager before at other companies, but I’m brand new to the company, the technology, and the team. How should I think about my time in these first few weeks? Joining a small team as a manager is tough. It’s one thing to balance technical work when you’ve been promoted to manager from software engineer, but it’s another thing to come in new with a team to manage and new code to learn. There are a few ways to get into the software without annoying the team. First, get someone to walk you through the systems and architecture, as well as the process for testing and releasing the software. If there is a normal developer onboarding process where you learn how to check out code and deploy the systems, go through that process. Spend some time getting comfortable in the code bases, and start watching the code reviews or pull requests, if they exist. Plan to work on at least a couple of features in your first 60 days. Take a specced-out feature and add it. Pair with one of the engineers on a feature he’s working on, and have him pair with you as you start working on a feature of your own. Get your code reviewed by a member of the team. Perform a release, and do a rotation of supporting the systems for at least a couple of days if support is part of the team’s responsibilities. You can probably tell that this means your management onboarding may go more slowly because you’re also l...

I took pains to make sure that we called out the fact that engineering directors would not necessarily be writing code every day, because I believe that it is very difficult for a person responsible for hands-on management of multiple teams to write code. Your schedule, by this point, has probably moved away from “maker” and firmly into “manager.” Between your 1-1s, meetings with other engineering leads, team planning sessions, and sessions with your peers in product management or other business functions, you’re probably quite busy. Be realistic about your schedule at this point. If you don’t have solid blocks of time to dedicate to it and you can’t realistically guarantee solid blocks of time at least a few days a week, any code you write is going to be very slow-going. Fortunately for us, there are ways to stay hands-on that don’t require writing a lot of production code. Code reviews are a good thing to stay in practice with, at least as a secondary reviewer. If you created systems when you were more hands-on, stay engaged with those systems, because you’ll remember the details better than most, and you can help engineers working in those systems with code reviews and questions. Debugging and production support are also valuable. How you stay hands-on depends on your skill set. If you were not a strong debugger before you went into management, jumping into incidents may be more annoying than useful. You may be more helpful doing pair programming, or fixing minor bugs o...

I’m managing two complex teams and my management responsibilities are forcing me to step back from technical responsibilities. I find that I miss code terribly. Is this a sign that I shouldn’t be a manager? Almost everyone who goes from a heavily hands-on technical role into management has a transition period where they question frequently whether they’ve made a mistake.

David Allen’s book Getting Things Done1 to be useful to think about, and I recommend reading it even if you don’t adopt the whole process.

Table 6-1. Prioritizing your time Not urgent Urgent Important Strategic: make time Obvious work Unimportant Obvious avoid Tempting distractions

prepare in whatever way makes sense. Ask for agenda items up front. Any sort of standard meeting that involves a group of people, whether it’s planning, retrospective, or postmortem, should have a clear procedure and expected outcomes.

One of the major changes at this level compared to the previous level is that your boss will expect you to be mature enough to manage yourself and your teams independently. This means that your manager trusts you to proactively deal with all those important but not urgent things before they become urgent, and especially before they become urgent for your manager. No one will tell you how to manage your calendar to give yourself the time to do this. I’ve seen managers fail at this point because they just could not juggle all the different tasks in an organized fashion.

Meetings can fall into that urgent but not important category, and you may decide to simply not attend them where you’re not clearly needed. Be very careful with over-deploying this strategy at this particular level of management. The responsibility of keeping your teams successfully moving forward and happily engaged is on your shoulders. When you stop going to all of their internal meetings, you run the risk of missing out on the very clues that will help you catch problems early — a major one being the existence of too many boring meetings. During meetings, look around the room at your team and notice their engagement. If half of them are falling asleep, staring off into space, on their phones or laptops ignor...

As you navigate your new obligations, start to ask yourself: How important is the thing I’m doing? Does it seem important because it is urgent? How much time have I spent this week on urgent things? Have I managed to carve out enough time for things that are not urgent?

The Hardest, Shortest Lesson of Becoming a Manager As a manager, I have this mental list of things about what my team needs. Things that I’m monitoring, things that I’m trying to fix, things that I’m trying to find for them. It’s my job to understand what is going on and what the team as a whole needs to be effective. Maybe you can look at the state of things and say, “We have a deadline right now, and what we need is another engineer for the next month. That engineer is me.” But more likely you look at the state of things and realize that what your team needs is a manager. Because you need to hire X more people. Because Y has a lot of potential but needs some coaching. Because product or design or some other team hasn’t given you what you need, so you need to go and get it. Because process is important, and the process you have is insufficient or just plain wrong. If your team needs a manager more than they need an engineer, you have to accept that being that manager means that you by definition can’t be that engineer. I know some people manage both, but you need to decide, if you’re going to suck at one, which one that will be. I feel bad when I suck at being an engineer, but sucking at being a manager would be a choice I inflicted on other people. That’s not fair. So at the end of another day when I feel like I didn’t write enough code and I have no way to quantify what I’ve achieved, I tell myself I was being as good a manager as I know how to be. And that has to be en...

Table 6-2. Deciding when to delegate or do it yourself Frequent Infrequent Simple Delegate Do it yourself Complex Delegate (carefully) Delegate for training purposes

Are your teams learning how to operate independently, or are you keeping them dependent on you for critical functions? List the tasks that you and only you really know how to do for the team. Some of them may be appropriate, like writing performance reviews or making hiring plans, but many of them are important to teach your teams to accomplish themselves. Project management. Onboarding new team members. Working with the product team to break down product roadmap goals into technical deliverables. Production support. These are all skills members of your team need to learn. Teaching them may take time up front, but in the long run it will save you time. Not only that, but teaching your team how to do these things is part of your job. It is your responsibility, as a manager, to build up the talent in your organization, and to help your people learn new skills they’ll need for the next stages of their careers.

There are definitely signals that you start to notice after you’ve been managing for a while. Here are some I’ve learned to spot: The person who is usually chatty, happy, and engaged suddenly starts leaving early, coming in late, taking breaks to leave during the workday, staying quiet in meetings, and not hanging out on chat. This person is either having a major personal issue or getting ready to quit. Usually, people will tell someone when there is a personal issue (such as a sick relative, relationship problems, or health issues), but not always. If this happened right after a major adjustment, such as a promotion, a team reorganization, or other event, the person may feel that she was overlooked. Regardless of the reason, you may want to have an honest conversation and try to get to the root of the issue before she resigns. The tech lead claims that everything is going well, but skips your 1-1s frequently and rarely provides detail in his status updates. This person may be hiding something. Often what he’s hiding is that the progress is going far slower than he anticipated, or he’s building something outside of the scope of the project. Help him create a clear project plan early and set expectations for how to adjust that plan when things change, so that it’s harder for him to hide a lack of progress. Also help him clarify the project’s goals and scope, which can be daunting for some new tech leads. You may have experienced something similar when managing new hires who...

Saying no to your boss rarely looks like a simple “no” when you’re a manager. Instead, it looks like the “yes, and” technique of improvisational comedy. “Yes, we can do that project, and all we will need to do is delay the start of this other project that is currently on the roadmap.”

Create Policies When it comes to your team, you want to help them understand what it takes to get to “yes.” Perhaps you are dealing with an engineer who wants to switch to a new programming language for a project, one that your team doesn’t use. He has some great arguments as to why this language is the perfect tool for the job, but you’re reluctant to add a new tool just because it’s perfect. You might be tempted to just say no, give the reasoning, and leave it, and sometimes that will work. But you may find yourself saying the same “no” over and over again, giving the same reasons. “No, we need to have more people who know that language; we need to understand what it means to put that language into production.” “No, we need to have standards for logging; we need to think about what testing would look like.” When you start repeating yourself, you have the basis for a reasonable policy. That policy consists of the hard requirements that must be met in order to say yes, and some guidelines for thinking about the decision. Making a policy helps your team know in advance the cost of getting to “yes.” “Help Me Say Yes” Policies are useful, but they don’t cover every case. The next strategy, “help me say yes,” is similar to policy writing, but works better for the one-off instances where there is no clear policy. Sometimes you’ll hear ideas that seem very ill-considered. “Help me say yes” means you ask questions and dig in on the elements that seem so questionable to you. Often...

Don’t Prevaricate When you know that you need to say no, it’s better to say it quickly than to delay and drag out the process. If you have the authority to say no, and you don’t believe something should happen, do yourself a favor and don’t agonize over the process. You’ll be wrong sometimes, so when you discover that you were too quick to say no, apologize for making that mistake. You won’t have the luxury to carefully investigate and analyze every decision, so practice getting comfortable with the quick no (and the quick yes!) for low-risk, low-impact decisions.

The popular management book First, Break All the Rules2 discusses several questions you can answer to help predict team productivity and satisfaction. Among them are: Do I know what is expected of me at work? Do I have the materials and equipment I need to do my work right? Do I have the opportunity to do what I do best every day?

These health signals — frequency of code releases, frequency of code check-ins, and infrequency of incidents — are the key indicators of a team that knows what to do, has the tools to do it, and has the time to do it every day.

Why don’t you release more frequently? Take a look at your team. If they don’t release continuously, or daily, what does the release process look like? How long does it take? How often has something gone wrong in the past few months regarding releases? What does it look like when things go wrong? How often have you had to delay or roll back a release due to problems? What were the impacts of that delay or rollback? How do you determine if code is ready to go into production? How long does that take? Who is primarily responsible for determining this?

Here’s the thing. Is your team working to its full capacity? Are your engineers challenged and growing? Is your product team excited by the progress you’re making? Are people able to spend most of their time on writing new code and evolving the systems? If so, great. Ignore me. You’ve got it under control. If not, you have a problem, and you’re ignoring that problem at your peril. It’s important to remember that, as a technical leader, while you may not be writing code much, you’re still responsible for the technical side of getting work done. You’re also responsible for keeping your team happy and productive, and often the solution to this is not cheerleading or paying them better or praising them more, but instead enabling them to be more productive, challenging them to go faster and do better work, and helping them find the time they need to make their work more interesting. You have to be the advocate and push for technical process improvements that can lead to increased engineer productivity, even if you’re not implementing them all yourself.

You may work for a company that has developers support the code or systems they write. This process has some downsides; significantly, expecting members of a team to frequently be on-call nights and weekends is a huge contributor to burnout. Despite that risk, it has the upside of putting the best people to help fix a problem in the role of responding to it. As a manager, you may be tempted now to take yourself out of this role. I sympathize, but if your team is set up to do its own incident management, you should be moving yourself into the role of escalation support.

It can be hard for new managers to create a shared team identity. Many of them default to an identity built around the specifics of their job function or technology. They unite the team by emphasizing how this identity is special as compared to other teams. When they go too far, this identity is used to make the team feel superior to the rest of the company, and the team is more interested in its superiority than the company’s goals. Rallying a team in this way is a shallow binding that is vulnerable to many dysfunctions: Fragile to the loss of the leader. In-group teams tend to be very fragile to the loss of their leader. When you hire a manager who builds a clique, that clique is likely to dissolve and leave the company if the manager leaves the company. This problem makes it that much harder to address the problems that the manager is causing by creating a clique in the first place. Resistant to outside ideas. In-groups tend to be resistant to ideas that do not come from those within the group. This means that they miss opportunities to learn and grow. The lack of growth for members of the team often causes the best members of the team to leave not just the group, but the company. Because they believe they’re in the best group but they still find themselves bored, they don’t appreciate the growth they could find just by switching to a new team. Empire building. Leaders who favor an us-versus-them style tend to be empire builders, seeking out opportunities to grow their ...

As a manager, be careful about focusing on your teams to the exclusion of the wider group. Even when you have been hired to fix a team, remember that the company has gotten this far because of some fundamental strengths. Before you try to change everything to fit your vision, take the time to understand the company’s strengths and culture, and think about how you’re going to create a team that works well with this culture, not against it. The trick is not to focus on what’s broken, but to identify existing strengths and cultivate them.

Durable teams are built on a shared purpose that comes from the company itself, and they align themselves with the company’s values (see “Applying Core Values” in Chapter 9 for more on this topic). They have a clear understanding of the company’s mission, and they see how their team fits into this mission. They can see that the mission requires many different types of teams, but all of the teams share a set of values. By creating a strong and enduring alignment between the team, its individuals, and the overall company, this purpose-based binding makes teams: Resilient to loss of individuals. While the clique is fragile, especially to the loss of the leader, the purpose-driven team tends to be very resilient to the loss of individuals and leadership. Because they’re loyal to the mission of the larger organization, they can see a path forward even through loss. Driven to find better ways to achieve their purpose. Purpose-driven teams are more open to new ideas and value changes that can help them serve their purpose better. They care less about the source of an idea than its merit in achieving their goals. The members of these teams are interested in learning from others outside their function, and they actively seek out chances to collaborate more broadly to create the best results. First-team focused. Leaders who are strong team players understand that the people who report to them are not their first team. Instead, their first team is their peers across the company. This...

As you grow more into leadership positions, people will look to you for behavioral guidance. What you want to teach them is how to focus. To that end, there are two areas I encourage you to practice modeling, right now: figuring out what’s important, and going home.

fun stuff is the work that uses most of your brain, and it’s not usually something you can do for hours and hours, day after day. So be impatient to figure out the nut of what’s important. As a leader, any time you see something being done that feels inefficient, question it: Why does this feel inefficient to me? What is the value in the thing we are doing? Can we deliver that value faster? Can we strip down this project into something simpler and get it done more quickly? The problem with this line of questioning is that often when managers ask whether something can be done faster, what they explicitly or implicitly want to know is whether the team can work harder or longer hours to deliver it in fewer days. This is why I encourage you to develop and show the value of laziness. Because “faster” is not about “the same number of hours but fewer total days.” “Faster” is about “the same value to the company in less total time.” If the team works 60 hours in a week to deliver something that otherwise would’ve taken a week and a half, they haven’t worked faster, they’ve just given the company more of their free time. This is where going home comes in. Go home! And stop emailing people at all hours of the night and all hours of the weekend! Forcing yourself to disengage is essential for your mental health, believe me. Burnout is a real problem in the American workforce these days, and almost everyone I know who has worked sustained excess hours has experienced it to some degree....

You’ll get a whole new sense of your strengths and weaknesses as you work at this level. People who are good at managing a single team, or even a couple of related teams, fall apart when asked to manage managers, or teams that are outside of their skill set. They’re unable to balance the ambiguities inherent in their new role, and fall back into things that they find easy. Sometimes this reveals itself as falling back into spending too much time playing individual contributor. Sometimes it shows up as a person playing project manager instead of training their managers to do that job themselves.

Skip-Level Meetings Skip-level meetings are one of the critical keys to successful management at levels of remove. And yet many people skip or undervalue them. I know, I’ve been there. No one wants to add yet more meetings to their calendar, especially the type that are often without an agenda. Still, if you want to build a strong management team, understanding the people who report to those managers and maintaining a relationship with them is hard to avoid. What is a skip-level meeting? Put briefly, it is a meeting with people who report to people who report to you. There are a few different ways that people hold these meetings, but their purpose is to help you get perspective on the health and focus of your teams. However you choose to hold them, keep this purpose in mind. One form of skip-level meeting is a short 1-1 meeting, held perhaps once a quarter, between the head of an organization and each person in that organization. This tactic accomplishes a couple of things. It creates at least a surface-level personal relationship between you and everyone in your organization, which keeps you from viewing them as “resources” instead of human beings (something that is a risk in managing large organizations). It also gives those individuals time to ask you questions that they may not feel are worth scheduling a meeting themselves to ask. These meetings are most successful when you provide prompts about potential topics, and remind the person that the meeting is largely for h...