Dealing With Difficult People (2019)

Dealing With Difficult People

Dealing With Difficult People: A Complete Guide

How does your team interact with people outside your immediate group? There are almost always folks wishing to join or collaborate with your team. There are issues in dealing with the politics of your larger organization. And, of course, you need to have a plan for dealing with the most important outsiders of all: the users of your software!


In this blog, we’ll discuss the importance of preventing destructive outsiders from trashing the cooperative culture your team has worked hard to build. Perhaps more importantly, we’ll also talk about how to deal with difficult people already on your team.


Defining “difficult”

We’ve already reviewed the importance of building a solid, communicative team culture. We spent most of the time talking about what a good culture should include: things like consensus-based development, high-quality code, code reviews, and an environment where people feel comfortable enough to try new things and to fail fast.


Just as important is the need to talk about what your culture should not include. If you’re trying to build a highly efficient, fast-moving team, it’s important to focus on what you don’t want.


While brilliant engineers can make your team faster and more efficient, certain anti behavior can make your team slower and less efficient, and make your company a less comfortable place to work—and eventually erode the bonds that hold the team together.


When we first began speaking about the social challenges of software development, we came up with a presentation titled “How to Deal with Bad Eggs.” A conference chair suggested we rename the talk to “How Projects Survive difficult People,” with the hope that a more sensational title would draw a bigger audience.


And he was right: we gave the presentation over and over at different conferences to standing-room-only crowds. It’s not just the negativity of a word like difficult that attracted people, but the fact that everyone seems to have some sort of personal experience in dealing with irritating people.


The talks would almost always turn into a group therapy session, with audience members swapping war stories and seeking advice.


But there’s a danger here. In general, it’s not healthy to spend your time stewing in an ocean of negativity—it tends to eat you up and can create more conflicts in the long run. The term difficult person is a nasty label and automatically creates a dividing line between “us” (the good guys) and “them” (those nasty jerks).


There’s a better way to think about the problem. Instead of running your team as an elite fraternity with a mission to “repel mean people,” it’s healthier to create a culture that simply refuses to tolerate certain negative behaviors.


It’s the behaviors you want to filter out, not particular individuals. It’s naïve to think of individuals as purely good or bad; it’s more constructive and practical to identify and reprimand the intolerable behaviors.


For now, we’ll continue to use the term difficult person as a simplifying piece of rhetoric, one that refers to a person who isn’t behaving well. In practice, though, this is not a term you’d want to use in everyday conversations!


Fortifying Your Team

Recall our yeast metaphor: how a team culture grows from an important starter culture. The biggest single influence on the long-term culture of your team is the team you start with, and if the founding team doesn’t establish a strong enough culture, strains of other cultures will overgrow it.


If your starter team builds a strong sense of acceptable and unacceptable behaviors, these expectations will endure.


The two of us have spent a lot of time in the world of open source projects, and our own experiences jibe with this idea pretty strongly. The project we were most involved with—Subversion—was started by a very small group of people. They had a lot of humility and naturally trusted and respected one another.


After 15-plus years, the project has gone through at least three or four generations of participants (the founders are mostly gone), and yet the same culture persists—everyone is kind, is polite, and expects that same behavior from everyone else.


The culture perpetuates not just because of high standards, but because cultures tend to be self-selecting. Nice people tend to be attracted to existing nice communities.


Self-selection can easily work in the other direction as well. When a team is started by a group of angry jerks, the effort tends to attract more and more individuals of the same sort.


Certain projects that we won’t mention here (like the Linux kernel community) are keen examples of this—full of endless bickering and chest thumping.


Yes, the team may get a lot of work done, but the overall efficiency of its operation is doubtful. How much more work would get done if so much energy weren’t being spent on personal attacks? How much potential contribution is lost because polite people are being driven away at the front door?


We bring up this topic again because you need to understand what’s at stake: difficult people are a direct threat to your high-functioning team.


If you allow bad behaviors to persist, not only does your productivity decrease, but you may also find your culture slowly changing for the worse. The best defense is to fortify your culture through a strong set of best practices and procedures. 


  • Have a visible mission statement, to keep you focused on both your goals and non-goals.
  • Establish proper etiquette around email discussions. Keep archives, get newcomers to read them, and prevent filibustering by noisy minorities.
  • Document all history: not just code history, but also design decisions, important bug fixes, and prior mistakes.
  • Collaborate effectively. Use version control, keep code changes small and reviewable, and spread the “bus factor” around to prevent territoriality.
  • Have clear policies and procedures around fixing bugs, testing, and releasing software.
  • Streamline the barrier to entry for newcomers.
  • Rely on consensus-based decisions, but also have a fallback process for resolving conflicts when consensus can’t be reached.


The bottom line is that the more ingrained these best practices are, the more intolerant of difficult behavior your community will be. When troublemakers arrive, you’ll be ready.


Identifying the Threat

If you’re going to defend your team against difficult people, the first thing you need to do is to understand exactly what constitutes a threat and when you should become concerned.


What’s specifically at risk is your team’s attention and focus.

Attention and focus are the scarcest resources you have. The bigger the team, the more capacity the team has to focus on building things and solving interesting problems—but it’s always a finite amount.


If you don’t actively protect these things, it’s easy for difficult people to disrupt your team’s flow. Your team ends up bickering, distracted, and emotionally drained. Everyone ends up spending all their attention and focus on things other than creating a great product.


Meanwhile, one has to wonder: what does a difficult person look like? To defend yourself, you need to know what to look out for. In our experiences, it’s rare to find people who are deliberately being malicious (i.e., are trying to be jerks on purpose). We call such people “trolls” and typically ignore them.


Most people who behave badly, however, either don’t realize it or simply don’t care. It’s more an issue of ignorance or apathy, rather than malice. Most of the bad behaviors boil down to a simple lack of HRT.


Here are some classic signals and patterns to watch for. Whenever we see these patterns, we talk about “flipping the bozo bit” on the person—that is, we make a mental note that the person is consistently exhibiting difficult behav-iors and that we should be extremely careful in dealing with her.



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, difficult and draining our collective energy. 



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



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


Repelling the Poison

We don’t advocate throwing people out of a community just because they’re being antisocial or rude. As we mentioned earlier, it’s not healthy to create a clique focused on “us” (the nice people) versus “them” (the mean people).


In our prior examples, we didn’t focus on booting the person, but rather on booting the behavior. Make it clear that bad behaviors will not be tolerated. If, after repeated warnings, the behavior doesn’t change, only then does it makes sense to consider formal rejection.


Concentrating your effort on removing toxic behavior is often enough to turn an intelligent (although perhaps socially awkward) person into a productive member of your team. A few years ago we had a team member who was an excellent engineer but had an annoying habit of accidentally insulting teammates.


Rather than just ejecting him from the community, one of us pulled him aside and asked him if he was aware that his words were alienating people. He seemed somewhat surprised that this was happening and didn’t exactly understand why his actions were having this effect.


But he agreed that it would be worthwhile to try to temper his actions in the interest of being a better team member. And everything worked out perfectly. He changed his behavior, and the problem was resolved. Not every anecdote ends in exile!


OK, so you’ve identified a difficult person. Perhaps there’s someone distracting and draining your team’s energy right now. How do you deal effectively with the situation? Here are some useful strategies.



This is an old adage from Usenet. 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 care-2 Which may itself refer to that original Star Trek episode, “Day of the Dove,” in which negative emotions fed an energy creature?


Kirk and his Klingon counterpart Kang ordered their men to stop feeding the energy creature, and it departed from the Enterprise. See, it all comes back to Star Trek. fully 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 difficult person’s vitriolic prose, some wisdom really is buried in there. Always bring the argument back to a technical discussion.


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 difficult 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 difficult behavior, you need to ask yourself two critical questions:


Despite the short-term loss of your team’s attention and focus, do you truly believe the project will still benefit in the long run?

Do you believe the conflict will ultimately resolve itself in a useful way?


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 difficult 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:


I have several friends who know him to some degree. One of them said, “He often walks the fine line between genius and lunatic.” The problem is, genius is such a commodity these days that it’s not acceptable to be an eccentric anymore.

—Greg Hudson


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: we feel it creates unmanageable territoriality.


People are afraid to change the 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.


A Final Thought

This blog discussed quite a number of scenarios, and after taking everything in it’s easy to develop a deep sense of paranoia. Please remember that most of the world isn’t overflowing with jerks. A friend of ours once noted, “Yeah, there are only a few crazy people out there; the Internet just makes it seems like they all live next door.”


We prefer to use the term ignorance rather than stupidity, but the idea is the same. As we mentioned in the beginning, it’s naïve to think of people as Good or Bad. There are very few evil people out there trying to deliberately crush your cul-ture—most of them are simply misinformed or misguided.


Or perhaps they just want recognition and are too socially inept to fit in. Either way, your job isn’t to cultivate condescension and lock out the less enlightened peasants from your project; rather, your job is to be intolerant of destructive behaviors and to be explicit about your expectations of HRT. It takes wisdom to understand the difference and real skill to carry it out.


The Art of Organizational Manipulation

So far we’ve shown you how to handle the human side of you and your team. We’ve reviewed the basic people skills required for leading a team and the hazards of dealing with the threat of difficult people. In addition to these skills, you also need to understand how to navigate good and difficult companies alike.


Most people work in dysfunctional corporate bureaucracies and need to employ certain manipulative techniques to get things done effectively. Some people call these politics; others call it social engineering.


We call it organizational manipulation.


The Good, the Bad, and the Strategies

Big companies are complex mazes, and even the best require a GPS, a flashlight, and a dump truck full of breadcrumbs to navigate from one end of the company to the other. 


First, we’ll cover how a team typically functions in an ideal company, and then we’ll discuss the various ways a dysfunctional company can put up road-blocks to your team’s success. We’ll review strategies for getting things done in both kinds of companies, and lastly, if all else fails, we’ll cover Plan B.


How Things Ought to Be

There are two levels of a properly functioning company: your manager, who you’ll deal with most of the time, and the corporation beyond your manager, which includes knowledge workers, middle managers, executives, salespeople, lawyers, and so on.



If your manager is a servant leader who employs HRT and is truly interested in helping you succeed, 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 resist-ance—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. 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?


How Things Usually Are

There are innumerable ways in which the environment in your company can work to prevent you from succeeding, but they can usually be divided into two major categories: bad people and bad organizations.



It’s hard to know where to start in describing the traits of a bad manager—entire movies and TV shows have been created solely to lampoon the bad managers of the world.


Most of us have had at least one bad manager in our careers, and a bad manager can make life on even the greatest team a living hell, so we’re going to cover just a few of the traits of a bad manager that typically affect engineers.


Fear of failure is one of the most common traits of bad managers. This insecurity tends to make them very conservative, which is antithetical to the work style of the typical engineer.


If your manager doesn’t want you to take risks, there is little opportunity for you to inject your own ideas into your product and you’ll usually wind up implementing (by rote) the product someone else designed.


Oftentimes the insecure manager will insist on inserting herself into any interaction you have with people outside your team, thereby preventing you from speaking directly to other teams without “going through the chain of command.” This kind of manager will consider any direct contact you make with anyone outside your team—especially another manager—to be akin to mutiny or insubordination.


If you need anything outside of your team or their organization, this manager expects you to go through her, which allows her to elevate her importance and subordinate you, thus giving her more power.


Most of us grew up in school hearing the oft-repeated canard “knowledge is power.” The bad manager is very much aware of this, but from a different angle: she wants to keep this power to herself and not share it with you, no matter how much it might help you to do your job.


This manager hoards information and hides it from you as a way to make sure she can play a part in anything that involves that information, which not only keeps you from getting work done but also helps her maintain her position of relevance and power no matter how much it slows down development.


By hoarding information and requiring that they be a conduit for information and communication, bad managers are also able to take credit for your successes and blame you for your failures (and sometimes, their failures as well).


In many cases, this kind of bad manager sees your existence solely as a means to get herself promoted, and she doesn’t care about your career, much less your team’s happiness.


Our friend Susan had a terrible manager for a number of years, and her manager would often hand a new project off to Susan with no context, no information on how to get the project done, and no one to contact with questions.


He would do this even if Susan had zero knowledge or context about the new task because this forced her to rely on him for information as well as communication with other teams.


Susan’s manager didn’t necessarily want Susan to fail: in fact, if he’d told Susan everything she needed to know about the project, it would have made Susan’s life easier and more productive. On the other hand, he was most likely afraid that it would have been that much easier for her to circumvent him!


Having the ability to directly contact relevant teams would have made them aware that Susan, and not her manager, was working on this project. Time and time again Susan would scramble to get up to speed on the new project, get it done, and then collapse, only to find out through the grapevine that her manager had taken credit for her work.


The bad manager wants to know what you’ve done for him lately. And those low performers on your team? They’re not going anywhere as long as they don’t grind your team to a screeching halt—it’s too much work for the bad manager to deal with them. It boils down to this: is your manager serving you? Or are you serving your manager? It should always be the former.



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. 



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 the organizational hierarchy. 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 time-card?


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.


Still, other organizations will breed employees who judge their success not by the number and quality of the 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.


Manipulating Your Organization

This is a sparring program, similar to the programmed reality of the Matrix. It has the same basic rules, rules like gravity. What you must learn is that these rules are no different than the rules of a computer system. Some of them can be bent. Others can be broken. Understand? Then hit me if you can.


Much like the sparring program, companies are made of rules: some of them can be bent, and others can be broken. If you focus on the way things should be in your organization, you’ll usually find nothing but frustration and disappointment.


Instead, acknowledge the way things are, and focus on navigating your organization’s structure to find the mechanisms you can use to get things done and to carve out a happy place for yourself in your company.


Whether you’re in a good organization or a bad one, there are a number of strategies that we’ve found to be quite effective at getting things done.



First and foremost, know what you can get away within 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 within 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.  


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 within the company as well as which ideas just won’t fly.


Persuasion by proxy

If you’re trying to persuade someone, a great way to increase your chances of success is to find several people who agree with you and get them to drop your idea (or proposal or request) in a conversation with that person.


Even if your target is totally aware of what’s going on, basic human psychology dictates that she’ll give more weight to the idea because it’s hitting her from multiple directions and not just from you.


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.