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

by Camille Fournier

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.

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 ignoring the proceedings, or otherwise disengaged, the meeting is wasting their time.

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.

Delegation is the primary way you claw yourself out of the feeling of having too many plates spinning at once. As tasks come at you, ask yourself: do I need to be the person who completes this work? The answer may depend on a few factors (see Table 6-2). 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 The degree of complexity and the frequency of the task can act as guides to determining whether and how you should delegate.

If the task is simple and frequent, find someone to whom you can hand it off. Examples of simple and frequent tasks might include running daily standups, writing up a summary of the teams’ progress each week, or conducting minor code reviews. Your tech leads or other senior engineers can take responsibility for these tasks and probably won’t even need training to do so.

If it’s faster to do something yourself than it would be to explain it to someone else and it rarely needs to be done, roll up your sleeves and do it, even if you deem the task beneath you. This can be anything from booking the occasional conference ticket for your team to running the script that generates quarterly reports.

Tasks like writing performance reviews and making hiring plans are yours alone. However, these are also the skills you will want to pass on to rising managers. You may have a tech lead sit with you to write the performance review for an intern, or have a senior engineer provide feedback on how many new people he believes would be needed to support a project next year.

Delegate Complex and Frequent Tasks to Develop Your Team Tasks like project planning, systems design, or being the key person during an outage are the biggest opportunity you have to grow talent on your team while also making the team run better. Strong managers spend a lot of their time developing members of their teams in these areas. Your goal is to make your teams capable of operating at a high level without much input from you, and that means they’ll need individuals who can take over these complex tasks and run them without you around.

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.

Delegation is a process that starts slow but turns into the essential element for career growth. If you teams can’t operate well without you around, you’ll find it hard to be promoted. Develop your talent and push decisions down to that talent so that you can find new and interesting plates to learn how to spin.

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.

The team has absolutely no energy at all in their meetings. In fact, the meetings feel like a total slog, with the product manager and tech lead doing all of the talking while the rest of the team sits silently or speaks only when called upon. A lack of engagement in meetings tends to mean the team isn’t engaged by the work or do not feel like they have a say in the decision-making process.

“Yes, and” 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.” Responding with positivity while still articulating the boundaries of reality will get you into the major leagues of senior leadership.

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,” 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, this line of questioning helps people come to the realization themselves that their plan isn’t a good idea, but sometimes they’ll surprise you with their line of thinking. Either way, curious interrogation of ideas can help you say no and teach at the same time.

when you give an implied promise that “not right now” means that you’ll seriously do something “later,” you need to be sure that later can actually happen.

there will be times when you and your peers (particularly across functions — i.e., your product or business peers) will need to act together to say no. This can apply to a no at any level. Sometimes you will use your technical authority to say no in a way that is beneficial to the product team. Sometimes you will appeal to the finance department to help you say no to certain budget excesses. Playing good cop/bad cop can be a little bit dishonest, so use this sparingly, but it can be useful to lend your authority to a no and then be able to call in the favor when you need support for your own no in the future.

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.

so practice getting comfortable with the quick no (and the quick yes!) for low-risk, low-impact decisions.

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?

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.

Interrogate every process to determine the value it should provide, and always ask yourself if it can be automated further.

In this modern era, frequency of code change is one of the leading indicators of a healthy engineering team.

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?

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.

If you’re building a brand new product for a small but growing business, it may be more important to focus on features over stability. On the other hand, if you own mission-critical systems, stability and incident minimization may be your top priority.

“Is our current setup enabling my team to do what they do best every day?”

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.

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 first-team focus helps them make decisions that consider the needs ...

In startups especially, there is often some confusion about the current goals and even sometimes the underlying mission. In the case where the goals are fuzzy and the mission is unclear, do your best to understand the company culture and think about how you can set your teams up to work well within that culture.

“laziness, impatience, and hubris” are virtues of engineers, as he articulated in Programming Perl.3 These virtues persist into leadership, and learning how to channel these traits into advantages is something I encourage all managers to do.

But impatience paired with laziness is wonderful when you direct it at processes and decisions. Impatience and laziness, applied to process, are the key elements to focus.

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.

Can I do this faster? Do I need to be doing this at all? What value am I providing with this work?

When was the last time you reviewed your schedule for things that you’re doing but that aren’t providing a lot of value for you or your team?

When was the last time you pushed your team to cut the scope of a project? When you cut scope do you cut features, technical quality, or both? How do you decide?

you’ll need to practice honing your instincts, and this practice will require you to follow through on things that you’re not sure are actually important, but you just sense are off.

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.

Except this basically never happens. The open-door policy is nice in theory, but it takes an extremely brave engineer to willingly take the risk of going to her boss (or especially her boss’s boss, etc.) to tell him about problems.

What do you like best/worst about the project you are working on? Who on your team has been doing really well recently? Do you have any feedback about your manager — what’s going well, what isn’t? What changes do you think we could make to the product? Are there any opportunities you think we might be missing? How do you think the organization is doing overall? Anything we could be doing better/more/less? Are there any areas of the business strategy you don’t understand? What’s keeping you from doing your best work right now? How happy (or not) are you working at the company? What could we do to make working at the company more fun?

What can I, your manager’s manager, provide for you or your team? Anything I should be helping with? Is this team working poorly with any other teams, from your perspective? Are there any questions about the larger organization that I can answer?

Whether you have experienced managers or first-timers reporting to you, there is one universal goal for these relationships: they should make your life easier.

Here are some tricky but common scenarios I’ve experienced: Unstable product roadmap The team doesn’t feel very productive, the systems are unstable, and there is some attrition happening, but the product organization keeps changing the goals for the team and everything is always an urgent mandate. Is the manager accountable? Errant tech lead The tech lead has been down a rabbit hole trying to redesign one of the core systems. The design doc is still barely started, and work is piling up, but the tech lead insists that this is a big problem that can’t be rushed. Is the manager accountable? Full-time firefighting mode The manager inherited a team with a bunch of legacy systems that are constantly broken, and the team seems to spend all their time fighting fires. They also support other teams who are using those systems, and the other teams are constantly asking for help and distracting the team with requests. There’s a roadmap to move out of these systems, but you haven’t heard any reports on the progress against this roadmap, and you know the team is killing themselves to keep things stable and manage the support requests. Is the manager accountable? The answer to all of these questions is yes. Yes, despite the mitigating circumstances in each case, the manager ultimately needs to take responsibility for pulling the team out of these situations and getting them moving forward, because the manager is accountable for the health and productivity of the team.

Everyone agrees that he makes plenty of time for anyone who wants it, and will listen for as long as you need him to. Bring him any problem, and he promises to make it right. Since he took over the organization, you feel like your concerns are really being heard. However, he never seems to get around to fixing those problems. The colleague you complained about still got promoted. The product team is still railroading you. The goals still don’t make any sense. But Marcus is so busy, you can’t blame him; after all, there are just so many problems he’s dealing with.

Her team loves her as a person but is increasingly frustrated with her as a manager, because she hides problems from them and tries to shield them from the external world.

The therapist people pleaser can inspire huge loyalty on his team because of his willingness to hear what you are upset about, and his genuine concern for your emotional well-being. Unfortunately, this can mean he amplifies drama and negativity, and disappoints his team by making promises to them that he cannot possibly keep.

Despite wanting to please, she frequently doesn’t provide much praise or feedback to her teams internally. This may seem surprising, but this people pleaser struggles to have difficult conversations internally so she avoids talking about serious issues within the team, and this can actually lead to a refusal to acknowledge good work as well as problems.

A team pleaser sets her team up to fail by promising things that aren’t realistic, and the result is often a team that feels extremely bitter toward either the manager or the company for failure to live up to these inflated expectations.