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

by Camille Fournier

The negative person is easier to deal with than the brilliant jerk. Make it clear to him that the behavior has to change, bring clear examples, and provide corrective feedback quickly after things happen. Sometimes the negative person is just unhappy and the best thing to do is to help him leave the team on good terms; you must be prepared for this outcome. Other times, the person has no idea about the impact he’s having on the team, and a quick chat will be all that’s needed to curtail the incidents. Be careful that vocally negative people don’t stay in that mindset on your team for long. The kind of toxic drama that is created by these energy vampires is hard for even the best manager to combat. The best defense is a good offense in this case, and quick action is essential.

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.

If your team isn’t working well together, look into creating some opportunities for them to hang out without it being all about work. Taking the whole team to lunch, leaving work early on a Friday afternoon to attend a fun event together, encouraging some PG-rated humor in chat rooms, and asking people how their lives are going are all ways to cultivate team unity. As a new manager I was pretty reluctant to get into this type of bonding, but even most introverts want to have a feeling of relatedness with their team. Assuming you don’t have any of the “people drama” problems listed earlier, small efforts in this area can warm the group up considerably.

So, yes, shielding your teams from distraction is important. Or, to put it another way, helping them understand the key important goals and focusing them on those goals is important. However, it’s unrealistic to expect that you can or should shield your team from everything. Sometimes it’s appropriate to let some of the stress through to the team. The goal is not to stress them out, but to help them get context into what they’re dealing with. The extreme shielders think they can best focus and motivate their teams by giving clear goals. But humans usually need some sort of context into why these goals have been set, and thereby into what problems they’re working to solve. If you’re going to have operational issues in November if a particular system isn’t up and running, your team deserves to understand that consequence. Appropriate context is what helps teams make good decisions about how and where to focus their energy. As the manager, it’s not your job to make all of those decisions by yourself.

You may be a shield, but you are not a parent. Sometimes, in combining the roles of shield and mentor we end up in a parenting-style relationship with our team, and treat them like fragile children to be protected, nurtured, and chided as appropriate. You are not their parent. Your team is made up of adults who need to be treated with appropriate respect. This respect is important for your sanity as well as for theirs. It’s too easy to take their mistakes personally when you view them as a child-like extension of yourself, or to get so emotionally invested that you take every disagreement they have with you personally.

Don’t rely exclusively on consensus or voting. Consensus can appear morally authoritative, but that assumes that everyone involved in the voting process is impartial, has an equal stake in the various outcomes, and has equal knowledge of the context. These conditions are rarely met on teams where each person has different levels of expertise and different roles. As when the team voted down Charles’s work, consensus can be downright cruel. Don’t set people up for votes that you know will fail instead of taking the responsibility as a manager of delivering that bad news yourself.

Do address issues without courting drama. There’s a difference between addressing conflict and cultivating dysfunction. You want to allow space for people to express frustration, but mind the difference between letting off steam and a real interpersonal issue. Use your judgment as to what should be addressed and what should be dropped. The key questions to ask are: Is this an ongoing problem? Is it something you’ve personally noticed? Is this something many people on the team are struggling with? Is there a power dynamic or potential bias at play? The goal is to identify problems that are causing the team to work less effectively together and resolve them, not to become the team’s therapist.

Do remember to be kind. It’s natural and perfectly human to want to be liked by other people. Many of us believe that the way to be liked is to be seen as nice — that niceness is itself the goal. Your goal as a manager, however, should not be to be nice, it should be to be kind. “Nice” is the language of polite society, where you’re trying to get along with strangers or acquaintances. Nice is saying “please” and “thank you” and holding doors for people struggling with bags or strollers. Nice is saying “I’m fine” when asked how you are, instead of “I’m in a really crappy mood and I wish you would leave me alone.” Nice is a good thing in casual conversation. 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. It’s awkward, and uncomfortable, but it’s also part of your job as his manager to have these difficult conversations.

Do get curious. Thinking about your actions is the best way to combat fear of conflict. Am I pushing this decision to the team because they really are the best people to decide, or am I just afraid that if I make an unpopular but necessary decision people will be mad at me? Am I avoiding working through this issue with my peer because she’s truly difficult to work with, or am I just hoping that the issue will resolve itself because I don’t want to have to discuss it and possibly be wrong? Am I holding back on giving my employee this feedback because he really was having a bad day and it’s just a one-off, or am I holding back because I’m afraid he won’t like me as a manager if I tell him? Be thoughtful about your behavior, and it’s unlikely that you’ll seek out unnecessary conflict.

This is why those who undermine team cohesion are so problematic. They almost always behave in a way that makes it hard for the rest of the team to feel safe around them. We refer to these employees as “toxic” because they tend to make everyone who comes into contact with them less effective. Dealing with them quickly is an important part of managing well.

The Brilliant Jerk One variant of the toxic employee is the brilliant jerk, who, as we discussed earlier, produces individually outsized results, but is so ego-driven that she creates a mixture of fear and dislike in almost everyone around her. The challenge of the brilliant jerk is that she’s probably been rewarded for a very long time for her brilliance, and she clings to it like a life raft. Acknowledging that there is value in the world beyond sheer intelligence or productivity would challenge her place in the world and tends to be a scary proposition for her. So she bullies with her intellect, cutting down dissenting voices in a harsh way, ignoring those she believes are not her equal, and letting her frustration with anything she sees as stupid seep out openly.

The best way to avoid brilliant jerk syndrome is to simply not hire one. Once they’re hired, getting rid of brilliant jerks takes a level of management confidence that I think is uncommon. Fortunately, these folks will often get rid of themselves, because even though you may not have the guts to fire them, it’s unlikely that you’ll be stupid enough to promote them. Right? Let’s hope so.

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. Note that this approach should only be used for behavior you feel is detrimental to the whole group. If you just think the person is undermining you personally, discuss it in private. 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 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. 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.

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.

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 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.

The team’s project list seems to change every week, depending on the customers’ whims that day. This team hasn’t thought about its goals beyond pleasing customers, and may need better product or business direction.

“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. This type of positive no is a pretty hard skill for most engineers to master. We’re used to articulating the downsides of projects, and getting out of the knee-jerk “no, that can’t happen” habit is hard. Start mastering the “yes, and” strategy for saying no, particularly when interacting with your boss and peers, and see how it often transforms contentious disagreements into realistic negotiations for priority.

“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, 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.

I can’t stand watching people waste their energy approaching problems with brute force and spending time rather than thought. And yet, any culture where you are encouraged to work excessive hours all the time is almost certainly doing just that. What is the value in automation if you don’t use it to make your job easier? We engineers automate so that we can focus on the fun stuff — and the 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?

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. It’s terrible for individuals, terrible for their families, and terrible for teams. But this isn’t just about preventing your own burnout — it’s about preventing your team’s burnout. When you work later than everyone else, when you send those emails at all hours, even if you don’t expect your team to respond to those emails or work those hours, they see you doing it and think it’s important. And that overwork makes them less effective, especially at the detailed knowledge work that engineers need to perform.

Laziness and impatience. We focus so we can go home, and we encourage going home because it forces us to constantly focus. This is how great teams scale.

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 his or her benefit. Each person should come prepared to focus on what he or she is interested in talking to you about.

Some suggested prompts to provide the person you are holding the skip-level 1-1 with include: 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?

If you’re building a dynamic, product-centric engineering team, you need managers who understand how to work with teams who ship software frequently, who are comfortable with modern development process best practices, and who can inspire creative product-centric engineers. These skills are so much more important than industry-specific knowledge. It’s easier to gain access to industry information than it is to retrain someone who doesn’t know how to work in your culture. Don’t compromise on culture fit, especially when hiring managers.

Another core element of agile software development is the emphasis on learning from the past. When estimates are wrong, what are we learning about unknown complexity? What are we learning about what is worth estimating, when? What are we learning about how we communicated those estimates and who was disappointed by the miss?

Your first job is to be a leader. The company looks to you for guidance on what to do, where to go, how to act, how to think, and what to value. You help set the tone for interactions. People join the company because they believe in you, in the people you hired, and in the mission you helped to craft.

You’re capable of making hard decisions without perfect information and willing to face the consequences of those decisions. You’re capable of understanding the current landscape of your business, as well as seeing into its many potential futures. You know how to plan for the months and years ahead so that your organization is best suited to handle those potential futures and capture opportunities as they come along. You understand organizational structure and how it impacts the work of teams. You know the value of putting in place management that strengthens this structure rather than undermining it. You can play politics in a productive way, in order to move the organization and the business forward. You work well with your peers outside of engineering and seek out their perspectives in addressing issues with a wide scope. You understand how to disagree with a decision and commit to deliver on it even though you disagree. You know how to hold individuals and organizations accountable for their output.

Information gathering or information sharing Sitting in meetings, reading and writing emails, talking to people one on one, gathering perspectives. The strong senior leader is capable of synthesizing large quantities of information quickly, identifying critical elements of that information, and sharing the information with the appropriate third parties in a way they will be able to understand.

Nudging Reminding people of their commitments by asking questions instead of giving orders. It’s hard for a leader of a large team to forcefully guide that team in any direction, so instead rely on nudging members of the team to keep the overall organization on track.

Role modeling Showing people what the values of the company are. Showing up for your commitments. Setting the best example for the team even when you don’t feel like it.

It took me a long time to realize that my job wasn’t to be the smartest person in the room. It wasn’t to be “right.” Rather, my role was to help the team make the best possible decisions and help them implement them in a sustainable and efficient way. I care about technology — it’s a factor in every decision we make as a team — but technology alone doesn’t make a productive and happy team. A good leader shapes technology discussions to inject the strategic objectives and take into consideration the nontechnical implications of a technical decision. It’s not about being the lead engineer, chasing the latest language or framework, or having the shiniest technology. It’s about building a team with the tools and attributes to build the best possible product for our customers. James Turnbull

So, what does a CTO actually do? First and foremost, a CTO must care about and understand the business, and be able to shape business strategy through the lens of technology. He is an executive first, a technologist second. If the CTO doesn’t have a seat at the executive table and doesn’t understand the business challenges the company faces, there’s no way he can guide the technology to solve those challenges. The CTO may identify areas where technology can be used to create new or bigger lines of business for the company that align with the overall company strategies. Or he may simply ensure that the technology is always evolving to anticipate and enable the potential futures of the business and product roadmap.

No matter what, the CTO must understand where the biggest technical opportunities and risks for the business are and focus on capitalizing on them. If he is focused on recruiting, retention, process, and people management, that’s because it’s the most important thing for the technology team to focus on at the time. I present this idea in contrast to the notion that the CTO should focus on purely technical issues, as the “chief nerd.”

Do a Lot of Research I started by considering the team, the technology we had currently built, and the company. I asked the engineering team where their pain points were. I asked several executives in various areas where they expected growth to come from in the future. Then, I asked myself several questions. I considered where the scaling challenges were now, and where they might be in the future. I examined the engineering team and found its productivity bottlenecks. I studied the technology landscape and wondered how it might change in the near future, especially as it pertained to personalization and mobile development.

Combine Your Research and Your Ideas Armed with my conclusions about the existing systems, teams, and bottlenecks, and having imagined the places where we could make things more efficient, expand features, or improve the business, I used the data to come up with a rough idea for a possible future. I spent some time sitting alone in a room with a whiteboard or paper and drawing out the systems in place at our company, slicing and dicing the systems and teams across various common attributes.

Draft a Strategy Once I had that data mapped, I could plan out actionable ideas to improve operational efficiency, expand features, and grow the business. I considered the places we would want to potentially limit or expand information sharing between systems.

Consider Your Board’s Communication Style I said earlier that the CEO sent back many of my attempts to get this work done. Really, she rejected two things. The first was an underdeveloped strategic plan that was almost entirely about system and architectural details and offered very few forward-thinking ideas beyond the next 6 to 12 months. It certainly did not attempt to address the business drivers that were critical to the team’s success. The second was my slide deck. As a speaker, I’ve been trained to make slide decks that are sparse, in support of an audience that listens closely. This board needed a deck that was very dense with information. It’s not uncommon for company boards to read through the slide deck before a meeting, so that the meetings can be focused more on details than on presentations. I didn’t understand this at the time, so I wasted a lot of energy trying to make something that wasn’t informative on paper. Lesson learned.

As you can see from this tale, good technology strategy here meant several things. It meant technology architecture, yes. It also meant team structure. It meant understanding the underpinnings of the business and the directions in which it was headed. I like to describe technology strategy for product-focused companies as something that “enables the many potential futures of the business.” It’s not just a reactive document that tries to account for current problems, but it anticipates and enables future growth. If you’re in a product-focused business, this is the heart of your technology strategy. It’s not about actually deciding the product’s direction, but about enabling the larger roadmap to play out successfully.

After I clarified this architecture for myself, leading became in many ways much easier. I could show the engineering team a vision of where we would go as a technology platform, not just what the product roadmap looked like. I had ideas about things we could work on that would directly move the company forward, beyond making the technology work. The architecture led the technology’s organizational strategy, which ended up leading some of the company’s organizational strategy — something I was quite proud of being able to influence.

Don’t blast an impersonal message to a large group. The worst way to communicate bad news is via impersonal mediums like email and chat, especially mediums with commenting abilities. Your team deserves to hear the message coming from your mouth directly, and without you to guide the message, you can expect some misunderstandings and bubbling animosity. That being said, the second-worst way to deliver this message, especially to a large group that you know won’t be happy, is with them all in a room at once. You may think that trying to communicate bad news to everyone at once is the best way to keep it from spreading before everyone has heard it, but the result is still impersonal. It’s hard to see everyone’s reaction, and one or two deeply unhappy members can quickly rile up the whole team before the message has had the chance to sink in.

Do talk to individuals as much as possible. Instead of impersonal or group-based communication, try your best to talk to people individually about the news. Think about the people who are going to have the strongest reaction, and try to tailor the news to them. Give them space one-on-one to react, to ask questions, to get it straight from you. And as necessary, make it clear that these are the marching orders and that you need your people to be on board with the changes, even if they don’t love them. In a case where you need to get the message out to your whole organization, talk to your managers first, give them talking points, and then let them share with their teams before bringing the whole group together.

Don’t force yourself to deliver a message you can’t stand behind. You may have a hard time delivering this news because you don’t like it yourself. Maybe you violently disagree with the policy change. Maybe you hate the fact that the team is being split up. If you absolutely can’t deliver the news in a way that won’t betray your strong disagreement, you might need to have someone else help you deliver it. Perhaps you ask another executive to step in, or maybe someone from HR. Depending on the size of your team, you can deliver the information to a trusted lieutenant and have that person help to share ...

A very common clash occurs between people who are extremely analytically driven and those who are more creatively or intuitively focused. Another is between the people who prefer to embrace agility and change (and, yes, sometimes disorder) and those who push for more long-term planning, deadlines, and budgets. You have to figure out how to understand and trust everyone’s styles across the spectrum.

When talking about structure with skeptics, I try to reframe the discussion. Instead of talking about structure, I talk about learning. Instead of talking about process, I talk about transparency. We don’t set up systems because structure and process have inherent value. We do it because we want to learn from our successes and our mistakes, and to share those successes and encode the lessons we learn from failures in a transparent way. This learning and sharing is how organizations become more stable and more scalable over time.

That, in short, is the value of structure. Structure is how we scale, diversify, and take on more complex long-term tasks. We do it to our software, we do it to our teams, and we do it to our processes. In the same way that strong technical systems designers are capable of identifying and shaping underlying system structures, strong leaders are capable of identifying and shaping underlying team structures and dynamics, and doing so in a way that supports the long-term goals of the team and equips the individuals to achieve their best.

My advice to leaders is simple: when failures occur, examine all aspects of reality that are contributing to those failures. The patterns you see are opportunities to evolve your structure, either by creating more or different structure or removing it. Think about how often the failure happens and its cost, and use your best judgment about the changes that need to be made. Using failure to guide evolution lets you apply structure at the right level. If a failure is occurring in only one part of the system — say, on one team — you can try to address the structure on that team without necessarily changing the larger structure.

When every new hire slows the team down for months because there is no onboarding process, that is a failure due to lack of structure. When people regularly leave the company because they have no path to advancement or career growth, that is a failure due to lack of structure. The third time you have a production outage because someone logged directly into the database and accidentally dropped a critical table, that is a failure due to lack of structure. I said earlier that I prefer to talk about learning and transparency rather than using the word structure, because really what we’re talking about here is identifying the causes of failures, especially frequent failures, and trying to figure out what we can change to solve for those failures. This is fundamentally about learning.

A lot of interviews try to determine cultural fit by what I would call “friendship” markers, such as “Would you like being stuck in an airport with this person?” You certainly don’t want to hire people that your team can’t stand to be around, but cultural fit is not about hiring friends. I’ve had great working relationships with people that I would not want to chat with for hours outside of work, and terrible working relationships with people I would love to be stuck with in an airport. Furthermore, culture fit as determined by friendship tests is almost certain to be discriminatory in some way. Humans form friendships with people who have significant shared background experiences, and these experiences tend to closely correlate with things like schooling, race, class, and gender. The shortcuts you get by hiring friends are not usually the values you need to form a strong team.