It’s a short step from managing a person or two to managing a whole team, but managing a team is more than just doing the job of managing the individuals. At this point, your job has changed. In fact, at every step beyond this level you will probably experience a totally different set of requirements and challenges. The hardest thing to prepare for as you advance in your career is the idea that you’re going to start doing totally different things. As much as you may want to believe that management is a natural progression of the skills you develop as a senior engineer, it’s really a whole new set of skills and challenges.
Here is the job description that I used for the role of managing a team, which I called “engineering lead”:
The engineering lead will spend less time writing code, but they still engage in small technical deliverables, such as bug fixes and small features, without blocking or slowing down the progress of their team. More than writing code, they hold responsibility for identifying bottlenecks in the process and roadblocks to success for their team and clearing these roadblocks.
The person who fills this role is expected to have a large impact on the success of [the organization] as a whole. In particular, leaders in this role are capable of identifying the most high-value projects and keeping their team focused on these projects. As part of keeping the team focused, the engineering lead will partner closely with the product lead to manage project scope and ensure the technical deliverables are met. In addition to focusing the team, they are capable of identifying headcount needs for the team and planning and recruiting to fill these needs.
The engineering lead is an independent manager. They are comfortable managing team members with different skill sets from their own. They communicate expectations clearly to all team members, and solicit and deliver individual feedback frequently (not just in the scope of review periods). In addition to strong management skills, the engineering lead acts as a leader for the technical roadmap for their product group (pillar). They clearly communicate the timeline, scope, and risks to their pillar partners, and lead the delivery of major initiatives on clear timelines. Additionally, they identify areas of strategic technical debt, do the cost/benefit analysis for resolving this debt, and communicate suggested timelines for prioritizing this to the management team.
We’ve covered the basics of managing individuals, but now let’s talk about what it takes to lead a whole team, all while still being technical.
The theme of this chapter is a focus on the job beyond the people management. Because it’s easy for new managers to get overly focused on the people-related tasks, I want to draw your attention back to the more technical, strategic, and leadership areas of managing a team.
BECOMING A PEOPLE MANAGER
I started out as an informal team lead in a company that had resisted traditional managers. After I played that role for a while, it came time for me to become an official people manager. Managers as a role were new to the company, and the entire organization met the changes with some trepidation. When dividing engineering among managers, we weighed who would chafe at the new structure. Not everyone was comfortable working for their former peers, but I was pretty lucky. Most of the people I now managed had worked with me long enough to be OK with the idea that I was now their manager. Their support helped tons. It wasn’t perfect, but the pushback I received wasn’t significant.
In this new role, I found myself managing a few people who were far more senior, tech-wise, than I was. It was the first time that I couldn’t rely on having the most knowledge as my main leadership tool. This wasn’t simple impostor syndrome. I knew I was out of my league. They knew I was out of my league! Of course, both of the most senior engineers I was now managing realized that this was awkward. We talked about how everyone had a job to do, and mine was to help them succeed however I could.
One engineer continued to help me along the way with ongoing feedback. I worked hard to learn what was important to this person and what they needed to succeed. The other engineer had trouble adjusting to me being his manager. He transferred to another team—at first. Months later, a bit contrite, he returned to our team and agreed to work with me. It turns out, being a good manager isn’t about having the most technical knowledge. The work of supporting people was far more important to management success.
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.
Furthermore, if you truly wish to command the respect of an engineering team, they must see you as technically credible. Without technical credibility you face an uphill battle, and even though you may be able to get into a position of leadership in one company, your options will be limited. Don’t underestimate the value of your technical skills as you work to become a successful engineering manager.
Of course, you have to learn how to balance. It’s a struggle to figure out how to stay technical as you transition to management. The new responsibilities that come with being a manager—more meetings, planning, administrative tasks—don’t lend themselves to having focused time to write code. It can be hard to work out how to stay in the code when you are pulled in a million directions.
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.
Why bother writing any code if all you’re doing is small stuff? The answer is that you need to stay enough in the code to see where the bottlenecks and process problems are. You might be able to see this by observing metrics, but it’s far easier to feel these problems when you’re actively engaged in writing code yourself. If the build is really slow or deploying code takes too long or on-call is a nightmare, you’ll feel it in the difficulties you, an experienced engineer, have in knocking out trivial programming tasks. Imagine how frustrating it is for the members of your team! It’s far easier to identify technical debt and prioritize dealing with it when you’ve slogged through the code yourself.
Additionally, as the manager of a single team, you’ll be called upon to help guide what is possible and impossible to do in your systems. When the product manager for your group has a crazy idea, it’s much easier to manage when you’re confident in your ability to evaluate how easy that feature will be to implement in the given systems (although beware of overconfidence in giving these estimates!). Strong engineering managers can identify the shortest path through the systems to implement new features. As you learned in your time as a tech lead, a critical part of complex project management is understanding the pieces of the system well enough to determine the best path to implementation. The more you understand the code in the system, the easier determining this path will be.
Sadly, some companies don’t really have the role of “manager who has a little time to code” available. These companies split the management and technical tracks so cleanly that managers immediately start with large teams reporting directly to them. Thus the manager’s job becomes an administrative and people management position, and these managers end up grabbing technical time on nights and weekends, if ever. If your company is like this, my advice is to stay technical until you feel that you have truly mastered what you want to learn for writing code and designing systems, and then decide if you want to switch careers into management. It’s hard to make up lost time when you stop writing code, and if you do it too early in your career, you may never achieve sufficient technical savvy to get beyond the role of middle management.
If you are horrified at my suggestion that managers stay in the code at all, don’t worry! In later chapters I’ll talk in detail about the point at which it doesn’t make sense to be in the code anymore, and I do believe that point exists. But for now, try to stay in it a little bit. I promise, it’ll make your job easier.
Sometimes you’ll find yourself managing a dysfunctional team. They keep missing deliverables. People are unhappy. They keep quitting. The product manager is frustrated. The team is frustrated with the product manager. Or maybe they’re just lacking energy in their work, or lacking enthusiasm about the current projects. You can tell something is wrong, but you’re not entirely sure what it is. A few basic dysfunctions can creep into tech teams. I’ll introduce these dysfunctions briefly here so you know what to look for and how to solve it.
You may not think this is a dysfunction. Perhaps your team is in deep research mode on a new problem, for example. However, even teams doing research generally have goals and deliverables, even if they’re just in the form of initial findings. Humans, by and large, feel good when they set small goals and meet them regularly.
As the manager of the team, you may worry about pushing them too hard, and so you let them miss deadlines without a fuss. The trick is to learn how to balance pushing your team and holding back. If you’re still writing code for the team, this may be a good time to roll up your sleeves and help the team meet its deliverables, or really dig in to the part of the project that’s slipping and partner with the engineers responsible to help understand the situation.
Sometimes, teams aren’t shipping because the tools and processes they’ve been using make it hard to get work done quickly. 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.
At my last job, there was a critical part of the system that, for a time, we released only once a week. The releases took hours and were very painful, and often suffered from people trying to get in last-minute changes that broke tests and slowed everyone down. We all decided this was a problem and the team came together to improve the code base and automation, in order to make releases happen faster. 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.
Sometimes we let ourselves hang onto that brilliant asshole for too long. You know, that person you think can’t be replaced because he’s just so productive and so smart, but who isn’t a team player and makes everyone around him unhappy. (For more on this kind of toxic employee, see “The Brilliant Jerk”.) A less critical version of this situation is the person who just stirs up drama, who dwells on negative experiences, or who spends a bit too much time on gossip and playing games of us-against-them.
You have to be brave and nip people drama in the bud quickly. It’s OK to ask your manager for help with this, especially if it’s your first time doing it, but be aware that your manager may actually have an even harder time dealing with the brilliant jerk than you do. She isn’t seeing the immediate impact on team dynamics; she’s just seeing someone who gets things done. Be prepared to have a series of conversations with both the employee and your boss. It may be that a move to a different team will clear up the situation.
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.
This problem is much easier to solve. Usually, unhappiness due to overwork has a root in problems that you can address. For example, if overwork is due to (in)stability of the production systems, it’s your job as the manager to slow down the product roadmap in order to focus on stability for a while. Make clear measures of alerts, downtime, and incidents, and strive to reduce them. 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.
Second, do everything you can to learn from this crunch period and avoid it the next time. Cut features if you can. Push back on the date if it’s truly unrealistic. Crunch periods will happen, but there is no reason they should happen frequently.
Your team isn’t working well with the product team, or the design team, or another tech team, and the lack of collaboration is dragging everyone down. There’s no quick fix here, but showing a willingness to improve collaboration goes a long way. If you aren’t already, make sure you’re having regular touch-bases with the appropriate peers to work through issues. Gather actionable feedback from your team, and have productive conversations about possible improvements. You can make the situation worse by undermining your peers in front of your team, so even when you are frustrated with them, try to stay positive and supportive of their efforts in public.
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.
ASK THE CTO: MANAGING A FORMER PEER
I just got promoted to run my team over another peer of mine, a senior engineer who also wanted the job. How can I make sure to manage this so that I don’t alienate him while still taking on the role?
This experience can be deeply awkward, so the first thing to do is to acknowledge that. If you’re now managing someone who was truly your peer, acknowledge the weirdness of the transition. Be honest and transparent with this person that you’re going to do the best job you can, but you’ll need his help to do it. You need him to be honest with you about the things that are going well and the things that are not. You’re going to have to be a little bit vulnerable with him, because you won’t be perfect the first time around.
Next, remember that your job has changed in some big ways. As his manager, you may now have the ability to override his decisions, but use this power very cautiously. Using your managerial power to override technical decisions is usually a bad idea. Resist the temptation to micromanage people—especially those who used to be your peers. They’re going to be sensitive to the feeling that you’ve been “rewarded,” even if they didn’t want to become managers themselves. If you question their every move and try to make every single decision yourself, you’ll make this sensitivity much worse.
A corollary here is that you’re going to have to let go of some of your previous work as you ease into the additional responsibilities of people management. Every step up the management chain will mean adding new responsibilities and giving up some of your old ones. You can use this situation to your advantage with former peers by openly giving them more control over some of that technical work you used to own. This is also an opportunity to give new challenges to more junior members of the team. While many engineering organizations want first-level managers to continue to write some code, they likely expect the code those managers write to be smaller features, bug fixes, and enhancements, rather than deep new systems.
Throughout all of this change, your goal is to show the team that you’re committed to helping them succeed. Your new role isn’t taking anything away from the rest of the team; it’s only giving you some new responsibilities that either were being neglected or used to belong to someone else, and shifting some of your old responsibilities to other members of the team.
Your team won’t be successful if your former peers all quit because they can’t stand working for you. They’re going to be extra-sensitive to any disagreements or perceived power grabs on your part. They may even do things to try to undermine you. Pick your battles. In the long run, handling this transition with maturity will pay off.
Many pieces of management advice tell new managers that part of their job, if they are effective, is to be a shield (or, less politely, a “bullshit umbrella”). They should help their team focus on what they need to get done without being distracted by the wider drama, politics, and changes happening in the company around them.
I have mixed feelings about this take on management. I do think that teams who are unnecessarily exposed to toxic drama that doesn’t concern them tend to get distracted and stressed out. If you’re managing an engineering team, they don’t need to be concerned with interpersonal incidents in the customer service organization. I’ve watched with mixed pride as my own teams continue to function smoothly when it seems to me like the world is burning down around my ears. It’s valuable for everyone to realize that they can and should focus on the things they can impact and change, and ignore the things they can’t. Drama in the workplace is usually little more than an ego-entertaining drain.
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.
Another error that the shield sometimes makes is denying that any drama exists in the outside world. If layoffs happen in another part of the company and the team finds out from someone else, rather than shielding your team from drama, you’ve created a situation where they feel like something bad is happening and no one wants to admit it. If you instead communicate information about such events in a straightforward, low-emotion way, you alleviate the gossip and quickly neutralize the impact on your team.
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.
What is your role in the decision-making process for your team? Do you know? You may have a product manager who works with your team and owns the product roadmap, or the set of business features that your team has committed to working on. You probably have a tech lead who, as we covered in Chapter 3, is still deep in the technology but is also thinking about project management and the work that needs to be done. So where does that leave you, the engineering manager?
You have more responsibility than you may expect. While the product manager is responsible for the product roadmap, and the tech lead is responsible for the technical details, you are usually accountable for the team’s progress through each of these elements. The nature of leadership is that, while you may only have the authority to guide decisions rather than dictate them, you’ll still be judged by how well those decisions turn out.
When you have a product or business head, she should be accustomed to using data about the business, the customers, the current behavior, or the market potential to justify her decisions. Start adding other data to the mix. For example, give that person data about team productivity (such as the time it takes to complete features) or data about quality measures (like how much time is spent dealing with outages, or the number of bugs found in QA or after releases). These efficiency and technical data points can be used to evaluate decisions on both product features and technical changes.
Strong leadership cares about cultivating success and having a team that delivers successful projects, which means honing your understanding of what is important to your customer. Whether you’re writing code for an external customer, developing tools for other engineers, or even running a support team, you have some group that depends on the output of your work. Treat them as your customers. Taking the time to develop customer empathy is important because you’ll need to give your engineers context for their work. Developing customer empathy will also help you figure out which areas of the technology have the greatest direct impact on your customers, and that understanding will guide where you invest engineering effort.
Talk about whether the hypotheses you used to motivate projects actually turned out to be true. Was it true that the team moved faster after you rewrote that system? Did customer behavior change in the way the product team predicted when you added the new feature? What have you learned from your A/B tests? It’s easy to forget to review assumptions after the project is done, but if you make this a habit for yourself and your team, you’ll always learn from your decisions.
Agile processes usually have a retrospective meeting at the end of each two-week development sprint, where you discuss what happened during the sprint and pick a few events—good, bad, or neutral—to discuss in detail. Whether you work in an agile methodology or some other fashion, the regular process retrospective has a lot of value for detecting patterns and forcing a reckoning with the outcome of decisions. Is the team feeling good about how they get requirements? Do they feel good about the code quality? This process helps you learn how the decisions you make over time affect the way your team operates in the day-to-day. This approach is more subjective than gathering data about the team’s health, but it’s arguably even more valuable than many objective measures, because it comes from the things the team itself is noticing and struggling with or celebrating.
Jason’s team is overworked. Everyone knows that Charles should be working on the big system rewrite, but he’s been off on his own pet project for months. After hearing complaints that Charles isn’t helping with the new system, Jason calls the team together and asks them to vote on what projects should be dropped to get the workload down. It’s no surprise to anyone that they vote to drop Charles’s pet project—no surprise, that is, to anyone except Charles, who has never heard anything about this from Jason and who figured he was doing the right thing.
Jason’s team is feeling the crunch partly because Jason doesn’t seem to stand up for them with other teams. He hates to say no to new projects, but he also doesn’t ask for more people to help manage the load. Jason is cool, everyone agrees, but it is so hard to get him to actually act on resolving conflicts or making difficult decisions. As a result, the team is overworked, struggles to prioritize a way forward, and is nursing several grudges among its members.
Lydia’s team is also feeling crunched, and she has her own Charles to deal with. She promised Charles that he would get time to work on this project, but it’s clear that priorities have changed and so his work will need to change with them. In her 1-1 with Charles, Lydia explains the current workload, and tells Charles that his team needs him to help with the system rewrite. Charles is unhappy, and Lydia doesn’t enjoy this conversation, but she knows that as the manager of the team, she’s responsible for making sure they’re focused on the most important projects.
Lydia knows that this project is important for the team to own, so while she pushes for more people, she makes sure that the team knows why she decided to take on this big project. She works with the team to prioritize the work, and guides them through their disagreements on what technology to use by following a structure for presenting options and soliciting feedback. Lydia’s team describes her as tough but fair, and though disagreements happen, the team is good at getting through challenges and collaborates well.
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. But there is such a thing as artificial harmony, and conflict-avoidant managers tend to favor harmony above functional working relationships. Creating a safe environment for disagreement to work itself out is far better than pretending that all disagreement does not exist.
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 set up clear processes to depersonalize decisions. When you want to allow for group decision making, the group needs to have a clear set of standards that they use to evaluate decisions. Start with a shared understanding of the goals, risks, and the questions to answer before making a decision. When you assign the ownership for making a decision to someone on the team, make it clear which members of the team should be consulted for feedback and who needs to be informed of the decision or plan.
Don’t turn a blind eye to simmering issues. Another way that conflict avoidance manifests is an inability to address problems until they’ve gone on for way too long. As a manager, if you’re giving negative feedback in the course of a performance review, it shouldn’t be a major surprise to your employee. There may be nuances that you didn’t think through until writing the review, but if there are major problems with someone’s work, that person should know about them as soon as you notice them. If you don’t notice these problems yourself but learn about them during the review process via feedback from several peers, that’s not a good sign. It’s probably an indication that you are not paying attention, and not making space in your 1-1s for your team to discuss problems they’re having with their colleagues.
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.
Don’t take it out on other teams. Ironically, conflict-avoidant managers often seek conflict when it comes to other teams. They identify strongly with their own team and will aggressively react to what they perceive as threats from outsiders. When something goes wrong, like an incident that spans across teams, the manager turns into a bully and demands justice for his team, or blames the problems on the other team. Sometimes, this behavior is an outlet for the manager’s suppressed feelings about his own team. As one friend put it, “I was not telling my people the 10% of things they needed to be improving because I was afraid they would miss the message about the 90% of things that were good, and so I took that desire for accountability out on other teams. I really just wanted everyone to be fully accountable, and I needed to figure out how to express that internally and externally in a healthy manner.”
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.
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. We’re afraid people won’t like us, or that we’ll fail when we take this risk. Some fear is natural, and being sensitive to the outcomes of conflict is a wise habit.
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.
One of the critical elements of creating functional teams is building teams that work well and happily together. I was once given a test of a happy engineering team: “If you buy them pizza in the evening, will they stick around and socialize together, or will they race out the door as quickly as possible?”
I have some quibbles with that. Employees with obligations that take them out of the office at a strict time every day are no more or less engaged than those who are willing to stand around and chat. The larger point, however, is still a good one. Most gelled teams have a sense of camaraderie that makes them joke together, get coffee, share lunch, and feel friendly toward one another. They may have obligations they respect, and passions outside of work, but they don’t view their team as something they’re eager to escape every day.
The real goal here is psychological safety—that is, a team whose members are willing to take risks and make mistakes in front of one another. 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. This is more than empty small talk; it fosters relatedness, the sense of people as individuals and not just anonymous cogs.
Beyond you personally cultivating relatedness, you want your teams to have their own relatedness among themselves. When companies talk about hiring for “culture fit,” they often mean they want to hire people they can be friendly with. While this can have some unwanted consequences, such as discrimination, it comes from a wise place. Teams that are friendly are happier, gel faster, and tend to produce better results. I mean, do you really want to go to work every day with a bunch of people you hate?
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.
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.
These days, most places claim that they don’t tolerate brilliant jerks, but I personally don’t believe that is true. It’s incredibly hard for a manager to justify getting rid of someone who produces great work, even though she’s a drain on everyone around her—especially if this person is only irregularly a jerk. How much jerk is too much? You start to run rings around the idea to try to justify keeping her on. You give her feedback, and she gets a little bit better for a while, but then she gets worse.
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.
It takes a strong manager to deal with a brilliant jerk onboard. Expect her to fight you tooth and nail on all feedback. This isn’t going to be easy on either of you. The difficulty is, if she doesn’t see her behavior as a problem, she won’t change it. It’s unlikely that you alone will be able to convince her that her behavior is a problem. All the evidence in the world can’t change a person who doesn’t want to change.
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.
Another very common problem team member is the noncommunicator—the person who hides information from you, from his teammates, from his product manager. The person who prefers to work in secret and unveil a magical project when everything is done and perfect. The person who, instead of talking things out with teammates, reverts their commits, or takes their tickets and does the work for them. The person who doesn’t want to go through code review and who doesn’t ask for design review on big projects.
This team member annoys everyone around him. As the noncommunicator’s manager, you have to nip this information-hiding habit in the bud as soon as possible. If necessary, make it clear that he’s not meeting expectations for his work. This is often a sign of fear—the person is afraid that he’ll be found lacking, or he’ll be asked to do work he’s not interested in. Sometimes it’s a sign of a person who feels he should have more responsibility and who doesn’t respect his manager. Whatever the cause, this person disrupts team cohesion because he isn’t being collaborative with the rest of his teammates; he doesn’t feel safe sharing his work in progress, and his fear often sets an example for the rest of the team.
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? If the team is rejecting the individual, you will need to decide whether to try to correct the team or move the individual to another team. Sometimes, moving the individual is the kindest thing to do; other times, the best solution is to work with the team as a whole to change the balance of culture and break the habits that exclude new people.
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.
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.
We gave a high-level overview of project management in Chapter 3’s discussion of being a tech lead, but now I want to dig into some of the advanced work. As the manager of a team, while you may push some of the project planning onto your tech leads, you’ll likely need to do some of that work yourself. You may have to decide which projects to take on, and when to push back on accepting projects. You’ll probably be asked for rough estimates as to when work will be done, even work that is planned and iterated on in an agile fashion.
You need to have a strong sense of the rhythms and pace of your team to manage their workload successfully, but fortunately there are some shortcuts that can help.
Here are some rules of thumb to keep in mind.
Before I begin, I want to make clear that I’m not suggesting that you go into waterfall mode and plan every project in detail from the get-go. However, most teams have both high-level, long-term goals, and short-term objectives that will enable them to meet those goals. When it comes to actually planning the details of the smaller pieces, an agile process where the team collaborates to divide and roughly estimate work is very effective at smoothing and organizing the day-to-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.
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.
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. If you make this a habit, you can use it to tackle some of the midsize legacy code every quarter and get decent improvements. Cleaning up systems as you go keeps those systems easy to work in, which keeps your teams moving forward on new features. In the worst case, you can use this slack to smooth over unexpected delays in feature development, but if you fill the schedule to 100% with feature development, expect that the feature development will quickly slow down as a result of this overscheduling.
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 times when the engineering team will say that they can’t possibly implement a feature without doing some other technical work, and you will need to figure out when to push for a hack implementation and when to hold back for the right implementation. 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.
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. Sometimes the longer tasks will take far more than twice your estimate, and it’s worth spending some time planning more carefully before you commit your team to a big, unknown project.
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 learning how to work in the systems. This slowdown is worth it. By getting to know the code, the processes for writing code, and the tools and systems your team use for their day-to-day, you will gain the understanding necessary for managing the team, and the technical credibility necessary for them to see you as a capable leader.
- What are your new responsibilities now that you’re the manager of a team? What tasks have you stopped doing or handed off to someone else in order to make time for these new responsibilities?
- How well do you feel you know the day-to-day challenges of writing, deploying, and supporting code on your team?
- How often does your team mark work as completed?
- When was the last time you wrote a feature, debugged a problem, or paired with a member of your team on some code he or she was struggling with?
- Are there one or two team members who cause the bulk of negativity on the team? What is your plan for getting rid of the problem moving forward?
- Do your team members seem engaged with one another? Do they smile in meetings? Make jokes in chat? Get coffee or lunch together? When was the last time you all sat down together without talking about work?
- How does your team make decisions? Do you have a process for assigning decision-making responsibility? What decisions do you hold yourself responsible for making?
- When was the last time you reviewed a completed project to see if it had achieved its goals?
- How well does your team understand why they are working on the projects they are working on?
- When was the last time you cut scope on a project? What did you use to determine which pieces to cut?