Building Team Culture and Members (80+ New Team Hacks 2019)

Team Members and Building Team Culture

Team Members and Building Team Culture: Best Ways

Your team’s culture is much like a good loaf of sourdough: your starter culture (your founders) inoculates your dough (your newcomers) with the culture, and as the yeast and bacteria (your team members) grow, out pops a great loaf of bread (your team).


If your starter culture is strong, it’s more than capable of overcoming any undesirable “wild strains” of culture that a newcomer might bring with him.


If your starter culture is weak, your team is vulnerable to unknown culture strains that newcomers might bring along. Unknown cultures bring with them unpredictable results, so it’s better, to begin with, a known starter culture.


But a team’s culture isn’t just the way in which team members tackle their work, write code, or treat one another: it’s a set of shared experiences, values, and goals that are unique to every engineering team we’ve ever been on or observed. The founding members of a team or company define the biggest part of a team’s culture, but it will continue to change and develop over the life of the team.


The elements that make up a team culture vary wildly. Some are directly relevant to the process of doing work: in the case of writing software, you might set up code reviews and test-driven development, and place a high value on having good design docs before starting to crank out reams of code.


Some elements might be more social, like going out to a particular restaurant for lunch every Thursday or going out for drinks at a favorite bar on Fridays.


Some of them might seem completely silly or outlandish to an outsider: the Google Pittsburgh engineering office used to be located next to a freight train track, and every time a train would come by (mind you, a very loud train), everyone would jump up and shoot Nerf darts at one another.


All of these things make up a team’s culture and affect the team’s productivity and ability to attract and retain good team members.


Take a look at any wildly successful software company today—Google, Apple, Microsoft, Oracle—and you’ll find that each company has a very different culture: one that has its roots in the culture that was set by the founders and earliest employees.


As these companies have grown and matured, their cultures have evolved and changed, but they’ve still retained a unique identity that trickles down to just about every aspect of how they develop products, treat their employees, and compete with other companies.


Why Should You Care?

In short, you should care because if you don’t put effort into building and maintaining your culture, your team will eventually be overtaken by strong personalities that cultivate their culture in your team.


This culture may turn out to be a productive, healthy culture that cranks out piles of great code, but more often than not, it won’t turn out as such, and you’ll suddenly find a lot of your energy that used to go into designing and creating your product is suddenly expanded in arguments and infighting.


Beyond that, it’s important to have a culture that your team values and is willing to defend. If your team doesn’t value your culture, not only is it difficult to build a strong team identity and collective pride in your work but also it’s very easy for a newcomer to change your culture into something that sucks.


The first mistake most team members make is to assume the team leader curates the culture of a team. Nothing could be further from the truth: while the founders and leads usually tend to the health of your culture, every member of your team participates in the culture and bears some responsibility for defining, maintaining, and defending the culture.


When someone joins your team, she doesn’t pick up the culture from the team leader alone, but from every team member, she works with. For example, when you carefully review your new team member’s work and explain to her why your team does something in a certain way, she’ll quickly figure out what the team values in their product.


She’ll also learn about your culture from observing how the rest of your team works, interacts and deals with conflict.


A “strong culture” is one that is open to change that improves it, yet is resistant to radical change that harms it. The team cultures that are most successful are those that focus the majority of the team’s effort on shipping great software.


If your team’s primary focus is anything other than that (e.g., partying, attending meetings, practicing one-upmanship) your team may bond tightly, but you won’t get very much software written.


If you’re happiest when writing code and shipping product, it’s definitely in your best interest to find a team that values that and to works to maintain that environment.


It’s not that you can’t create something great without a strong and productive culture, but it’s going to cost you a lot more time and energy to do so without one.


A strong culture gives you focus, efficiency, and strength, and these things make for a happier team.


The interesting thing about team culture is that, if you build a strongly defined one, it will become self-selecting. In the open source world, projects that are built on HRT and focused on writing clean, elegant, the maintainable code will attract engineers who are interested in—surprise, surprise—working with people they respect and trust and writing clean, elegant, maintainable code.


If, however, your team is built on a culture of aggression, hazing, and ad hominem attacks, you’re going to wind up attracting more people like that.


We’ve seen self-selecting cultures many times in the Apache Software Foundation: the ASF is a collection of software development teams that are community-based and that run on a consensus model. Many times a new contributor will join the mailing list and, through either ignorance or malice, will behave in a manner contrary to the team’s culture.


Community members will usually attempt to educate the newcomer (sometimes gently, sometimes, um, well, “not so gently”), and if the newcomer is not interested in how the ASF team does things, they’ll usually head off in search of a more compatible project.


In the corporate world, teams self-select through the hiring process, whether implicitly in the skills and strengths that are valued in potential candidates, or explicitly by considering culture fit as part of the hiring process.


Google takes the explicit approach in its hiring process as it looks specifically for culture fit when interviewing candidates: if Google interviews someone who in all respects looks like an outstanding engineer but is incapable of working with a team of people or requires a very structured environment, the interviewers will raise a red flag in their feedback.


If you don’t pay attention to culture fit as part of the hiring process and hire someone who isn’t a fit, you’ll wind up expending a tremendous amount of energy either getting the new hire to fit in or getting him to leave your team.


Regardless of the result, the cost is high enough that it’s definitely worthwhile to make sure new team members will work well with your existing team.


Interviewing for culture

The only way to make sure new team members will be a culture fit is to interview for it. Many companies (like Google) have culture fit as one of the criteria that interviewers look out for as they’re speaking to a candidate.


Some companies take it even further in their quest to avoid a hiring mistake: they have a separate interview for culture fit before doing the technical interviews because they don’t want to even consider people who would fit technically but not culturally.


This sort of process involvement is critical for creating and preserving a strong culture and it doesn’t happen by accident; in fact, it is usually consciously created by the company’s founders and early employees.


Culture and People

Creative work like writing software is different from simply knocking out widgets on an assembly line. Some types of work can be done with a few days of training and some basic tools, and if your worker quits and leaves (or doesn’t work out), you just drop another worker in and on you go.


In the assembly line environment, employees are accomplishing simple tasks, often by rote, with little creative-thinking or problem-solving skills required. In the software world, a great deal of creative thinking is required of engineers working on a product, and if you want a great product, you need great engineers.


If you want great engineers to do great work (and to stick around), you need to create a culture for them that allows them to safely share ideas and have a voice in the decision-making process.


If you want to get excellent engineers to work on your team, you need to start by hiring, well, some great engineers! That may sound weird, but the fact of the matter is that most great engineers want to be on teams with other great engineers.


Many great engineers we know gravitate toward teams where they can learn from giants of the industry. So how do you attract these engineers in the first place?


For starters, they’re going to want to be able to not only contribute to the development of your product, but also participate in the product’s decision-making process, and that usually means some level of consensus-driven management.


In the case of top-down management, the alpha engineer is the team lead and lesser engineers are hired as team members.


This is because subservient team members cost less and are easier to push around. And you’re going to have a hard time finding great engineers to be on this team because, after all, what really great engineer wants to ride the bus when she can drive the bus at another company? But in the case of consensus-driven management, the entire team participates in the decision-making process.


Many people hear “consensus-based team” and immediately think of a bunch of hippies singing “Kumbaya” around a campfire and never making a decision or getting anything done, but that stereotype is symptomatic of a dysfunctional team much more than a consensus-based team.


What we mean by “consensus” is that everyone has a strong sense of ownership and responsibility for the product’s success and that the leaders really listen to the team (with an emphasis on the “respect” component of HRT).


This may mean there are times when extended discussion and reflection is what the product needs to succeed, and there are other times when the team agrees they need to move quickly. In the latter case, team members may decide to entrust a great deal of the nitty-gritty day-to-day decision making to one or more team leads.


In order for this to happen, the team as a whole needs to agree on the general mission of the team, and believe it or not, the key to that is the development of a team mission statement.


Just as important as your team’s decision-making process is the manner in which team members treat one another because this is more self-selecting than anything else.


If your team has a culture of chest thumping and yelling and screaming at one another, the only people you’ll attract (and retain) are aggressive types who feel right at home in this environment composed of strong individual egos (in fact, most of the women we know find this kind of environment especially off-putting).


If you create a culture of HRT where team members treat one another kindly and take the effort to give constructive criticism, you’ll not only attract a much larger set of people, but you’ll also spend a great deal more of your energy writing software. Having a strong team ego6 is good; a team totally eclipsed by individual egos is a recipe for disaster. 


Constructive criticism is essential to the growth and development of any person or team, but many people will go to great lengths to avoid soliciting criticism.


In some cases, this is due to insecurity, but in most cases that we’ve seen, it is because a person thinks that they are required to take action on any criticism received, even if they disagree with it. The best part about getting good constructive criticism is that you can pick and choose which pieces you want to act on.


Let’s say, for example, that you’re getting ready for an important job interview and put on your favorite suit. You approach a trusted friend and ask how you look. If they say, “You’ve got spinach in your teeth, and I really hate your suit” you can take a quick floss break, but you don’t have to change clothes as well. Criticism is a gift that you can either accept or reject.


If you’re interested in improving your work or fixing your own personal bugs, these very friends and colleagues are the ones that can make you aware of things you do that might be hindering your effectiveness. Unless you have a truly remarkable level of self-awareness or introspection, without criticism, you’ll just go on making the same mistakes no one wants to tell you about.


For example, in the process of going to press with this blog, we’ve had no fewer than a dozen people look at it and give us constructive criticism on our writing, and most of it was incredibly detailed and completely invaluable.


Regardless of whether you think the blog is good or bad, it would have been considerably worse if we had ignored this valuable feedback or been afraid to ask for it.


It requires a certain amount of self-confidence to take any kind of criticism, and we think constructive criticism is the easiest kind to receive. On the down-side, it’s a lot harder to give someone constructive criticism than to simply lam-bast her or ridicule something she did.


Of course, we realize it’s incredibly difficult to solicit and then receive constructive criticism from most people—they assume that when you ask them to criticize your work, you’re only looking for compliments and assurance.


If you can find friends or colleagues who will constructively criticize your work when you ask them, hang on to these people because they’re worth their weight in unobtainium.


Aggressive people can (usually) be productive in a quieter environment, but quieter, more introverted people rarely excel (or enjoy working) in an aggressive environment—it’s not only harder to hear their voices over the noise, but it also tends to discourage them from being active participants.


If you’re looking for a culture that allows the broadest range of people to work most efficiently, you should build that culture on humility, respect, and trust.


Calm, easygoing cultures built on respect are more vulnerable to disruption by aggressive people than aggressive cultures are vulnerable to disruption from more easygoing people. Easygoing cultures need to be aware of this and not let the aggressive newcomer take over, typically by refusing to engage this person in an aggressive tone.


In some cases, one or more of the more senior team members may have to meet the aggressive newcomer head-on to prevent her from harming an easygoing team culture. 


Communication Patterns of Successful Cultures

Communication can often be a challenge when you’re working with a team, Communication can often be a challenge when working with a team, particularly for engineers, who would rather spend an afternoon with a (predictable, logical) compiler than spend three minutes with an (unpredictable, emotional) human being.


In many cases, engineers see communication work as an obstacle to be overcome on the road to writing more code, but if your team isn’t in agreement or is uninformed, there’s no way to know if you’re writing the right code in the first place.


If you examine any successful, efficient culture, you’ll find high value placed on numerous channels of communication, such as mailing lists, design docs, chat rooms, mission statements, code comments, production how-tos, and more.


It takes considerable effort to make sure everyone on a team agrees on the team’s direction and understands exactly what the team needs to do. All this effort, however, is an investment that pays off in increased productivity and team happiness.


A good general rule around communication is to include as few people as necessary in synchronous communication (like meetings and phone calls), and to go for a broader audience in asynchronous communication (like email, issue trackers, and document comments). Synchronous communications have a high cost: they require that participants interrupt their workday and receive information on your schedule.


Asynchronous communications, however, can be dealt with at a time and place most convenient for the recipient. Every time you interrupt someone’s work it will take some amount of time for them to get back up to speed—always be conscious of when you’re doing this.


But most importantly, you should make certain that all information is available to as many people as possible in your project’s documentation. Let’s cover the primary communication mechanisms that people use in the process of writing software with a team.


Some of these may seem obvious, but there are many nuances that make them worth reviewing. One thing is certain: if you don’t expend any effort on good communication, you’ll waste considerable effort doing work that’s either unnecessary or already being done by other members of your team.


High-Level Synchronization

At the highest level, the team needs to keep common goals in sync and follow best practices around communicating their progress.



When you hear someone say “mission statement,” the odds are good that the first thing that springs to mind is the insipid, overhyped, marketing-speak mission statements that are bandied about by a lot of big companies. An example is the following mission statement from a very large telecommunications company that will remain nameless:


We aspire to be the most admired and valuable company in the world. Our goal is to enrich our customers’ personal lives and to make their businesses more successful by bringing to market exciting and useful communications services, building shareowner value in the process.


Oddly enough, I’ve yet to meet anyone who admires that company! Here’s another example from another major corporation:

Providing solutions in real time to meet our customers’ needs.


What does that even mean? It could mean absolutely anything at all—if we worked for that company, we wouldn’t know if it was more important to wash the car, fix a leaky pipe, or deliver a pizza. It’s this kind of corporate doublespeak that gives mission statements a bad name.


For an effective, efficient team, writing a mission statement is a way to concisely define the direction and limit the scope of your product. Writing a good mission statement takes some time and effort, but it can potentially save you years of work by clarifying what your team should and shouldn’t be working on.


When Google decided to move development of the Google Web Toolkit (GWT) to an open source project, we acted as the team mentors.


We reviewed the many differences between open and closed source development, paying specific attention to the difficulties of designing, discussing, and writing software in an environment where anyone can poke their nose in to offer an opinion, contribute a patch, or criticize the most minute aspect of your product.


After going over these challenges, we told the team they needed to come up with a mission statement as a way to describe to the public at large what their product goals (and nongoals!) were.


Some of the team members balked at this for many of the reasons outlined earlier, but others seemed curious, and the team lead seemed to think it was a great idea. However, when we sat down to start writing the mission statement, a lot of debate about the content, substance, and style of the mission statement ensued.


After a great deal of discussion (and a few more meetings), the team came up not only with a great, concise mission statement, but also an entire document called “Making GWT Better” explaining the statement phrase by phrase. They even included a section that described what the project’s nongoals were. Here’s the mission statement:


GWT’s mission is to radically improve the web experience for users by enabling developers to use existing Java tools to build no-compromise AJAX for any modern browser.


There’s a ton of substance packed into that sentence, and we think it’s an excellent example of a mission statement: it includes both a direction (improve the web experience…by enabling developers) and a scope limiter (Java tools).


Several years later we were having dinner with the team lead, and Steve told him how thankful we were that he had supported us so strongly in our effort to get the team to write a mission statement.


He responded that he had actually thought the entire exercise was a waste of time when we first proposed it, but that once he started debating it with the team, he discovered something he’d never known: his lead engineers did not agree on the direction of the product!


In this case, writing a mission statement forced them to confront their differences and come to an agreement on their product’s direction, a problem that could have slowed down (or stopped) development of the product as time went on.


They posted their mission statement on the Web, and not only did the entire team have a laser focus on what they wanted to do with their product, but it saved them months of time arguing with potential contributors about the product’s direction—they just pointed newcomers to “Making GWT Better” and most questions were answered.


As your project progresses, the mission statement keeps things on track. It shouldn’t become an insurmountable impediment to change, however. If radical changes happen to the environment or business plan (say, at a startup company), software team members need to be honest with themselves and reevaluate whether the mission still makes sense.


Changing a constitution is a deliberately difficult process, as it prevents people from doing so whimsically. But in dramatic times it’s at least possible to change it and it should be considered. If a company or product pivots suddenly, the mission statement needs to keep up.



Most people would classify meetings as a necessary evil. While they can be highly effective when used skillfully, they’re frequently abused, usually disorganized, and almost always too long. We like our meetings like we like our sewage treatment plants: few, far between, and downwind. So we’ll keep this section brief and just cover team meetings.


Let’s start with the most dreaded meeting of all: the standing meeting. This meeting usually takes place every week, and should absolutely be kept to basic announcements and introductions—going around the room for a status update from every attendee (whether they have something important to add or not) is a recipe for wasted time, rolling eyes, and a burning desire to punch yourself in the throat just to make it end.


The anything worth deeper discussion should take place after the meeting, with only the relevant people sticking around for it. This is also a great way to avoid derailing a meeting when someone starts to do a deep dive into a particular meeting topic: the person running the meeting should just add the topic to a list of “sidebars” and once the meeting is over, review them one at a time.


If your team makes this a habit, it’s easy to call “sidebar” on something that’s getting off-track without putting anyone off.


The key to making this meeting work is that people should be happy to leave the meeting once the main part of it is done, and if there’s nothing that needs to be covered or information that can be disseminated by email, don’t hesitate to cancel the meeting.


We’ve seen some cultures where meeting attendance is equated with status, so nobody wanted to be left out. Not to put too fine a point on it, but that is patently insane.


Daily standups

Some engineers swear by daily standups that are promoted by development methodologies like Agile, and these are acceptable if they are kept short and on point.


These meetings usually start their lives short—15 minutes—with everyone actually standing up and giving a brief update on what they’re working on, but without constant vigilance, they tend to quickly turn into 30-minute-long sit-down meetings where people ramble on and on like they’re in a group therapy session.


If your team is going to have these meetings, someone needs to run them with authority and keep their growth in check.


If you’re trying to design something new, try to include no more than five people in your meeting—it’s practically impossible to come up with new designs and make decisions with more than five people in a room unless there’s only one person in the room making the decisions.


If you don’t believe us, get five of your friends together, go downtown, and try to decide among the six of you how to do a walking tour that hits half a dozen tourist sites.


The odds are good that you’ll stand on the street corner arguing for most of the day unless you simply declare one person to be the final arbiter and then follow her wherever she goes.


Meetings are frequently an interruption to what many refer to as “make time,” inspired by Paul Graham’s “Maker’s Schedule, Manager’s Schedule.”


It can be hard for anyone, especially engineers, to get into the zone if they’re constantly stopping work to attend meetings. Schedule time on your calendar in three- to four-hour blocks and label these blocks as “busy” or even “make time,” and get your work done.


If you have to set up a meeting, try to set it up near another natural break in the day, like lunchtime, or at the very end of the day.


At Google, there’s a long (and unfortunately, often ignored) tradition of “No-meeting Thursdays” in the interest of clearing time to just get work done. This is a good first step on the path to having 20 to 30 hours of make time set aside in larger blocks.



Five simple rules for running a meeting:

  • 1. Only invite people who absolutely need to be there.
  • 2. Have an agenda and distribute it well before the meeting starts.
  • 3. End the meeting early if you’ve accomplished the meeting’s goals.
  • 4. Keep the meeting on track.
  • 5. Try to schedule the meeting near other interrupt points in your day (e.g., lunch, end of day).


If you’re going to have a meeting, create an agenda and distribute it to all attendees at least a day before the meeting so that they’ll know what to expect. Invite a few people as possible (remember the cost of synchronous communication). We know team members, managers, and even directors and VPs who will flat out ignore invitations to a meeting that has no agenda.


Only invite people to the meeting who actually need to be there for the meeting to accomplish its goal.


Some people have taken to banning laptops in meetings after they’ve noticed attendees reading email instead of paying attention, but this is attacking the symptom and not the cause—people start reading email in a meeting because they probably don’t need to be in the meeting in the first place.


Whoever’s running the meeting should actually run the meeting and not hesitate to (gently) cut off someone who veers off-topic or, even worse, tries to monopolize the conversation. Doing this well can be tricky, but is worthwhile. And most importantly, don’t be afraid to end a meeting early if you’ve completed the agenda.



When you’re part of a distributed team or working remotely from them, you not only need to find different ways to communicate but also need to put more work into communication, period.


If you’re on a team that has remote workers, this means documenting and sharing decisions in writing, usually over email.


Online chats, instant messages, and hallway conversations might be where a lot of discussion takes place, but there needs to be some way to broadcast relevant discussions like these to everyone to make sure they’re informed and participating (and as a bonus, archived email lists provide documentation).


Video chat is also incredibly useful as a quick conversation enabler, and besides, these days most laptops have built-in webcams.


In the Subversion project we had a motto: “If the discussion didn’t happen on the email list, then it never really happened.” People spent lots of time bandy-ing around ideas in chat rooms, but in order to make the resolutions “real,” we had to be mindful of everyone else who didn’t witness them.


By forcing conversations to report to email lists, we gave the entire distributed team a chance to see how decisions were arrived at (and to speak up if they wanted to). This is particularly critical if you’re trying to encourage a consensus-based team culture.


Talking to someone from a remote location should be as frictionless as walking over to their desk.


If you’re working remotely, overcommunicate with your team using every available medium (e.g., online chat, instant messages, email, video chat, phone calls, etc.) to make sure everyone knows not only that you exist, but also what you’re working on.


And most important of all, do not underestimate the bandwidth of a face-to-face conversation.


Steve once had an engineer who was working with a team in Colorado, and she was having trouble getting momentum on the project that she was sharing with them. She pulled Steve aside to tell him this and he told her that she should hop on a flight to Colorado and spend a week with the team to kickstart their project.


Two weeks later, she emailed Steve from Colorado, after spending only a day there, with great news—not only had she gained great momentum on the project, but she was getting along great with the team after joining them for lunch and drinks after work.


Ben once had a team member, Corey, who started a new project with a team in another office. Corey was having a bit of a tough time getting traction with the new team and lamented this to Ben in their weekly one-on-one.


Ben told Corey that he should fly out to the team’s office and sit with them for a week to kick off the project. Corey was hesitant because of the cost of a flight and hotel, but he wasn’t accounting for the benefit of the trip.


Corey took a two-day trip to work with the team and he immediately realized how valuable it was to be there with the team. Not only did he gain the benefit of the additional bandwidth of in-person conversation, but, by having lunch together, and going out together after work one day, Corey and the team all got to know each other as people.


As a result, future interactions with the team went much more smoothly, despite the fact that Corey was a thousand miles away.


Nothing replaces being in the same room

One thing to note about all of these people is that, despite all the advances in social media and video conferencing technology, nothing even comes close to the bandwidth and the intimacy of being face to face with someone else in real life.


If you’re starting a new project or have an important meeting with someone in your company and you have the budget to be there in person, it’s almost always worth the hassle of traveling. The impact of an in-person discussion etches itself into memory in ways that phone or video chats can’t compete with.


A frequent argument against business travel is that it’s too expensive or, in some cases, not affordable. While this may be the case for small geographically distributed companies, most large companies can afford this expense. The cost of not spending face time with your colleagues is higher than you think.


No matter how much your email, chat, or call, don’t be afraid to regularly get on a plane and visit the rest of your team. This goes for remote employees, remote teams, and remote offices as well—make the time to get out to the home office and talk to people.



If you’re an engineer, it’s sometimes difficult to resist the urge to take a running leap into writing code for a new project, but this is rarely fruitful (unless you’re throwing together a quick and dirty prototype). Just the same, many engineers rush right into coding before designing the software they intend to write, and this usually ends very badly.


A design doc is typically owned by one person, authored by two or three, and reviewed by a larger set. It serves not only as a high-level blueprint of your future project but also as a low-cost way to communicate with your larger team what you want to do and how you intend to do it.


Since you haven’t spent weeks (or months) writing code, it’s a lot easier to accept criticism at this point and you’ll wind up with a better product and a better implementation.


In addition, once you’ve nailed down the design doc, it will serve as your guide for both scheduling and dividing the work on your project.


Once you start coding, however, you should treat your design doc as a living document and not one carved in stone: you and your team should update the document as your project grows and changes, not once you’ve shipped, although this is easier said than done.


Most teams have no docs at all, while the rest have a short period of awesome docs, followed by a long period of out-of-date docs.


Having said that, make sure you don’t take the “design doc religion” to the opposite extreme. We’ve seen control freaks write a four-page design essay for a program that’s only 100 lines of code.


If the project can be rewritten from scratch several times in the same amount of time it takes to write a design doc, a design doc is clearly a waste of time. Use experience and judgment when making these time calculations and trade-offs.


Day-to-Day Discussions

Assuming high-level goals are agreed upon, you need to worry about the tools your team uses for everyday coordination. These tools are useful, but they tend to have narrow communication bandwidth and, usually, a complete lack of meta-data and secondary communication channels such as facial expressions and body language.


As a result, they’re more conducive to miscommunication and an inherent threat to HRT. Still, these tools are invaluable to most teams and (with a little effort) can give a good boost to productivity.



We don’t know of anyone who works with a team these days that doesn’t use at least one mailing list, but there are a few things you can do with your mailing lists to make them more useful.


Many big successful projects have multiple mailing lists, separating development discussions, code reviews, user discussions, announcements, pager emails, and miscellaneous administrivia.


Sometimes smaller projects attempt to emulate this as they’re just getting started and create half a dozen mailing lists when they’ve only got three engineers and two users.


This is the mailing list equivalent of providing six conference rooms for five people to carry on a discussion—you wind up with little coherence, a lot of echoes, and mostly empty rooms.


It’s really best to start with one list and to add lists only when the amount of traffic on one list gets unmanageable (which is typically indicated by list members begging for mercy).


An exception to that rule is to have automated emails and “bot” notifications go to their own list or at the very least use identifiers that make them easy to filter.


Take some time to establish proper etiquette around email discussions— keep discussions civil, and prevent filibustering by a “noisy minority.”

A mailing list isn’t going to be your first choice for a discussion in a team that shares an office, but it’s a good idea to send a copy of meeting agendas, meeting notes, decisions made, design docs and any other relevant textual information to your team’s mailing list so that you have a convenient central record.


Set up these lists to archive all posts in a searchable index, either publicly available in the case of open source projects or on your company’s intranet if you’re working on a closed source project.


Now you have a system of record for the history of your project, and it’s easy to refer back to it when a newcomer asks about the reasoning behind one or more decisions that you made in the past. If you don’t have these discussions archived somewhere, you’ll find yourself repeating them again and again and again and again.



Online chat is an incredibly convenient way for teams to communicate, especially since it provides a way to send a quick request to a teammate without interrupting her work (providing, of course, she has her chat program configured to not interrupt her work!).


It’s a good tool for teams to use if they’re moving quickly on a new project, doing some light work in the evening or on the weekend, or if one team member is out of the office for a day or two.


One-on-one chat is useful and certainly has its place in team communication, but we strongly recommend that teams use some sort of group chat mechanism.


Years before instant messaging became wildly popular, teams would hang out in an Internet Relay Chat (IRC) channel and most of their discussions would be in a group chat.


This could be noisy at times, and it was easy enough for team members to break off to have a private chat if they were discussing something that was not of interest to the larger team, but in most cases, discussions happened “in front of” the rest of the team.


This allowed other people to join in on the conversation, lurk in the background and follow the discussion, or even catch up on discussions they missed earlier. This is convenient not only because of the ease with which ad hoc group discussions can start but also because it helps to build community even in teams that are geographically dispersed.


It’s often surprising how much a newer team member can learn just by watching (or later reading) various discussions he’s not necessarily participating in.


With the advent of instant messaging, many of these conversations that would previously take place in the group chat room moved to private chat, which was the default for instant messenger.


It’s very tempting to indulge your insecurity and take what might be perceived as a stupid question to a one-on-one discussion rather than risk embarrassment in front of the rest of the team.


Unfortunately, this increases the burden on the team because there’s no shared lore created and different team members may ask other team members the same question over and over again.


Fortunately, group chat has seen a renaissance in 2014/2015 with the rise of Slack, a free (but not free software or open source) group messaging client that feels a lot like a modern-day IRC.


Slack integrates with dozens of other products and has become the messaging tool of choice in smaller companies, startups, and even loosely connected groups of acquaintances on the Internet.


While it still provides a means to send private messages, team owners get a weekly report telling them the percentage of private messages versus group messages. This makes it easy to give your team a gentle “push” to have more discussions in the group channels rather than one-on-one.


Regardless of the application you use for chat, we strongly recommend that your team have a convenient and accessible mechanism for group chat. It’s well worth the effort in order to have this additional communication bandwidth in your team.


Group chat versus 1:1 instant messages

When many people first hear about IRC these days, they scoff at its primitive text-based environment because even the most modern of IRC clients tend to be less whizzy than outdated versions of iChat or Google Talk.


Don’t be fooled by the outdated look and feel of IRC—its killer features are that it was designed for a multiperson chat and it’s asynchronous; most clients keep an unlimited scroll-back record so that you can read back to see conversations among others that you missed.


Slack is basically the modern-day version of IRC, and despite its whizzy integration of graphics, avatars, and emoji, at its heart, it’s still a text-based messaging system like IRC.


It may be tempting to try out fancy video conferencing packages, shared whiteboard systems, and more, but these systems often tend to be ineffective and can eliminate the asynchronous advantage of text-based group chat.


If you’re going to use something other than Slack or IRC, find something that is actually designed for group chat and isn’t just an instant messaging system with group chat bolted on.


Sometimes people are more comfortable chatting online: we remember the first time we went to a hackathon where a number of open source contributors were going to meet (many for the first time) face to face and work on their projects together.


We walked into an almost silent room to find a dozen tables— with six to eight people per table—furiously typing away at their laptops.


We figured that, well, we were late, and everyone was already busy writing code, so we sat down, opened our laptops, fired up our editors, and signed on to the project’s IRC channel to see if folks who couldn’t make it to the hackathon were “virtually” there. We found a number of conversations taking place in the IRC channel.


We said hello and mentioned that we’d just arrived at the hackathon room, and imagine our surprise when several people said hello in the IRC channel when they turned out to be sitting less than 10 feet away from us!


Some of this was purely inertia as we were all used to chatting online, but in many cases, it was just the most comfortable way for some people to communicate with the rest of the group.


Fresh off a four-hour flight and desperate for some communication bandwidth, we got up and went from table to table to talk with people face to face.


There are no hard and fast rules for when to use chat versus email. Chat is more useful for fast-moving real-time discussions where a decision can be made easily and all participants are currently available.


If some participants aren’t around or the discussion is less pressing, email might be better. Just keep in mind the costs of synchronous versus asynchronous communication.


Using an Issue Tracker

If you’re going to use an issue/bug tracker (and you should), it’s important that you have some sort of process in place for processing and triaging bugs to encourage people to file and fix important bugs in a timely manner.


If your bug tracker is neglected and not prioritized, people will stop filing bugs and begin shouting complaints into the void; and when your team eventually digs into the bug tracker, more than likely they will be fixing unimportant bugs and ignoring important ones.


Keep in mind that a bug tracker is really just a slightly specialized “Internet forum” or “bulletin board.” As such, it shares most properties in common with email lists and the same best practices apply.


Hallway conversations about bugs should be recorded as updates in the bug tracker, making thoughts and decisions “official” for all to see. Keep the tone civil and don’t tolerate trollish behaviors.


We’ve also seen numerous occasions where a project manager is assigned the task of checking in on all open issues in the issue tracker. This can often not only create a great deal of churn but also lead team members to start lengthy conversations in the issue tracker.


If conversations get overly long or fragmented, take the discussion temporarily to the main email list—an email client is a much better tool for complex threads.


Communication as Part of Engineering

Hundreds and hundreds of blogs have been written about the software development process. While we’re not going to dig into them all here, there are a few communication-related highlights that deserve mention, regardless of the development methodology you use.


Even if you don’t write software, there are a few lessons to be learned here—especially lessons about what not to do.



Code commenting style is very subjective. Verbose comments can often provide clues regarding the intent and reasoning of the original programmer and can be very useful, but at the cost of ongoing maintenance: out-of-date or incorrect comments drastically hinder understanding of a code base.


Similarly, terse or non-existent comments can cause future maintainers or API consumers to waste time sleuthing. Comments are often used to point out the missing structure and bad naming, and then go on to re-explain what the code already says. Comments should be focused on why the code is doing what it’s doing, not what the code is doing.


Comments are most useful at the function or method level, especially as a means of documenting an API, and without going into exhaustive details, comments can be summed up with the popular Greek maxim, “μηδέν άγαν,” or “nothing in excess.”


Beyond that, take the time to come up with a commenting style for your team and have everyone stick to it—we think being consistent is more important than the actual choice.


Your style guide should also explain the reason the guide exists and what it intends to prescribe—for example, here’s the introduction to the Google C++ Style Guide:


C++ is the main development language used by many of Google’s open-source projects. As every C++ programmer knows, the language has many powerful features, but this power brings with it complexity, which in turn can make the code more bug-prone and harder to read and maintain.


The goal of this guide is to manage this complexity by describing in detail the dos and don’ts of writing C++ code. These rules exist to keep the code base manageable while still allowing coders to use C++ language features productively. 


Style, also known as readability, is what we call the conventions that govern our C++ code. The term Style is a bit of a misnomer since these conventions cover far more than just source file formatting.


One way in which we keep the code base manageable is by enforcing consistency. It is very important that any programmer be able to look at another’s code and quickly understand it.


Maintaining a uniform style and following conventions means that we can more easily use “pattern-matching” to infer what various symbols are and what invariants are true about them.


Creating common, required idioms and patterns makes code much easier to understand. In some cases, there might be good arguments for changing certain style rules, but we nonetheless keep things as they are in order to preserve consistency.


Another issue this guide address is that of C++ feature bloat. C++ is a huge language with many advanced features. In some cases, we constrain, or even ban, use of certain features.


We do this to keep code simple and to avoid the various common errors and problems that these features can cause. This guide lists these features and explains why their use is restricted.


Open-source projects developed by Google conform to the requirements in this guide.


Note that this guide is not a C++ tutorial: we assume that the reader is familiar with the language.

Note that the guide doesn’t make claims about enforcing the best or fastest way to write C++, but merely the importance of having consistency across the code base.



Everyone wants to get credit for work they do, from the artist who signs her painting to the author who puts her name on the spine of her blog or the top of her blog. It’s human nature to crave recognition in one way or another, but littering source files with your name are, in our opinion, more trouble than it’s worth.


The tradition of putting your name at the top of your source code is an old one (heck, both of us have done it in the past), and may have been appropriate in an age where programs were written by individuals and not teams.


Today, however, many people may touch a particular piece of code, and the issue of name attribution in a file is the cause of much discussion, wasted time, and hurt feelings.


As a result, we advocate strongly against names as a sign of ownership in source code files (at best, include a name to designate a first choice to review any changes you might make to the file, but be careful that you don’t imply ownership).


Let’s imagine, for example, that you create a new file in your team’s project—you write a few hundred lines of code, smack your name and the appropriate copyright header at the top of the file and send it off for code review, and later, commit it to the repository.


No problems, no drama, no disagreements so far. Let’s say that your teammate Adrian comes along and makes some changes to the file: at what point does he get to put his name at the top of the file? Does he have to fix a bug? Five bugs? Does he have to write a function? Two functions?


How many lines of code does he have to write? What if he writes a function, slaps his name on the file, and then someone else comes along and rewrites “his” function? Does this person now get to put her name on the file? Does she get to take Adrian’s name off?


Unlike other collaborative pieces of creative work—plays, novels, films—software keeps changing even after it’s “done.” So, while listing contributor credits at the end of a movie is a safe and static thing, attempting to add and remove names from a source file is a never-ending exercise in insanity.


Certainly, you can answer all these questions and extensively document every possible edge case, but maintaining this, tracking it, and keeping an eye out for violations is an incredible waste of time—time that could be spent actually writing code. It’s for this very reason that we advocate tracking credit at the project level, not in the code itself.


Most projects that we’ve seen have an “Authors” or “Contributors” file that lists everyone who has done work. If you need more detail, your version control system can tell you. Of course, if you don’t use version control, all those moments will be lost in time, like tears in rain.



If you’re going to have coding standards, you need to have a means of monitoring code going into your product. Whether you review the code before committing it or after committing it, you should make sure every line of code that goes into your repository gets a second pair of eyes on it to check for style, quality, and, of course, careless mistakes.


Keep code changes small and reviewable— changesets that are thousands of lines long are unreviewable for anything but formatting nits. This not only results in a higher-quality code base but also goes a long way toward instilling a strong sense of group pride in the quality of your code. 



Whether you’re a full-on test-driven development shop or you just have some simple regression tests for your product, the more automated tests you have for your product, the more confident you can be when you’re tearing through fixing bugs or adding new features.


Once your team determines the role that testing will play, it should be part of the coding and review process. Just as importantly, your release process should be lightweight enough that you can do frequent releases (e.g., weekly), but thorough enough that you catch brokenness before it hits your users.


It Really Is About Your Product, After All

Although these habits of culture and communication may seem to represent a certain amount of bias, as they reflect the manner in which we prefer to work, it’s not as subjective as you might think.


We’ve found that building a strong, productive team culture and taking some time to pay attention to communication in the team creates a team that will spend more time writing and shipping product and less time arguing about what product to ship.


Strong teams don’t arise spontaneously; they’re carefully seeded and cultivated by team leads and founders who understand the high cost of trying to write software with a dysfunctional team. Putting this work in from the outset helps to create a self-selecting culture that builds a team that will spend much more time designing and creating a product than defining and defending their culture.


A big side benefit of this effort—communication and process—is that it drastically reduces the barrier to entry for newcomers to your team. Without these elements in place, newcomers will either waste a lot of time struggling to learn how your team works or give up and try to make your team work like their last team did (for good or for bad).


While getting the right people on your team and the right values instilled in your team is important, the overwhelming majority of effort that goes into a culture turns out to be communication.


Mission statements, meetings, mailing lists, online chat, code comments, documentation, and even decision-making processes all make up the many different ways your team communicates, both with itself and with others.


It’s often a surprise to people that it takes so much communication—including emotional time and effort—to build a strong team for the sole purpose of creating a product, but it’s true. Your product is ultimately about communications with people, not just with a machine.


No matter what your team’s culture is, and regardless of how well your team communicates, every effective team that we’ve ever seen has a leader.


In the next blog, we’ll look into what makes the most effective team leader, why her role is probably not what you think, and why it’s important for every team member to understand the basics of leading a team.


Every Boat Needs a Captain

Even if you’ve sworn on your mother’s grave that you’ll never become a “manager,” at some point in your career you’re going to accidentally trip and fall into a leadership position. This blog will help you understand what to do when this happens.


There are dozens of blogs already written for managers on the topic of management, but this blog is for individual contributors who find themselves in an unofficial position of leadership. Most people fear becoming managers for various reasons, yet no team can function without a leader.


We’re not here to attempt to convince you to become a manager (even though we’re both managers now!), but rather to help show why teams need leaders, why people typically fear becoming managers, and why the best leaders work to serve their team using the principles of humility, respect, and trust. Beyond that, we’ll delve into leadership patterns and antipatterns, and motivation.


Understanding the ins and outs of leadership is a vital skill for influencing the direction of your work. If you want to steer the boat for your project and not just go along for the ride, you need to know how to navigate or you’ll run yourself (and your project) onto a sandbar.


Nature Abhors a Vacuum

A boat without a captain is nothing more than a floating waiting room—unless someone grabs the rudder and starts the engine, it’s just going to drift along aimlessly with the current. A project is just like that boat: if no one pilots it, you’re left with a group of geeks just sitting around waiting for something to happen.


Whether officially appointed or not, someone needs to get into the driver’s seat if your project is ever going to go anywhere, and if you’re the motivated, impatient type, that person might be you. You may find yourself sucked into helping your team resolve conflicts, make decisions, and coordinate people.


It happens all the time, and often by accident. You never intended to become a “leader,” but somehow it happened anyway. Some people refer to this affliction as “managers.”


Manager Is a Four-Letter Word

The present-day concept of the pointy-haired manager is partially a carryover, first from military hierarchy and later adopted by the Industrial Revolution— more than 100 years ago! Factories started popping up everywhere, and they required (usually unskilled) workers to keep the assembly lines moving.


Consequently, these workers required supervisors to manage them, and since it was easy to replace these workers with other people who were desperate for a job, the managers had little motivation to treat their employees well or improve conditions for them. Whether humane or not, this method worked well for many years when the employees had nothing more to do than perform rote tasks.


Managers frequently treated employees in the same way that cart drivers would treat their mules: they motivated them by alternately leading them forward with a carrot, and, when that didn’t work, whipping them with a stick.


This “carrot and stick” method of management survived the transition from the factory to the modern office, where the stereotype of the hard-ass manager-as-mule-driver flourished in the middle part of the 20th century when employees would work at the same job for years and years (frequently relying on their pension as well).


This continues today in some industries—even in industries that require creative thinking and problem solving—despite numerous studies suggesting that the anachronistic carrot and stick is ineffective and harmful to the productivity of creative people.


While the assembly-line worker of years past could be trained in days and replaced at will, knowledge workers can take months to get up to speed on a new team. Unlike the replaceable assembly-line worker, these people need nurturing, time, and space to think and create.



Most people still use the title “manager” despite the fact that it’s often an anachronism. We think the term manager should be eliminated and the term leader should be used instead.


While we’re hardly members of the stalwart, politically correct crowd, the word manager has become a four-letter word—a role whose very existence encourages new managers to manage their reports.


Managers wind up acting like parents, and consequently, employees react like children. To frame this in the context of HRT: if the manager makes it obvious that she trusts her employee, the employee feels positive pressure to live up to that trust.


It’s that simple. A leader forges the way for a team, looking out for their safety and well-being, all while making sure their needs are met. If there’s one thing you remember from this blog, make it this:


Traditional managers worry about how to get things done, while leaders worry about what things get done…(and trust their team to figure out how to do it). Steve had a new engineer join his team a few years ago.


Jerry’s last manager (at a different company) was adamant that Jerry is at his desk from 9:00 to 5:00 every day, and assumed that if Jerry wasn’t there, Jerry wasn’t working enough (which is, of course, a ridiculous assumption). 


On his first day working with Steve, Jerry came to Steve at 4:40 p.m. and stammered out an apology that he had to leave 15 minutes early because he had an appointment that he had been unable to reschedule.


Steve looked at him, smiled, and told him flat out, “Look, as long as you get your job done, I don’t care what time you leave the office.” Jerry stared blankly at Steve for a few seconds, nodded, and went on his way.


Steve treated Jerry like an adult, Jerry always got his work done, and Steve never had to worry about Jerry being at his desk because Jerry didn’t need a babysitter.


Being a “leader” doesn’t necessarily mean you have ultimate responsibility for absolutely everything. There are different types of leadership, some technical and some personal. In the software development world, there are two distinct roles (and titles) for people leading a team: TL (tech lead) and TLM (tech lead manager).


A TL is typically responsible for the technical direction for all (or part) of a product, while a TLM is responsible for the technical direction for all (or part) of a product in addition to the careers and happiness of the people on the team. This enables those who want to focus on leading a project to avoid the people management part of being a leader if they want to.



Aside from the general sense of malaise that most people feel when they hear the word manager, there are a number of reasons that most people don’t want to become managers.


The biggest reason you’ll hear in the software development world is that you spend much less time writing code, which is true whether you’re a technical leader or a people leader. We’ll talk more about that later, but first, some more reasons why most of us avoid becoming managers.


If you’ve spent the majority of your career writing code, you typically end a day with something you can point to—whether it’s code, a design document, or a pile of bugs you just closed—and say, “That’s what I did today.”


Based on this metric of productivity, at the end of a busy day of “management”, you’ll usually find yourself thinking, “I didn’t do a damned thing today.”


It’s the equivalent of spending years counting the number of apples you picked each day and changing to a job picking bananas, only to say to yourself at the end of each day, “I didn’t pick any apples,” handily ignoring the giant pile of bananas sitting next to you.


Quantifying management work is more difficult than counting widgets you turned out, and you don’t have to take credit for your team’s work; however, making it possible for them to be happy and productive is a big measure of your job. Just don’t fall into the trap of counting apples when you’re picking bananas.


Another big reason for not becoming a manager is often unspoken but rooted in the famous “Peter Principle,” which states that “In a hierarchy, every employee tends to rise to his level of incompetence.” Most people have had a manager who was incapable of doing her job or was just really bad at managing people, and we know some people who have only worked for bad managers.


If you’ve only been exposed to crappy managers for your entire career, why would you ever want to be a manager? Why would you want to be promoted to a role that you weren’t able to do?


There are great reasons to consider becoming a manager: first, it’s a way to scale yourself. Even if you’re great at writing code, there’s still an upper limit to the amount of code you can write. Imagine how much code a team of great engineers could write under your leadership!


Second, you might just be really good at it—many people who find themselves sucked into the leadership vacuum of a project discover that they’re exceptionally skilled at providing the kind of guidance, help, and air cover a team needs.


The Servant Leader

There seems to be a sort of disease that strikes new managers where they forget about all the awful things their managers did to them and suddenly start doing these same things to “manage” the people that report to them.


The symptoms of this disease include, but are by no means limited to, micromanaging, ignoring low performers, and hiring pushovers. Without prompt treatment, this disease can kill an entire team.


The best advice we got when we first became managers at Google was from Steve Vinter, an engineering director. He said, “Above all, resist the urge to manage.” One of the greatest urges of the newly minted manager is to actively “manage” her employees because that’s what a manager does, right? This typically has disastrous consequences.


The cure for the “management” disease is a liberal application of what we call “servant leadership,” which is a nice way of saying the most important thing a leader can do is to serve her team, much like a butler or majordomo tends to the health and well-being of a household. As a servant leader, you should strive to create an atmosphere of humility, respect, and trust (HRT).


This may mean removing bureaucratic obstacles that a team member can’t remove by herself, helping a team achieve consensus, or even buying dinner for the team when they’re working late at the office. The servant leader fills in the cracks to smooth the way for her team and advises them when necessary, but still isn’t afraid of getting her hands dirty.


The only managing that a servant leader does is to manage both the technical and social health of the team; as tempting as it may be to focus purely on the technical health of the team, the social health of the team is just as important (but often infinitely harder to manage!).



Before we go over a litany of “design patterns” for successful leaders, we’re going to review a collection of the patterns you don’t want to follow if you want to be a successful leader. We’ve observed these destructive patterns in a handful of bad leaders we’ve encountered in our careers, and in more than a few cases, ourselves.



If you’re a manager and you’re feeling insecure in your role (for whatever reason), one way to make sure no one questions your authority or threatens your job is to hire people you can push around. You can achieve this by hiring people who aren’t as smart or ambitious as you are, or just people who are more insecure than you.


While this will cement your position as the team leader and decision maker, it will mean a lot more work for you. Your team won’t be able to make a move without you leading them like dogs on a leash.


If you build a team of push-overs, you probably can’t take a vacation; the moment you leave the room, productivity comes to a screeching halt. But surely this is a small price to pay for feeling secure in your job, right?


Instead, you should strive to hire people who are smarter than you and can replace you. This can be difficult because these very same people will challenge you on a regular basis (in addition to letting you know in no uncertain terms when you screw up). These very same people will also consistently impress you and make great things happen.


They’ll be able to direct themselves to a much greater extent, and some will be eager to lead the team as well. You shouldn’t see this as an attempt to usurp your power, but rather as an opportunity for you to lead an additional team, investigate new opportunities, or even take a vacation without worrying about checking in on the team every day to make sure they’re getting their work done.



Early in Steve’s career as a team leader at Google, the time came for him to hand out bonus letters to his team, and he grinned as he told his manager, “I love being a manager!” Without missing a beat, Steve’s manager, a long-time industry veteran, replied, “Sometimes you get to be the tooth fairy, other times you have to be the dentist.”


It’s never any fun to pull teeth. We’ve seen team leaders do all the right things to build incredibly strong teams, only to have these teams fail to excel (and eventually fall apart) because of just one or two low performers.


We understand that the human aspect is the hardest part of writing software, but the hardest part of dealing with humans is handling someone who isn’t meeting expectations.


Sometimes people miss expectations because they’re not working long enough or hard enough, but the most difficult cases are when someone just isn’t capable of doing his job no matter how long or hard he works.


The team at Google that is responsible for keeping all of their services running has a motto: “Hope is not a strategy.” And nowhere is hoped more overused as a strategy than in dealing with a low performer.


Most team leaders grit their teeth, avert their eyes, and just hope that the low performer either magically gets better or just goes away. Yet it is extremely rare that this person does either.


While the leader is hoping and the low performer isn’t getting better (or leaving), high performers on the team waste valuable time pulling the low performer along and team morale leaks away into the ether.


You can be sure that the team knows they’re there even if you’re ignoring them—the rest of the team is acutely aware of who the low performers are because they have to carry them.


Ignoring low performers is also a way to keep new high performers from joining your team, and a way to encourage existing high performers to leave. You eventually wind up with a whole team of low performers because they’re the only ones who can’t leave of their own volition.


Lastly, you aren’t even doing the low performer any favors by keeping him on the team; often, someone who wouldn’t do well on your team would actually have plenty of impacts somewhere else.


The benefit of dealing with a low performer as quickly as possible is that you can put yourself in the position of helping him up or out. If you deal with a low performer right away, you’ll oftentimes find that he merely needs some encouragement or direction to slip into a higher state of productivity.


If you wait too long to deal with a low performer, his relationship with the team is going to be so sour and you’re going to be so frustrated that you’re not going to be able to help him.


How does one coach a low performer effectively? It turns out that the two of us have (unfortunately) had quite a lot of experience in this area, gained through painful trial and error. The best analogy is to imagine you’re helping a limping person learn to walk again, then jog, then run alongside the rest of the team.


It almost always requires temporary micromanagement—but still a whole lot of HRT, particularly respect. Set up a specific time frame (say, two or three months), and some very specific goals you expect him to achieve in that period.


Make the goals small and incremental, so there’s an opportunity for lots of small successes. Meet with the team member every week to check on progress, and be sure you set really explicit expectations around each upcoming milestone, so it’s easy to measure success or failure. If the low performer can’t keep up, it will become quite obvious to both of you early in the process.


At this point, the person will often acknowledge that things aren’t going well and decide to quit; in other cases, a determination will kick in and he’ll “up his game” to meet expectations. Either way, by working directly with the low performer you’re catalyzing important and necessary changes.



As we’ve said before, a team leader has two major areas of focus for his team: the social and the technical. It’s rather common for leaders to be stronger in the technical side, and since most leaders are promoted from a technical job (where the primary goal of their job was to solve technical problems), they tend to ignore human issues.


It’s tempting to focus all your energy on the technical side of your team because, as an individual contributor, you spend the vast majority of your time solving technical problems.


When you were a student, your classes were all about learning the technical ins and outs of your work. Now that you’re a leader, however, you ignore the human element of your team at your own peril.


Let’s start with an example of a leader ignoring the human element in his team. Years ago, a close friend of Steve’s—we’ll call him Jake—had his first child. Jake and Steve had worked together for years, both remotely and in the same office, so in the weeks following the arrival of the new baby, Jake worked from home.


This worked out great for Jake and his wife, and Steve was totally fine with it as he was already used to working remotely with Jake.


They were their usual productive selves until their manager, Pablo (who worked in a different office), found out that Jake was working from home for most of the week. Pablo was upset that Jake wasn’t going into the office to work with Steve, despite the fact that


Jake was just as productive as always and that Steve was fine with the situation. Jake attempted to explain to Pablo that he was just as productive as he would be if he came into the office and that it was much easier on both him and his wife for him to mostly work from home for a few weeks.


Pablo’s response: “Dude, people have kids all the time. You need to go into the office.” Needless to say, Jake (normally a mild-mannered engineer) was enraged and lost a lot of respect for Pablo.


There are numerous ways that Pablo could have handled this differently: he could have shown some understanding that Jake wanted to be home more for his wife and, if his productivity and team weren’t being affected, just let him continue to do so for a while.


He could have negotiated that Jake go into the office for one or two days a week until things settled down. Regardless of the end result, a little bit of empathy would have gone a long way toward keeping Jake happy in this situation.



The first foray that most people have into leadership is when they become the leader of a team of which they were formerly members. Many leads don’t want to lose the friendships they’ve cultivated with their teams, so they will sometimes work extra hard to maintain friendships with their team members after becoming a team leader.


This can be a recipe for disaster and for a lot of broken friendships. Don’t confuse friendship with leading with a soft touch: when you hold power over someone’s career, he may feel pressure to artificially reciprocate gestures of friendship.


Remember that you can lead a team and build consensus without being a peer of your team (or a monumental hard-ass). Likewise, you can be a tough leader without tossing your existing friendships with the wind.


We’ve found that having lunch with your team can be an effective way to stay socially connected to them without making them uncomfortable—this gives you a chance to have informal conversations outside the normal work environment.


Sometimes it can be tricky to move into a management role over someone who has been a good friend and a peer. If the friend who is being managed is not self-managing and is not a hard worker, it can be stressful for everyone. We recommend that you avoid getting into this situation whenever possible.



Steve Jobs once said: “A people hire other A people; B people hire C people.” It’s incredibly easy to fall victim to this adage, and even more so when you’re trying to hire quickly.


A common approach we’ve seen is that a team needs to hire five engineers, so they sift through their pile of applications, interview 40 or 50 people, and pick the best 5 regardless of whether they meet the hiring bar. This is one of the fastest ways to build a mediocre team.


The cost of finding the right person—whether by paying recruiters, paying to advertise, or pounding the pavement for references—pales in comparison to the cost of dealing with an employee you never should have hired in the first place.


This “cost” manifests itself in lost team productivity, team stress, time spent managing the employee up or out, and the paperwork and stress involved in firing the employee. That’s assuming, of course, that you try to avoid the monumental cost of just leaving him on the team.


If you’re managing a team where you don’t have a say over hiring and you’re unhappy with the hires being made for your team, you need to fight tooth and nail for higher-quality engineers.


If you still keep getting handed substandard engineers, maybe it’s time to look for another job. Without the raw materials for a great team, you’re doomed.



The best way to show your team you don’t trust them is to treat them like kids— people tend to act the way you treat them, so if you treat them like children or prisoners, don’t be surprised when that’s how they behave.


You can manifest this behavior by micromanaging them or simply by being disrespectful of their abilities and giving them no opportunity to be responsible for their work.


If it’s permanently necessary to micromanage people because you don’t trust them, you’ve got a hiring failure on your hands. Well, it’s a failure unless your goal was to build a team that you can spend the rest of your life babysitting.


If you hire people worthy of trust and show these people you trust them, they’ll usually rise to the occasion (sticking with the basic premise, as we mentioned earlier, that you’ve hired good people).


Steve runs a conference in Chicago that used to be at a site rented from a local institution. The first time Steve went to get access to the venue for the conference, the facilities manager gave Steve a brief tour of the place to make sure he knew where everything was. The manager then handed him the key to the building and told Steve that he’d get the key back from him next week.


There was no list of “dos and dont’s,” and no extensive supervision for the event, and as a result Steve and his team felt responsible for taking take care of the facility as though it were their own, going above and beyond the expectations of keeping the place clean and organized.


The results of this level of trust go all the way from keys to a building to office and computer supplies. As another example, Google provides employees with cabinets stocked with various and sundry office supplies (e.g., pens, noteblogs, and other “legacy” implements of creation) that are free to take as employees need them.


The IT department runs numerous “Tech Stops” that provide self-service areas that are like a mini electronics store. These contain lots of computer accessories and doodads (e.g., power supplies, cables, mice, USB drives, etc.) that would be easy to just grab and walk off with, but since Google employees are being entrusted to check these items out, they feel a responsibility to Do The Right Thing.


Many people from typical corporations react in horror to hearing this, exclaiming that surely Google is hemorrhaging money due to people “stealing” these items. That’s certainly possible, but what about the costs of having a workforce that behaves like children? Surely that’s more expensive than the price of a few pens and USB cables.


Leadership Patterns

These are a collection of behavior patterns for successful leadership that we’ve learned from experience, from watching other successful leaders, and, most of all, from our own leadership mentors.


These patterns are not only those that we’ve had great success in implementing but the patterns that we’ve always respected the most in the leaders that we follow.



It’s especially important when you’re playing the role of a servant leader. This pattern is frequently misunderstood as encouraging leaders to be a doormat and let their team walk all over them, but that’s not the case at all.


We admit that there’s a fine line between being humble and letting others take advantage of you, but humility is not the same as lacking confidence.


You can still have self-confidence and opinions without being an egomaniac. Big personal egos are hard to handle on any team, especially in the team’s leader. Instead, you should work to cultivate a strong collective team ego and identity. 


Part of “losing the ego” is something we’ve covered already: you need to trust your team. That means respecting the abilities and prior accomplishments of the team members, even if they’re new to your team.


If you’re not micromanaging your team, you can be pretty certain the folks working in the trenches know the details of their work better than you do.


This means that while you may be the one driving the team to consensus and helping to set the direction, the nuts, and bolts of how to accomplish your goals are best decided by the people who are putting the product together.


This gives them not only a greater sense of ownership but also a greater sense of accountability and responsibility for the success (or failure!) of their product.


If you’ve got a good team and you let them set the bar for the quality and rate of their work, they’ll accomplish more than they would by you standing over them with a carrot and a stick.


Most people new to a leadership role feel an enormous responsibility to get everything right, to know everything, and to have all the answers. We can assure you that you will not get everything right, nor will you have all the answers, and if you act as you do, you’ll quickly lose the respect of your team.


A lot of this comes down to having a basic sense of security in your role. Think back to when you were an individual contributor; you could smell insecurity a mile away.


Try to appreciate inquiry: when someone questions a decision or statement you made, remember that this person is usually just trying to better understand you. If you encourage inquiry, you’re much more likely to get the kind of constructive criticism that will make you a better leader of a better team.


Finding people who will give you good constructive criticism is incredibly difficult, and it’s even harder to get this kind of criticism from people who “work for you.” Think about the big picture of what you’re trying to accomplish as a team, and accept feedback and criticism openly; avoid the urge to be territorial.


The last part of losing the ego is a simple one, but many engineers would rather be boiled in oil than do it: apologize when you make a mistake.


And we don’t mean you should just sprinkle “I’m sorry” throughout your conversation like salt on popcorn—you have to sincerely mean it. You are absolutely going to make mistakes, and whether you admit it or not your team is going to know you’ve made a mistake.


They’ll know regardless of whether they talk to you or not (and one thing is guaranteed: they will talk about it with one another). Apologizing doesn’t cost money. People have enormous respect for leaders who apologize when they screw up, and contrary to popular belief it doesn’t make you vulnerable.


In fact, you’ll usually gain respect from people when you apologize, because apologizing tells people you are level-headed, good at assessing situations, and— coming back to HRT—humble.



As an engineer, you likely developed an excellent sense of skepticism and cynicism, but this can be a liability when you’re trying to lead a team. That’s not to say you should be naïvely optimistic at every turn, but you would do well to be less vocally skeptical while still letting your team know you’re aware of the intricacies and obstacles involved in your work.


Mediating your reactions and maintaining your calm is more important as you lead more people because your team will (both unconsciously and consciously) look to you for clues on how to act and react to whatever is going on around you.


A simple way to visualize this effect is to see your company’s org chart as a chain of gears, with the individual contributor as a tiny gear with just a few teeth all the way at one end, and each successive manager above her as another gear, ending with the CEO as the largest gear with many hundreds of teeth.


This means every time that individual’s “manager gear” (with maybe a few dozen teeth) makes a single revolution, the “individual’s gear” makes two or three revolutions.


And the CEO can make a small movement and send the hapless employee, at the end of a chain of six or seven gears, spinning wildly! The farther you move up the chain, the faster you can set the gears below you spinning, whether you intend to or not.


Another way of thinking about this is the maxim that the leader is always on stage. This means that if you’re in an overt leadership position, you are always being watched: not just when you run a meeting or give a talk, but even when you’re just sitting at your desk answering emails.


Your peers are watching you for subtle clues in your body language, your reactions to small talk, and your signals as you eat lunch. Do they read confidence or fear? As a leader, your job is to inspire, but inspiration is a 24/7 job. Your visible attitude about absolutely every-thing—no matter how trivial—is unconsciously noticed and spreads infectiously to your team.


Steve had a manager, Bill, who truly mastered the ability to maintain calm at all times. No matter what blew up, no matter what crazy thing happened, no matter how big the firestorm, Bill would never panic.


Most of the time he’d place one arm across his chest, rest his chin in his hand, and ask questions about the problem, usually to a completely panicked employee.


This had the effect of calming her and helping her to focus on solving the problem instead of running around in a chicken-with-its-head-cut-off mode. Steve used to joke that if someone came in and told Bill 19 of the company’s offices had been attacked by space aliens, Bill’s response would be, “Any idea why they didn’t make it an even 20?”


This brings us to another Zen management trick: asking questions. When a team member asks you for advice, it’s usually pretty exciting because you’re finally getting the chance to fix something!


That’s exactly what you did for years before moving into a leadership position, so you usually go leaping into solution mode, but that is the last place you should be.


The person asking for advice typically doesn’t want you to solve her problem, but rather to help her solve it, and the easiest way to do this is to ask her questions.


This isn’t to say you should replace yourself with a Magic 8 Ball, which would be maddening and unhelpful. Instead, you can apply some HRT and try to help her solve the problem on her own by trying to refine and explore her problem.


This will usually lead the employee to the answer, and it will be her answer, which leads back to the ownership and responsibility we went over earlier in this blog. Whether you have the answer or not, using this technique will almost always leave the employee with the impression that you did. Tricky, eh? Socrates would be proud of you.



In chemistry, a catalyst is something that accelerates a chemical reaction, but which itself is not consumed in the reaction. One of the ways in which catalysts (e.g., enzymes) work is to bring reactants into close proximity: instead of bouncing around randomly in a solution, the reactants are much more likely to favorably interact with one another when the catalyst helps bring them together.


This is a role you’ll often need to play as a leader, and there are a number of ways you can go about it.


One of the most common things a team leader does is to build consensus. This may mean you drive the process from start to finish, or you just give it a gentle push in the right direction to speed it up.


Working to build team consensus is a leadership skill that is often used by unofficial leaders because it’s one way you can lead without any actual authority.


If you have the authority, you can direct and dictate direction, but that’s less effective overall than building consensus. If your team is looking to move quickly, sometimes they’ll voluntarily con-cede authority and direction to one or more team leads. While this might look like a dictatorship or oligarchy, when it’s done voluntarily it’s a form of consensus.


Know Where to Put the Chalk Mark

There’s a story about a Master of all things mechanical who had long since retired. His former company was having a problem that no one could fix, so they called in the Master to see if he could help find the problem.


The Master examined the machine, listened to it, and eventually pulled out a worn piece of chalk and made a small X on the side of the machine.


He informed the technician that there was a loose wire that needed repair at that very spot. The technician opened the machine and tightened the loose wire, thus fixing the problem.


When the Master’s invoice arrived for $10,000, the irate CEO wrote back demanding a breakdown for this ridiculously high charge for a simple chalk mark! The Master responded with another invoice, showing a $1 cost for the chalk to make the mark, and $9,999 for knowing where to put it.


To us, this is a story about wisdom: that a single, carefully considered adjustment can have gigantic effects. Ben tries to use this technique when managing people. He imagines his team as flying around in a great blimp, headed slowly and surely in a certain direction.


Instead of micromanaging and trying to make continuous course corrections, he spends most of his week carefully watching and listening. At the end of the week, he makes a small chalk mark in a precise location on the blimp, then gives a small but critical “tap” to adjust the course.


Sometimes your team already has a consensus about what you need to do, but they hit a roadblock and get stuck. This could be a technical or organizational roadblock, but jumping in to help the team get moving again is a common leadership technique.


There are some roadblocks that, while virtually impossible for your team members to get past, will be easy for you to handle, and helping your team to understand that you’re glad (and able) to help out with these roadblocks is valuable.


One time Steve’s team spent several weeks trying to work past an obstacle with his company’s legal department. When they finally reached their wits’ end and came to Steve with the problem, he had it solved in less than two hours because he knew the right person to contact. Another time Ben’s team needed some server resources and just couldn’t get them allocated.


Fortunately, Ben was in communication with other teams across the company and managed to get the team exactly what they needed that very afternoon.


Yet another time one of the engineers on Steve’s team was having trouble with an arcane bit of Java code, and while Steve wasn’t a Java expert, he was able to connect the engineer to another engineer who knew exactly what the problem was.


You don’t have to know all the answers to help remove roadblocks, but it usually helps to know the people who do. In many cases, knowing the right person is more valuable than knowing the right answer.



Another way to catalyze your team is to make them feel safe and secure so that they can take greater risks. The risk is a fascinating thing—most humans are terrible at evaluating risk, and most companies try to avoid risk at all costs.


As a result of this, the usual modus operandi is to work conservatively and focus on smaller successes even when taking a bigger risk might mean exponentially greater success.


A common saying at Google is that if you try to achieve an impossible goal, there’s a good chance you’ll fail, but if you fail to try to achieve the impossible, you’ll most likely accomplish way more than you would have accomplished had you merely attempted something you knew you could complete.


A good way to build a culture where risk-taking is accepted is to let your team know it’s OK to fail.


So let’s get that out of the way: it’s OK to fail. In fact, we like to think of failure as a way of learning a lot really quickly (providing that you’re not repeatedly failing at the same thing).


In addition, it’s important to see failure as an opportunity to learn and not to point fingers or assign blame. Failing fast is good because there’s not a lot at stake.


Failing slowly can also teach a valuable lesson, but it is more painful because more is at risk and more can be lost (usually engineering time).


Failing in a manner that affects your customers is probably the least desirable failure that we encounter, and one where we have the greatest amount of structure in place to learn from failures. As mentioned earlier, every time there is a production failure at Google, they perform a postmortem.


This procedure is a way to document the events that led to the actual failure and to develop a series of steps that will prevent it from happening in the future.


This is not an opportunity to point fingers, nor is it intended to introduce unnecessary bureaucratic checks; the goal is rather to focus strongly on the core of the problem and fix it once and for all. It’s very difficult but quite effective (and cathartic!).


Individual successes and failures are a bit different. It’s one thing to laud individual successes, but looking to assign individual blame in the case of failure is a great way to divide a team and discourage risk-taking across the board.


It’s OK to fail, but fail as a team and learn from your failures. If an individual succeeds, praise him in front of the team.


If an individual fails, give constructive criticism in private. Whatever the case, take advantage of the opportunity and apply a liberal helping of HRT to help your team to learn from their failures.



One of the hardest things to do as a team leader is to watch a more junior-level team member spend three hours working on something you know you can knock out in 20 minutes.


Teaching people and giving them a chance to learn on their own can be incredibly difficult at first, but it’s a vital component of effective leadership.


This is especially important for new hires who, in addition to learning your team’s technology and code base, are learning your team’s culture and the appropriate level of responsibility to assume.


Much like the role of manager, most people don’t apply for the role of men-tor—they usually become one when a team lead is looking for someone to mentor a new team member.


It doesn’t take a lot of formal education or preparation to be a mentor; in fact, you primarily need three things: experience with your team’s processes and systems, the ability to explain things to someone else, and the ability to gauge how much help your mentee needs.


The last thing is probably the most important—giving your mentee enough information is what you’re supposed to be doing, but if you overexplain things or ramble on endlessly, your mentee will probably tune you out rather than politely tell you she got it.



This is one of those patterns that, as obvious as it sounds, is solidly ignored by an enormous number of leaders. If you’re going to get your team moving rapidly in one direction, you need to make sure they all understand and agree on what the direction is. Imagine your product is a big truck (and not a series of tubes).


Each team member has in his hand a rope tied to the front of the truck, and as he works on the product, he’ll pull the truck in his own direction.


If your intention is to pull the truck (or product) northbound as quickly as possible, you can’t have team members pulling every which way—you want them all pulling the truck north.


The easiest way to set a clear goal and get your team pulling the product in the same direction is to create a concise mission statement for the team .


Once you’ve helped the team define their direction and goals, you can step back and give them more autonomy, periodically checking in to make sure they’re still on the right track.


This not only frees up your time to handle other leadership tasks but it also drastically increases the efficiency of your team.


Teams can (and do) succeed without clear goals, but they typically waste a great deal of energy as each team member pulls the product in a slightly different direction. This frustrates you, slows progress for the team, and forces you to use more and more of your own energy to correct the course.



This doesn’t mean we’re assuming you are lying to your team, but it merits a mention because you’ll inevitably find yourself in a position where you can’t tell your team something or, even worse, you have to tell them something they don’t want to hear.


A former manager of Steve’s would tell new team members, “I won’t lie to you, but I will tell you when I can’t tell you something or if I just don’t know.”


If a team member approaches you about something you can’t share with her, it’s OK to just tell her you to know the answer but can’t tell her. Even more common is when a team member asks you something you don’t know the answer to you can tell her you don’t know.


This is another one of those things that seem blindingly obvious when you read it, but many people move to a manager role and feel that if they don’t know the answer to something it proves they’re weak or out of touch. In reality, the only thing it proves is that they’re human.


Giving hard feedback is…well, hard. The first time you have to tell one of your reports that he made a mistake or didn’t do his job as well as was expected of him can be incredibly stressful.


Most management texts advise that you use the “compliment sandwich” to soften the blow when delivering hard feedback. A compliment sandwich looks something like this:


“You’re a solid member of the team and one of our smartest engineers. That being said, your code is incredibly convoluted and almost impossible for anyone else on the team to understand. But you’ve got great potential and a wicked cool neckbeard.”


Sure, this softens the blow, but with this sort of beating around the bush, most people will walk out of this meeting only thinking, “Sweet! I’ve got a wicked cool beard!”


We strongly advise against using the compliment sandwich, not because we think you should be unnecessarily cruel or harsh, but because most people won’t hear the critical message, which is that something needs to change.


It’s possible to employ HRT here: be kind and empathetic when delivering constructive criticism without resorting to the compliment sandwich. In fact, kindness and empathy are critical if you want the recipient to hear the criticism and not immediately go on the defensive.


Years ago, Steve picked up a team member, Tim, from another manager who insisted that Tim was impossible to work with. He told Steve that Tim never responded to feedback or criticism and instead just kept doing the same things he’d been told he shouldn’t do.


Steve sat in on a few of the manager’s meetings with Tim to watch the interaction between the manager and Tim, and he noticed that the manager made extensive use of the compliment sandwich so as not to hurt Tim’s feelings.


When Steve took Tim on his team, he sat down with him and very clearly explained that Tim needed to make some changes to work more effectively with the team.


Steve didn’t give Tim any compliments or candy-coat the issue, but just as importantly, Steve wasn’t mean—he just laid out the facts as he saw them based on Tim’s performance with the previous team.


Lo and behold, within a matter of weeks (and after a few more “refresher” meetings), Tim’s performance improved dramatically. Tim just needed very clear feedback and direction.


When you’re providing direct feedback or criticism, your delivery is key to making sure your message is heard and not deflected. If you put the recipient on the defensive, he’s not going to be thinking of how he can change, but rather how he can argue with you to show you you’re wrong. Ben once managed an engineer we’ll call Dean.


Dean had extremely strong opinions and would argue with the rest of the team about anything. It could be something as big as the team’s mission or as small as the placement of a widget on a web page; Dean would argue with the same conviction and vehemence either way, and he refused to let anything slide.


After months of this behavior, Ben met with Dean to explain to him that he was being too combative. Now, if Ben had just said, “Dean, stop being such a jerk,” you can be pretty sure Dean would have disregarded it entirely.


Ben thought hard about how he could get Dean to understand how his actions were adversely affecting the team, and he came up with the following metaphor:


Every time a decision is made, it’s like a train coming through town—when you jump in front of the train to stop it you slow the train down and potentially annoy the engineer driving the train.


A new train comes by every 15 minutes, and if you jump in front of every train, not only do you spend a lot of your time stopping trains, but eventually one of the engineers driving the train is going to get mad enough to run right over you.


So, while it’s OK to jump in front of some trains, pick and choose the ones you want to stop to make sure you’re only stopping the trains that really matter.


This anecdote not only injected a bit of humor into the situation but also made it easier for Ben and Dean to discuss the effect that Dean’s “train stopping” was having on the team in addition to the energy Dean was spending on it.



As a leader, one way you can make your team more productive (and less likely to leave) in the long term is to take some time to gauge their happiness.


The best leaders we’ve worked with have all been amateur psychologists, looking in on their team members’ welfare from time to time, making sure they get recognition for what they do and trying to make certain they are happy with their work.


One leader we know makes a spreadsheet of all the grungy, thankless tasks that need to be done and makes certain these tasks are evenly spread across the team.


Another leader watches the hours his team is working and uses comp time and fun team outings to avoid burnout and exhaustion. Yet another leader starts one-on-one sessions with his team members by dealing with their technical issues as a way to break the ice and then takes some time to make sure each engineer has everything he needs to get his work done.


After they’ve warmed up, he talks to the engineer for a bit about how he’s enjoying the work he’s doing and what he’s looking forward to next.


One of the most valuable tools in tracking your team’s happiness is, at the end of each one-on-one meeting, to ask the team member, “What do you need?” This simple question is a great way to wrap up and make sure each team member has what he needs to be productive and happy, although you may need to carefully probe a bit to get details.


If you ask this every time you have a one-on-one, you’ll find that eventually, your team will remember this and sometimes even come to you with a laundry list of things they need to make their job better.


The Unexpected Question

Shortly after Steve started at Google he had his first meeting with then-CEO Eric Schmidt, and at the end, Eric asked Steve, “Is there anything you need?” Steve, who had prepared a million defensive responses to hard questions or challenges, was completely unprepared for this.


So he sat there dumbstruck and staring. But you can be sure Steve had something ready the next time he was asked that question!


It can also be worthwhile to pay some attention to your team’s happiness outside the office. Be wary of assuming that people have no life outside of work— having unrealistic expectations about the amount of time people can put into their work will cause people to lose respect for you, or worse, to burn out.


We’re not advocating that you pry into your team members’ personal lives, but being sensitive to personal situations that your team members are going through can give you a lot of insight into why they may be more or less productive at any given time.


Giving a little extra slack to a team member who is having a tough time at home now can make him a lot more willing to put in longer hours when your team has a tight deadline to hit later.


A big part of tracking your team members’ happiness is tracking their careers. If you ask a team member where she sees her career in five years, most of the time you’ll get a shrug and a blank look.


When put on the spot, most people won’t say much about this, but there are usually a few things that everyone would like to do in the next five years: get promoted, learn something new, launch something important, and work with smart people. Regardless of whether they verbalize this, most people are thinking about it.


If you’re going to be an effective leader, you should be thinking about how you can help make all those things happen and let your team know you’re thinking about this.


The most important part of this is to take these implicit goals and make them explicit so that when you’re giving career advice you have a real set of metrics on which to evaluate situations and opportunities.


Tracking happiness comes down to not just monitoring careers, but also giving your team members opportunities to improve themselves, get recognized for the work they do, and have a little fun along the way.



Delegate, but get your hands dirty. When moving from an individual contributor role to a leadership role, achieving a balance is one of the hardest things to do: initially, you’re inclined to do all of the work yourself, and after being in a leadership role for a long time, it’s easy to get into the habit of doing none of the work yourself.


If you’re new to a leadership role, you probably need to work hard to delegate work to other engineers on your team, even if it will take them a lot longer than you to accomplish that work. Not only is this one way for you to maintain your sanity, but also it’s how the rest of your team will learn.


If you’ve been leading teams for a while or if you pick up a new team, one of the easiest ways to gain the team’s respect and get up to speed on what they’re doing is to get your hands dirty—usually, by taking on a grungy task no one else wants to do.


You can have a résumé and a list of achievements a mile long, but nothing lets a team know how skillful and dedicated (and humble) you are like jumping in and actually doing some hard work.


Seek to replace yourself. Unless you want to keep doing the exact same job for the rest of your career, seek to replace yourself. This starts, as we mentioned earlier, with the hiring process: if you want a member of your team to replace you, you need to hire people capable of replacing you, which we usually sum up by saying you need to “hire people smarter than you.”


Once you have team members capable of doing your job, you need to give them opportunities to take on more responsibilities or occasionally lead the team.


If you do this, you’ll quickly see who has the most aptitude to lead as well as who wants to lead the team. Remember that some people prefer to just be high-performing individual contributors, and that’s OK.


We’ve always been amazed at companies that take their best engineers and—against their wishes—throw these engineers into management roles. This usually subtracts a great engineer from your team and adds a subpar manager.


Know when to make waves. You will (inevitably and frequently) have difficult situations crop up where every cell in your body is screaming at you to do nothing about it.


It may be the engineer on your team whose technical chops aren’t up to par. It may be the person who jumps in front of every train. It may be the unmotivated employee who is working 30 hours a week. “Just wait a bit and it will get better,” you’ll tell yourself. “It will work itself out,” you’ll rationalize.


Don’t fall into this trap—these are the situations where you need to make the biggest waves and you need to make them now. Rarely will these problems work themselves out, and the longer you wait to address them, the more they’ll adversely affect the rest of the team and the more they’ll keep you up at night thinking about them.


By waiting, you’re only delaying the inevitable and causing untold damage in the process. So act, and act quickly.


Shield your team from chaos. When you step into a leadership role, the first thing you’ll usually discover is that outside your team is a world of chaos and uncertainty (or even insanity) that you never saw when you were an individual contributor.


When Steve first became a manager back in the 1990s (before going back to being an individual contributor) he was taken aback by the sheer volume of uncertainty and organizational chaos that was happening in his company.


He asked another manager what had caused this sudden rockiness in the otherwise calm company, and the other manager laughed hysterically at Steve’s naïveté: the chaos had always been present, but Steve’s previous manager had shielded Steve and the rest of the team from it.


Give your team air cover. While it’s important that you keep your team informed about what’s going on “above” them in the company, it’s just as important that you defend them from a lot of the uncertainty and frivolous demands that may be imposed upon you from outside your team.


Share as much information as you can with your team, but don’t distract them with the organizational craziness that is extremely unlikely to ever actually affect them.


Let your team know when they’re doing well. Many new team leads can get so caught up in dealing with the shortcomings of their team members that they neglect to provide positive feedback often enough.


Just as you let someone know when he screws up, be sure to let him know when he does well, and be sure to let him (and the rest of the team) know when he knocks one out of the park.


Lastly, here’s something the best leaders know and use often when they have adventurous team members who want to try new things often: it’s easy to say “yes” if it’s easy to undo something.


If you have a team member who wants to take a day or two to try using a new tool or library that could speed up your prod-uct (and you’re not on a tight deadline), it’s easy to say, “Sure, give it a shot.”


If, on the other hand, she wants to do something like launch a product that you’re going to have to support for the next 10 years, you’ll likely want to give it a bit more thought. Really good leaders have a good sense for when something can be undone.


Imposter Phenomenon

Much has been written about the so-called “imposter syndrome” or “imposter phenomenon,” which according to Wikipedia is a “psychological phenomenon in which people are unable to internalize their accomplishments.


Despite external evidence of their competence, those with the syndrome remain convinced that they are frauds and do not deserve the success they have achieved.”


We prefer the “phenomenon” nomenclature because, even though this may make you feel like a fraud who will be discovered at any time, the imposter phenomenon often drives you to work much harder and achieve goals that you might never have achieved otherwise.


This problem is extremely common in people new to management, especially those thrust into leadership positions (official or not) by necessity. The phenomenon is so widespread that we almost always get asked about it after our talks. “I don’t actually know what I’m doing,” people will say, “so what can I do to stop feeling like a phony?”


Our answer is that everyone feels like a phony at some point in their career; one could even argue that a little bit of insecurity makes us work harder and helps improve our success.


Ben likes to share the story of his parents’ marriage. The night before they got married, they both got cold feet and admitted to each other that they had made a Terrible Mistake—but that it was clearly far too late to call off the wedding.


So they made a pact to “fake it” for the wedding, play the stage role of happy newlyweds, and then maybe call things off a few days later.


A couple of weeks later, they decided to try another month of marriage. And then the month after that, and the month after that. Eventually, it became a running joke in their marriage. Every year on their anniversary they would say, “Let’s give this trial another year, eh?”


Whatever sort of leadership you’re involved in, the same “fake it till you make it” technique tends to work very well. When Ben first got asked to manage a large team, a similar script went through his mind: “You want me to own this project?


That’s crazy, but OK, I guess I’ll pretend to be a leader for a while.” Then every year at performance-review time, he’d look back at his success and say, “Yeah, I guess I’ll keep pretending a bit longer—seems to be going well!”


People Are Like Plants

Steve’s wife is the youngest of six children, and her mother was faced with the difficult task of figuring out how to raise six very different children, each of whom needed different things.


Steve asked his mother-in-law how she managed this (see what we did there?), and she responded that kids are like plants: some are like cactuses and need little water but lots of sunshine, others are like African violets and need diffuse light and moist soil, and still others are like tomatoes and will truly excel if you give them a little fertilizer.


If you have six kids and give each one the same amount of water, light, and fertilizer, they’ll all get equal treatment, but the odds are good that none of them will get what they actually need. 


And so your team members are also like plants: some need more light, and some need more water (and some need more bullshit, er, fertilizer). It’s your job as their leader to figure out who needs what and to then give it to them.


Take a look at this matrix:

To get all of your team members into the sweet spot, you need to motivate the ones who fall into the “In a rut” portion of the matrix, and provide stronger direction to those who are in the “Look! Squirrel!” portion. Of course, those who are “adrift” need both motivation and direction.


So, instead of water and sunlight, you need to provide team members with a combination of motivation and direction to make them happy and productive. And you don’t want to give them too much of either—because if they don’t need motivation or direction and you try giving it to them, you’re just going to annoy them.


Giving direction is fairly straightforward—it requires a basic understanding of what needs to be done, some simple organizational skills, and enough coordination to break it down into manageable tasks.


With those tools in hand, you can provide enough guidance for an engineer in need of directional help. Motivation, however, is a bit more sophisticated and merits some explanation.


Intrinsic Versus Extrinsic Motivation

There are two types of motivation: extrinsic, which originates from outside forces (such as monetary compensation), and intrinsic, which comes from within.


In his blog Drive, Dan Pink explains that the way to make people the happiest and most productive isn’t to motivate them extrinsically (e.g., throw piles of cash at them), but rather to work to increase their intrinsic motivation. Dan claims you can increase intrinsic motivation by giving people three things: autonomy, mastery, and purpose.


A person has autonomy when she has the ability to act on her own without someone micromanaging her. With autonomous employees, you might give them the general direction in which they need to take the product, but leave it up to them to decide how to get there.


This helps with the motivation not only because they have a closer relationship with the product (and likely know better than you how to build it), but also because it gives them a much greater sense of ownership of the product.


The bigger their stake is in the success of the product, the greater their interest is in seeing it succeed.


Mastery in its basest form simply means you need to give someone the opportunity to learn new skills and improve existing skills. Giving ample opportunities for mastery not only helps to motivate people but also makes them better over time, which makes for stronger teams.


An employee’s skills are like the blade of a knife: you may spend tens of thousands of dollars to find people with the sharpest skills for your team, but if you “use” that knife for years without sharpening it, you will wind up with a dull knife that is inefficient, and in some cases useless.


Ample opportunities for team members to learn new things and master their craft will keep them sharp, efficient, and effective.


Of course, all the autonomy and mastery in the world isn’t going to help motivate someone if she’s doing work for no reason at all, which is why you need to give her work purpose.


Many people work on products that have great significance, but they are kept at arm’s length from the positive effects their products may have on their company, their customers, or even the world.


Even in cases where the product may have a much smaller impact, you can motivate your team by seeking the reason for their efforts and making this reason clear to them. If you can help them to see this purpose in their work, you’ll see a tremendous increase in their motivation and productivity.


One manager we know keeps a close eye on the email feedback the company gets for its product (one of the “smaller-impact” products), and whenever she sees a message from a customer talking about how the company’s product has helped the customer personally or helped the customer’s business, she immediately forwards it to the engineering team.


This not only motivates the team but also frequently inspires them to think about ways they can make their product even better.


Final Thoughts

Regardless of whether you ever intend to lead a team, we hope this blog has helped you understand what it takes to be a good team leader and dispelled some of the myths about what a leader does for a team.


Even if you’re resolute in your commitment to never be a leader, it’s good to be familiar with the concepts laid out in this blog because they can help you understand why the leader of your team does what she does, regardless of whether she’s good at her job or terrible at it.


Take a moment to look at your team and see which of these patterns and antipatterns your team leader applies to make your team succeed (or fail), and you’ll have a more concrete understanding of what makes your team tick. 


But understanding the team and leader you work with every day is only one aspect of working with other people—crossing paths with someone outside your team can be even more challenging, especially if this person is out to sabotage your team.