Debugging Teams

Before we start, we need to set your expectations. Motivated programmers love to read books that lay out domain-specific problems in a perfect mathematical presentation; each problem is typically paired with a prescribed procedural solution.

This is not such a book.

We should also make a couple more disclaimers. As we like to joke in our talks, "These opinions are purely our own and are based on our experiences. If you disagree, you’re welcome to get your own talk." Just as with our oral presentations, we encourage any and all discussion that arises from the topics in this book. We’re happy to chat about feedback, corrections, new opinions, and disagreements: you can find us at http://www.debuggingteams.com/. Everything in this book comes from our own trials by fire and the lessons that came out of our numerous mistakes.

You should also know that every name used in our examples has been changed to protect the innocent (or guilty).

Most of the software engineers we know have spent anywhere from 4 to 10 years in school learning about computer science and software engineering. And yet there are hardly any curricula ^[1] that actually teach you how to communicate and collaborate in a team or a company. Sure, most students are required to participate in a group project at some point in their academic career, but there’s a big difference between teaching someone how to successfully work with another person and throwing him into a situation of forced collaboration. Most students end up jaded by the experience.

When you hear someone say "mission statement," the odds are good that the first thing that springs to mind are 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:

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

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^[15] 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.^[16] 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"^[17] explaining the statement phrase by phrase. They even included a section that described what the project’s nongoals were. Here’s the mission statement:

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

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.

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."^[18] 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"^[19] 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.

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 as 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 bandying 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 repost 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.

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

No matter how much you 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 to 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.

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."^[20]

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.^[21]

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.

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 that we reviewed in Communication Patterns of Successful Cultures.

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 nonexistent comments can cause future maintainers or API consumers to waste time sleuthing. Comments are often used to point out missing structure and bad naming, and then go on to reexplain 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.^[22] 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:^[23]

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 book 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 is, in our opinion, more trouble than it’s worth. We’ve all seen these attributions at the top of source files, nestled snugly against the copyright declarations:

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.^[24]

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. For more information, see the section on feedback loops in Hiding Is Considered Harmful.

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.

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,^[29] 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 chapter, make it this:

Fitz had a new engineer join his team a few years ago. Jerry’s last manager (at a different company) was adamant that Jerry be 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 Fitz, Jerry came to Fitz 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. Fitz 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 Fitz for a few seconds, nodded, and went on his way. Fitz treated Jerry like an adult, Jerry always got his work done, and Fitz 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).^[30] 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,^[31] 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.

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 pushovers, 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 Fitz’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, Fitz’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 hope 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 impact 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, 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 Fitz’s—we’ll call him Jake—had his first child. Jake and Fitz 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 Fitz 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 Fitz, despite the fact that Jake was just as productive as always and that Fitz 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 showed 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 lead 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 lead. 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 to 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 advertising, 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).

Fitz runs a conference in Chicago that used to be at a site rented from a local institution. The first time Fitz went to get access to the venue for the conference, the facilities manager gave Fitz 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 Fitz 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 Fitz 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, notebooks, 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.

We talked about "losing the ego" in The Myth of the Genius Programmer when we first examined HRT, but it’s especially important when you’re playing the role of 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 like 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.

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

Sometimes your team already has 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 Fitz’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 Fitz 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 Fitz’s team was having trouble with an arcane bit of Java code, and while Fitz 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. 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 trying 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.^[35] 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.^[36] 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 mentor—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 (see the section The Mission Statement—No, Really in Building an Awesome Team Culture for more information about mission statements). 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 Fitz’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 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 seems 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, Fitz picked up a team member, Tim, from another manager who insisted that Tim was impossible to work with. He told Fitz that Tim never responded to feedback or criticism and instead just kept doing the same things he’d been told he shouldn’t do. Fitz 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 Fitz 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. Fitz didn’t give Tim any compliments or candy-coat the issue, but just as importantly, Fitz 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:

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.

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 Fitz 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 Fitz’s naïveté: the chaos had always been present, but Fitz’s previous manager had shielded Fitz 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 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 product (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.

There are certain people out there who simply are unable to figure out what’s going on in a project. Their damage is most often in the form of wasting the team’s time. Rather than spending a few minutes of their own time reading fundamental project documentation, mission statements, FAQs, or the latest email discussion threads, they repeatedly distract the entire team with questions about things they could easily figure out on their own.

In the Subversion project, we once had a participant who decided to use the main developer discussion forum as a sounding board for his daily stream of consciousness. Charlie made no actual code contribution. Instead, every two or three hours, he’d send out his latest daydreams and brainstorms. There would inevitably be multiple responses explaining why his ideas were incorrect, impossible, already in progress, previously discussed, and/or already documented. To make things worse, Charlie even started answering questions from drive-by users, and answering them incorrectly. Core contributors had to repeatedly correct his replies. It took us quite a while to realize that this affable, enthusiastic participant was in fact poisonous and draining our collective energy. Later in this chapter we’ll talk about how we dealt with the situation.

Perhaps ego isn’t the perfect word here, but we’re using the term to describe anyone who is incapable of accepting a consensus decision, listening to or respecting other points of view, or reaching compromises. This person will typically reopen discussions that have been long settled (and documented in email archives) because she wasn’t around to participate in the decision. The person won’t read or think about the history at all, demanding that the debate be replayed just for her sake. She will often make sweeping claims about the project’s success, claiming that doom is imminent unless she gets her way.

The Subversion project had a notable episode in which an intelligent programmer showed up on the email list one day and declared that the entire product was ill-designed. He had seen the light, had radical ideas about how things should work, and insisted that the entire project start over from scratch. He even helpfully volunteered to lead the reboot himself. Without his leadership, he proclaimed that complete failure was looming just around the corner.

An entire week was wasted while the project founders endlessly argued with this person and defended their original design decisions. A huge amount of attention and focus was lost. It became clear that this person wasn’t willing to compromise or integrate any of his ideas into the current product, and the product (which was already in beta and being used in the wild) wasn’t about to start over. At some point we simply had to walk away from the debate and get back on track. Ironically, years later, this person’s predictions turned out to be correct on many levels, but that didn’t stop Subversion from becoming wildly successful anyway—at least in corporate software development. The point here isn’t about who is right or wrong, but whether a disagreement is guaranteed to come to a conclusion and whether it’s worthwhile to keep a debate going. Never stop asking yourself those sorts of questions; at some point you need to decide when it’s time to cut your losses and move on.

Anytime you have a visitor who demands that something be done, your alarm should go off. Something is wrong with a person who puts all her energy into complaining about the inadequacies of the software but is unwilling to directly contribute in any way.

This sense of entitlement sometimes bleeds into troll-like behavior. While running Google’s Project Hosting service, we once had a project owner ask us to ban a user for obscene behavior. The open source project, a video game emulator, didn’t work properly for his favorite video game. The user started by filing a rather rude bug in the issue tracker. The project developers politely explained why the game didn’t work yet, and why it was unlikely to be fixed for a good while. This answer was unacceptable to the user, who began to harass the developers daily. He would open bug after bug with the same complaint. He started adding comments to other bugs saying what "idiots" the developers were for refusing to fix his problem. His language became increasingly obscene over time, despite repeated warnings from the developers and Google administrators. Regardless of all our efforts to eliminate his destructive behavior, he steadfastly refused to change, so we were eventually forced—as a last resort—to ban him entirely.

The person doesn’t use her real name. Instead, you’ll see only childish nicknames like "SuperCamel," "jubjub89," or "SirHacksalot." To make things worse, often the person will have different nicknames in different media—one name for email, a different one for instant messaging, and perhaps a different one for code submissions. In extreme cases, you’ll see these people communicating in lol-speak, 1337speak, ALL CAPS, or with excessive punctuation!??!1!!1!!

As seen in the earlier example, sometimes an inappropriate sense of entitlement leads directly into open hostility toward a project. Many times we see it escalate into complete paranoia. When an existing team disagrees with the visitor, the poisonous person will sometimes start to throw accusations of a "cabal" and conspiracy. It’s amusing to imagine that the project team finds him so important that they’d go through the effort of conspiring against the visitor. And if you already have an open and transparent culture of communication (as we pushed for in Building an Awesome Team Culture), this makes the accusation all the more hilarious, since every conversation is already a public record. The recommendation here is to not even bother responding to such charges. By the time the poisonous person goes this far over the edge, anything you say will only dig yourself a deeper hole in his mind, so why bother saying anything at all? It’s time to get back to the important work of making things.

On the surface, perfectionists don’t seem dangerous at all. Sure, there may be a touch of odd obsessive-compulsive behavior now and then, but usually the person is humble, polite, respectful, and a good listener. He seems stuffed full of happy HRT and good intentions. What’s the problem, then? The problem is the threat of paralysis.

Let’s look at a person we’ve worked with in the past. Patrick was a brilliant engineer. He had great design chops, wrote high-quality code and tests, and was easy to get along with. Unfortunately, when it came time to design new software, he could spend the rest of his life tweaking and improving his design. He was never satisfied with the plans and seemingly was never ready to start coding. While he certainly had good points and excellent insights into the problems we were trying to solve, the rest of the team ended up becoming immensely frustrated; it became clear that we were never actually going to write any code. Several of us on the project deliberated quite a bit on what to do about this. On the one hand, Patrick was a huge help to our team. On the other hand, he was preventing us from making forward progress as a group. Every time we’d begin to code he’d politely veto and point out potential theoretical problems that could matter in the distant future. He was paralyzing us without realizing it. We’ll talk about how we resolved this in the next section.

Once a good-enough solution is found for the original problem, point the perfectionist to a different problem that still needs attention.

In the case of Subversion’s perfectionist, this strategy worked well. Eventually, we reached a point where we took Patrick aside and said, "OK, we’re just going to start working from this design as it stands now, and see what happens. Hopefully you’ll be able to help us navigate around any problems that crop up down the road." To our surprise, Patrick was OK with this and instead moved on to a different subject as the object of his obsession. No feelings were hurt either way, and Patrick kept contributing to the overall effort.

There’s an old saying to not let "the perfect be the enemy of the good," and in your quest to create a high-performing team, you need to be just as vigilant about avoiding perfectionism as you are about calling out more obvious disruptive behaviors.

This trick of redirecting energy also works on the overly entitled people who spend more time complaining and criticizing than helping out. It’s tempting to respond to such a person with a standard "patches welcome" remark—the open source community’s euphemistic version of telling someone to put up or shut up. Instead, try getting him to take an interest in formally testing the software and pointing out regressions. It allows him to keep complaining, but in a useful way.

This is an old adage from Usenet.^[44] In particular, this works best against deliberate trolls—people who are purposely trying to get a rise out of you or your team. The more you respond, the more the troll feeds off your energy, and the more time you’ve wasted. The simple silent treatment often works best. Regardless of how much you’re dying to deliver that one-line zinger that’ll put him in his place, resist the urge. When the person realizes nobody’s paying attention, he typically loses interest and just leaves. Note that it often takes quite a bit of willpower to not respond. Stay strong!

Even if the person isn’t deliberately trolling, it’s all too easy to get defensive. When somebody accuses you of making a bad design decision or of conspiracy, or simply wastes your time by asking too many questions whose answers are obvious, it’s easy to get upset. Remember that your job is to build great things, not to appease every visitor or repeatedly justify your existence. The stronger your emotions are, the more likely you are to waste hours or days writing passionate replies to someone who doesn’t deserve such attention. Choose your battles carefully and keep calm. Carefully decide who’s worth replying to, and who you’ll let be.

Continuing on with the theme of staying clear of too much emotion, a corollary is to actively look for facts. If someone is complaining, listen carefully. Always start by giving the person the benefit of the doubt, despite the angry or rude language. Does the person have a real point? Is there something to learn from the person’s experience, or is there an idea worth responding to? Very often the answer is "yes"—that despite a poisonous person’s vitriolic prose, some wisdom really is buried in there. Always bring the argument back to a technical discussion.^[45]

Our favorite example of this is the day we got a rancorous email from a well-known leader of the open source community. It was a bug report of sorts, but on the surface it was more like a rant about the team’s overall intelligence. The post was chock-full of slander and hyperbole, and seemed intended to inflame the team rather than to get the bug fixed. One of our team members, however, responded to the report with just a few specific questions, focusing only on the bug. The bug reporter replied with more clarification, but still it was wrapped in over-the-top venom. Our team member continued to completely ignore the insults, investigated the issue, and replied with a simple "Thanks for the bug report, I see how to fix the problem—we’ll release a patch soon."

We were immensely proud of the way our team member handled the situation. Remaining utterly calm and fact-driven only made the original poster seem like more of a lunatic as the conversation progressed. By the end of the exchange, the bug reporter had lost all credibility with his audience and no longer had any interest in hanging around.

To take the preceding approach (of remaining cool-headed and factual) even further, sometimes it’s possible to scare people away just by being too kind! Here’s an actual chat transcript from the Subversion IRC channel:

Sometimes no matter how hard you try, you simply need to flip the bozo bit and move on. Even if you’ve already spent a lot of attention and focus trying to correct bad behaviors, you need to know how to recognize a lost cause.

Let’s return to our story about Charlie, the friendly philosopher who was posting far too often to the Subversion email list. Eventually we did an analysis of the email discussions and discovered that this participant had grown into the third most frequent poster over the course of two months; the first and second most frequent posters were core project contributors, and 70% of their posts were spent replying to Charlie! Clearly our energy and focus were being sucked away, despite no ill will from Charlie himself. Our final solution was to privately email him and (politely) ask him to stop posting so often. It was a difficult conversation to have, mainly because he was unable to see the amount of disruption he was causing. After a few more weeks without a significant behavioral change, one of us actually had a long (and even more difficult) discussion with him over the phone where we asked him to stop posting altogether. He ultimately withdrew as requested, a bit sad and confused, but respectful of the team’s wishes. Everyone felt a little guilty about it because he never quite understood the harm he was causing, but everyone also felt it was the right thing to do. It was a delicate situation to resolve, but we used a great deal of HRT to keep things civil and appropriate.

The path to a successful project is lined by thousands of distractions. If there’s a common theme in dealing with the distraction of poisonous people, it’s that it’s all too easy to get caught up in the immediate drama of a situation. If you’re witnessing what you think may be poisonous behavior, you need to ask yourself two critical questions:

If your answer to either of these questions is "no," you need to intervene to stop the behavior as soon as possible. It’s easy to persuade ourselves that the short-term gain of tolerating poison is worth it, but it usually isn’t: for example, somebody may be a great technical contributor but still exhibit poisonous behavior. There’s a temptation to turn a blind eye to the behavior in order to benefit from the technical advancement. But be careful! A strong culture based on HRT is irreplaceable, while technical contributions are definitely replaceable. To quote a former teammate of ours:

Of course, Greg isn’t talking about literal "genius" here; he’s pointing out that the world is full of highly competent programmers. If you find one who’s offensive or threatens your culture over the long term, it’s best to wait for another one to come along.

We once encountered this sort of situation in the Subversion project. The team has a strict policy of not putting names into source code files (the very policy we discussed in Building an Awesome Team Culture!): we feel it creates unmanageable territoriality. People are afraid to change code if it has somebody else’s name on it, and it keeps the bus factor artificially low. Instead, we allow the version control’s history to credit people appropriately, and we keep a single top-level file with all the contributors' names in it.

One day a smart programmer showed up and volunteered to write a sizable new feature that was sorely needed. He submitted the code for review, and our main feedback was simply requesting that he remove his name from the top of the file—that we’d credit him in the same places as everyone else. He refused to do this, however, and the debate led to an impasse. In the end, the decision was made to reject his code and he left, taking his toys with him. Of course everyone was disappointed, but we didn’t want to violate our policy (and dilute our culture) just to get the new feature sooner. A couple of months later, someone else ended up reimplementing the feature anyway.

To be explicit: it’s not worth compromising your culture for the short-term gains—particularly if it’s about a brilliant contributor who doesn’t acknowledge the importance of HRT.

If your manager is a servant leader who employs HRT and is truly interested in helping you succeed (see Every Boat Needs a Captain), there are a few simple things you can do to help make her job easier, and consequently make yourself more productive and a more valuable team member. Perhaps more importantly, they can make your job better and your career more successful.

Pursue extra responsibility as you’re getting your work done. One of our favorite metaphors for this is the forest ranger who sends you, a junior ranger, into the forest to cut down a sick or damaged tree. If you’re focused merely on the task at hand, you’ll go into the forest, cut down the sick tree, and return triumphant. If, however, you’re thinking about the bigger picture, you’ll go into the forest, cut down the sick tree, and return with a map of all the other sick trees you encountered on your journey, along with a plan for efficiently cutting them down if the senior ranger agrees that this is the best plan of action. As a result of this kind of action, the next time the forest ranger has a task that requires that level of responsibility she’ll likely give you the first shot at it. She’ll do this not only because she knows you can do it, but because that’s the path of least resistance—it’s less work for her.

This kind of proactive, responsibility-seeking behavior reduces your manager’s workload because she has one less thing to worry about, and it shows that you’re capable of doing work beyond your current level. This also means you’ll likely have to leave your comfort zone and try new things, and that’s OK if you’re on a team where you’re encouraged to take risks and fail fast.

Take risks and don’t fear failure. We talked a lot in Chapters 3 and 4 about the importance of taking risks and failing fast. In the presence of an enlightened manager, failing is a great way to learn quickly, discover the limits of what you can and can’t do, and grow those limits over time. Our friend Steve Hayman, who travels a lot for work, has often said, "If you don’t miss at least one flight a year, you’re getting to the airport too early." This is a great metaphor for creating any sort of product: if you don’t fail at least once a year, you’re not taking enough risks. And like the pursuit of extra responsibility, taking risks is a way to show you’re capable of bigger things.

If you don’t take risks in your work, you’ll have fewer failures, but you’ll have fewer big successes as well. A good manager wants a team that’s willing to push the envelope to see what they can and can’t do (and to learn a lot in the process), and she’ll provide a soft landing for when you fail. When you fail, take responsibility, don’t seek to assign blame, and document what happened and what you can do to avoid that same failure again. Lather, rinse, repeat.

Act like an adult. Another recommendation in a long line of suggestions that seem glaringly obvious: you are responsible for teaching people how to act and how to treat you. Bad managers will frequently train their teams to act like children by squashing any initiative, responsibility, or rule breaking. If you’ve had one of these managers, you often come to expect this sort of treatment from all managers.

Question things that you’re unsure about. If your manager makes a decision that you disagree with, don’t be afraid to argue with her or question the premise upon which she made the decision. While this isn’t a license to be an obstacle, being a "yes-man" isn’t helpful to someone in a leadership position if you’ve got information or experience that she lacks.

Your manager is not clairvoyant: only rarely will you find a person in an organization who overcommunicates, so don’t hesitate to update your team’s leader on what you’re doing before she asks you what’s going on. Drop her a quick note when you hit an obstacle, score a victory, need something, or expect something. Not only is this a great way to make sure your manager knows what you’re up to, but we’ve seen crafty engineers take this technique to the extreme as a way to deal with micromanagement: if your manager keeps checking in on you, proactively sending her an email at the same frequency with which she checks in on you is a surefire way to get her to back off.

These techniques work well when you’re in the ideal organization, but what about when your organization is anything but ideal?

While we’re big proponents of trusting people, or at the very least giving them the benefit of the doubt, trusting the office politician can be a seriously career-limiting move.

The office politician may be difficult to spot when you first meet him because he tends to be very good at managing relationships and dealing with people—he may be quite friendly at first. He usually does an exceptional job of managing up and an even better job of using his peers and subordinates as a means for self-promotion. He’s quick to blame others, but even quicker to steal credit when given the opportunity. He’s usually not directly confrontational, but instead prefers to tell you what you want to hear so that you’ll think well of him. If he can’t use you or manipulate you, he’ll either ignore you or, if he sees you as a threat, try to undermine you. After you’ve worked with him for a while, it’s easy to spot him: he spends more time looking impactful than actually being impactful.

We advise that you steer clear of the office politician: route around him where possible, but don’t carelessly badmouth him to other people above him in the organization, because it’s quite difficult to know who he has hoodwinked and who is wise to him. If you’re the kind of person who is happy to keep your head down and focus on building interesting technology, you may want to rethink this strategy when there’s an office politician around. If you don’t put energy into getting promoted because you don’t want to "play the game," you may find that the office politician gets promoted over you, in which case you’ve now got a bad manager and an office politician. See Manipulating Your Organization for more on this.

As companies grow, they develop bureaucracy and processes in an effort to manage profit, reduce risk, increase predictability, and support the massive weight of the organization itself. Over time, this bureaucracy can grow to a point where it prevents the company from succeeding. As with bad managers, much has been written about bad organizations, so we’re only going to review a few examples of organizational issues that most often affect individual contributors.

It’s a simple fact that most companies are not engineering-focused. That is to say: engineers are a means to accomplish business goals that are typically not technical. This means the people running the company probably don’t understand the technical underpinnings of their system, just the demands set upon them by the business, and so they wind up creating unrealistic demands on engineering. Even if a technically competent executive finds her way into this sort of company and fights to defend her organization, she’ll frequently find herself replaced by someone who is willing to sacrifice the health and sanity of the employees to meet the needs of the business. Typically you’ll see this directly in the form of unrealistic deadlines and lack of qualified technical people to get projects completed on time. You may have difficulty acquiring enough hardware to effectively run your product, or find your team spending weeks rewriting something when a hardware purchase costing only a few hundred dollars would have done the job. This is unfortunately typical of a company that doesn’t value engineers and treats them like "work units" or "resources," giving them no voice in how the company operates.

The most egregiously bad organizations have ossified command and control structures that resemble fiefdoms. Years ago, our friend Terrence worked at a company that had strict rules on passing bugs between teams, and eventually another team created a bug that caused Terrence’s product to run out of memory over the course of a few hours. Instead of emailing the team members who were responsible for this, or looking at their commit logs or source code, he stayed up all night reproducing the bug, gathering data, and building his case. Terrence sent this email to his manager, who sent the email to his director, who emailed the director of the team that created the bug. This director emailed that team’s manager, who figured out who on his team was responsible for the software in question. More than 10 days later, Terrence found himself in a meeting with two managers, two directors, and three other engineers discussing the bug and whether they could get it fixed in time for their next launch. Sound absurd? Sadly, this sort of thing happens all the time. In contrast, during Fitz’s first week at Google he found a typo in Gmail. He opened the source code, fixed the typo, then emailed a patch to the Gmail team, who thanked him heartily.

Many companies are filled with people who are obsessed with organizational hierarchy.^[49] This results in endless power struggles, with managers often preventing engineers from transferring to another team in order to protect their own team from losing a valuable contributor—even when the right thing to do for both the company and the engineer is to let the transfer happen.

Has your company ever treated you like a naughty child? Are you unable to get to innocuous external websites due to an overzealous company firewall? Do you have to carefully account for every moment of your day with a detailed timecard? Some organizations will even go so far as to measure your productivity by meaningless (and usually wildly inaccurate) methods such as the number of lines of code you write every week.^[50]

Still other organizations will breed employees who judge their success not by the number and quality of products they ship, but by the number of meetings they’re invited to attend.

Lastly, your company might lack important things like focus, vision, or direction. This is often the result of too many masters, or "design by committee," which results in conflicting orders being sent down to the rank and file. So you wind up moving in ever-tighter circles instead of in a coherent direction.

Many bad companies are guilty of these transgressions, and much, much more. Still, these companies are composed of people, and there are a number of tips and tricks you can put to bear to get people to help you out.

First and foremost, know what you can get away with in your organization—while asking for permission does give you an opportunity to push responsibility onto someone else, it also creates an opportunity for someone to tell you "no." It’s important to know what you can get away with in your organization without explicitly getting approval from one of your superiors, but wherever possible, we advise you to do what you think is right for the company.

Even if you’re prepared to beg for forgiveness, choose your battles wisely—every time you have to plead your case for something or go up against someone else in your company, you’re spending your political capital. If you spend all your capital winning a bunch of battles that just don’t matter, you’re going to find that you have nothing left in your account when it comes to the important things. Be strategic and fight for things either that matter or that you’re pretty sure you have some chance of winning. Blowing all your capital on a battle you know you can’t win is pointless, stressful, and career limiting for no good reason. For more details, see Your Political Bank Account.

If you do decide to go the "beg for forgiveness" route, it’s useful to have colleagues and friends in your company that you can use as a sounding board for your ideas—especially your riskier ideas.

These people should have a good sense of what you can and can’t get away with in the company as well as which ideas just won’t fly.

When someone in marketing suggested that Fitz raise awareness of his Data Liberation team among the executives at Google, Fitz bounced an idea off his sounding-board colleagues: give Data Liberation–branded bolt cutters and locked boxes of swag (with the keys locked inside, of course) to the execs. He decided to go ahead with it and it was a big hit. A few years later, when Fitz was contemplating printing up some, shall we say, "off-color" swag, the same sounding board expressed some concern that the plan was too risky and Fitz decided to nix that plan. If you’re going to act without asking permission, it’s good to trust your instincts, but a second opinion from a trusted source is invaluable.

Another strategy for making change in a company is to find ways to get your ideas accepted at a grassroots level. If you can get enough people to buy into your idea or use a particular product, it will often be too late for the bureaucracy to squash you, and management will be forced to notice and either accept it or act against it (which costs them, yep, you guessed it, political capital!). This is a strategy that many engineers used for years, for example, to sneak open source tools into their daily workflow in order to make their lives a lot more pleasant.

Ideas in particular are fascinating things: they can go a long way if you don’t care who gets the credit! Sometimes you’ll find that people will spread an idea only if they can take credit for the idea as their own, so you need to decide what’s more important: that you get the credit, or that the idea spreads. Despite the fact that it may pain you to hear your words coming out of another (perhaps despised) person’s mouth, it’s often the most effortless way for an idea to travel. We’ve seen this happen time and time again in companies large and small: the lofty concepts and ideas coming from an executive’s mouth originate from someone in her organization. Think about the broad audience that your idea—which would otherwise go unheard—can reach in this case!

Just as with individuals, eliminating bad habits in a company is difficult. One of Ben’s early teachers used to have a saying: "It’s impossible to simply stop a bad habit; you need to replace it with a good habit." Anyone who’s ever tried to quit smoking is intimately familiar with this phenomenon. Corporations are the same way—if you’re going to successfully eliminate a bad habit, find a better one to replace it. Don’t like a certain weekly meeting? Replace it with a different kind of meeting or alternate (more effective) ritual. Don’t like a useless reporting process? Don’t complain about it; write a useful one that’s too compelling to ignore. Once you’ve found a good replacement habit, you need to overcome the inertia of change aversion, so we recommend offering to "try" your new ritual for a few weeks. This makes the new thing seem less permanent, less scary, and if it turns out that everyone likes the new ritual, by the time your "trial" period is over, they’ve forgotten that it was a trial in the first place.

Whether you’re a manager or an individual contributor, you need to spend some of your time managing upward. By this we mean you need to try to ensure that both your manager and the people outside your team are not only aware of what you’re doing, but are aware that you’re doing it well. Some people find this mode of "selling yourself" distasteful, and it may remain so, but the benefits of doing this are huge.

As we’ll mention in Users Are People, Too, you need to underpromise and overdeliver whenever possible. We’re not advocating that you sandbag all your estimates and pad out your deadlines, but wherever you can, try to avoid promising things that you can’t deliver, even if it means saying "no" more often than you’d like. If you constantly miss deadlines or drop features, other people in the company will have less of a reason to trust you and will most likely pass over you when they’re looking for someone to get something done.

We recommend that you focus your energies on launching products over just about everything else. Shipping things gives you credibility, reputation, and political capital more than just about anything else in a company. Launching your product is a high-visibility event that shows you’re accomplishing something. As tempting as it might be to spend a ton of time cleaning up your code base and refactoring things, we’ve learned from experience that if you dedicate more than half of your time to this kind of defensive work, it’s hardly valued at all by anyone outside of your team, including your superiors. You will then find yourself in the somewhat embarrassing position of having almost nothing (politically) important to show for your time.^[52] This is not only a good way to get no recognition, but also a good way to get your product canceled.

Regardless of the kind of company you work in, believe it or not, it’s not that hard to create a sort of luck for yourself. Richard Wiseman, author of The Luck Factor,^[53] wrote about an experiment he performed to test the ability of people to spot chance opportunities:^[54]

He then goes on to note that lucky people "are skilled at creating and noticing chance opportunities." We think the same tenet applies to creating opportunities in companies: if you perform your job to the letter of the law and focus only on getting your own work done to the exclusion of all else, there will be few chance opportunities for you. If you help others get their jobs done when given the chance, even when it’s not part of your job, there’s no guarantee (nor should there be a "tit for tat" expectation) that they’ll return the favor, but many people will gladly repay the favor in the future if given the chance.

Every company has a gray-market favor economy that lives outside the org chart, and those favors are one of the main things that you can use to fill up your political bank account. There’s usually something you can quickly and easily do that benefits your company but is someone else’s job, and if you keep your eyes open for the chance to do these things (in many cases, someone will come right out and ask you to do something for them), you earn a bit of credit for your bank account in this favor economy. Think of these credits as a series of small bets: some will never pay you back, others will pay even money, and still others will pay enormous dividends. It’s hard to know which bets will pay off, but one thing that will pay off over time is that people will remember you as the person who helped them out in a jam. Later on, when you’re in a jam and you give them a call, they’re going to be considerably more likely—even eager—to help you out than if you gave them a big fat "not my job" response when they came looking for help. Even if you never get "paid back" you’ll often learn something new in the process of helping someone, and it feels good to help other people, so what do you have to lose other than a little time and effort?

One of the most interesting things about the favor economy is that your bank account doesn’t just empty out when you leave a job or a company—you’ll frequently be able to call on folks at your company for a hand even after you’ve left. This is all the more reason that you should never burn bridges when you leave a company, no matter how tempting it might seem at the time.^[55]

If you’re like most engineers, you expect a logical promotion process where all it should take to get promoted is to excel at your job. Unfortunately, this world exists only in the most enlightened companies. In most companies you need to put some amount of effort into "playing the promotion game" to get yourself promoted (usually in addition to excelling at your job).

If you’re happy with your job, your salary, and your team, you might choose to not play the promotion game and settle into your job at whatever title and job level you’re already at. This can leave you vulnerable in many situations—for example, your company reorganizes and you get shuttled to a new team, you get a bad manager, or you wind up under the thumb of the office politician.

The higher in the organization you can get (either as an individual contributor or as a manager), the more control you’ll have over your destiny inside the company. Putting a modicum of effort toward getting promoted when you’re comfortable in your position is a great way to invest in your security and happiness when something bad happens to your company or team. Keep track of your accomplishments and use them in your self-assessment. Update your résumé^[56] and share it with your manager or promotion committee. Read up on the promotion process and talk to your manager about what boxes you need to tick off to get promoted, and methodically work to tick off every box. Even if getting promoted is subjective and nondeterministic, there’s a lot you can do to increase the odds in your favor.

Every company has a "shadow" org chart that is unwritten but through which power and influence flow. There are only a few different types of people who make up the nodes in this graph.

Connectors are people who know people in every corner of the organization, and if they don’t know someone on a team, they can find the right person for you. Sometimes getting something done is just a matter of finding the right person to speak to, and the connector can help you find that person.

Old-timers may not have a high rank or fancy title, but they typically carry a lot of institutional knowledge and wield a lot of influence just because they’ve been around for a long time. These are great people to go to when you’re trying to understand why the organization works in a certain way, or if you need a supporter that a lot of people respect.

People most often talk about this in jest, but administrative assistants wield an enormous amount of power and influence in an organization because they are agents of the executives they work for. More importantly, they usually do an incredible amount of work to keep things running smoothly, so anger them at your own (and your career’s) peril. And never pass up a chance to be nice to an administrative assistant—they are the cornerstone of the Favor Economy.

Work in any big company long enough, and you’ll find yourself in a position where you need to email an executive (or any busy person you don’t know) to ask him for something. Perhaps you need something for your product or team, or you are looking to right a wrong. Whatever the case, this is likely the first time you’ve ever communicated with this person. In this situation, almost everyone makes the same rookie mistake: they ramble, rant, and rave.

Fitz (while working at Apple) bought his mom a lemon of an iMac more than 14 years ago, and on the advice of a coworker sent a "short" email to Steve Jobs.^[57] This email served as a rough prototype of how to effectively ask an executive for help:

Less than 20 hours later Fitz received a call from someone who worked for Steve, and two weeks later his mom had a new (non-lemon-flavored) iMac.

Here’s the big secret: when given a chance to help right a wrong, more often than not people in positions of power would love to do the right thing—even busy executives (many of them enjoy righting a wrong, and absolutely all of them understand the value of gaining a little extra political capital). Unfortunately, the email inbox of these people looks like a never-ending distributed-denial-of-service attack, and if they encounter an email from someone they’ve never met before that is 3,000 words of solid text with no paragraph breaks, the odds are good that they’re going to read 15 words in, press the Delete key, and then move on to the next email.

If, however, they can fix something by reading an email in 10 seconds and waving a magic wand (i.e., mailing one of their minions to Make It Happen), they’ll likely do it. They spend a few seconds delegating and get a big pile of political capital from you in return.

After years of trial and error, we’ve found that shorter emails are even more likely to get a response.

We call this the "Three Bullets and a Call to Action" technique, and it will drastically increase your chances of getting action—or at the very least, a response—from just about anyone you email out of the blue asking for something,^[58] not just an executive.

A good Three Bullets and a Call to Action email contains (at most) three bullet points detailing the issue at hand, and one—and only one—call to action. That’s it, nothing more—you need to write an email that can be easily forwarded along. If you ramble or put four completely different things in the email, you can be certain that they’ll pick only one thing to respond to, and it will be the item that you care least about. Or worse, the mental overhead is high enough that your mail will get dropped entirely.

The bullet points should be short sentences (each one should fit on a single line without wrapping), and the call to action should be as short as possible. If you want a reply from anyone, make it easier for the person to reply inline, preferably with a one (or two) word answer. Don’t ask half a dozen questions in one paragraph—limit yourself to a single question per paragraph, or ideally, a single question per email. Lastly, your email should be loaded with HRT: polite, respectful, and devoid of grammar mistakes and spelling errors. If you positively cannot help yourself and simply must include more background or information, put it at the very end of your email (even after your signature), and label it clearly as "More details" or "Background."

In hindsight, we consider Fitz’s prototype email to be a bit too wordy—if we were writing it today, it would probably look more like this:

This rewritten email eliminates a lot of the editorial color, but is now readable by a busy executive in 10 seconds.

In the course of our careers, we’ve used all of these techniques over and over again to get things done. But sometimes all the tips and tricks in the world aren’t enough to fix a job.

If you’re hungry and searching for a restaurant, how the restaurant appears from the street really matters. If it seems disgusting or uninviting you simply aren’t going in. If it’s warm and friendly and the host is kind, you’ll be willing to give it a fair chance. Don’t underestimate the emotional impact of a well-designed first experience with your product—if you’ve ever unboxed an iPad or a Nest thermostat, you know exactly what we mean here.

What is your product like to a newbie? Is it welcoming and does it encourage exploration? Conversely, for an expert who sits down to an initial session with your software, does it appear familiar and sensible? At first glance, does your app scream instant productivity, or steep learning curve and countless tears? More specifically, what does a user experience in the first 30 seconds after launching your software? Don’t just give an intellectual answer ("she sees a menu of choices, with a login box") but give an emotional answer too. How does a new user feel after a minute? Empowered or just confused? What can you do to improve that feeling? Step back a level and look at your product’s website. Does it seem professional and inviting, like a good storefront? You need to take these things seriously for your software to be taken seriously.

A lot of programmers hate the media industry—it’s just marketing in another guise. When a trade magazine or research firm comes knocking on the door, a lot of companies will drop everything and kowtow to their requests. They realize that a good (or bad) review can make or break a product’s perception. Engineers tend to resent this sort of power and deference, though.

For example, there was a time when members of the Apache Software Foundation (ASF) had problems interacting with analysts. An analyst would ask the ASF for industry-standard white papers describing their Apache HTTPD server, and the typical snarky response might be, "Go read the documentation on the website, like everyone else." While this satisfied the open source developers' deep commitment to meritocracy, overall it was counterproductive to public perception—particularly among corporate users. Eventually the ASF "PR person" worked to reeducate a number of community members about this attitude and deal more productively with analysts. Passive-aggressively fighting the system—no matter how irritating it is—just doesn’t make sense. It’s no different from telling the restaurant reviewer to get back at the end of the line. Should the reviewer get preferential treatment? Probably not. But is it worth sticking it to him as a matter of principle? Definitely not. You’re only hurting yourself in the process. Choose your battles carefully.