Dealing With Difficult People (60+ New Hacks 2019)

Dealing With Difficult People

Dealing With Difficult People: A Complete Guide

As the opening quote of our blog suggests, the hardest part of creative work is people. Up until now, we’ve taken an introspective approach. We began with an examination of your own private behaviors and how to focus them on the principles of humility, respect, and trust (HRT). We then explored ways to build a communication team culture around these concepts.


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



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


Or, as the saying from Robert J. Hanlon goes:

Never attribute to malice that which is adequately explained by stupidity.


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.


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


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.



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.


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 give 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. This is not only a good way to get no recognition, but also a good way to get your product canceled.


“Offensive” Versus “Defensive” Work

When Ben first became a manager, it seemed like his team’s productivity was being crushed under a mountain of accrued technical debt. He decided that the team’s top priority was to spend a long time doing nothing but paying back this debt. His superiors gave a cursory nod to this plan and the work began.


Things didn’t go well. Despite the prior approval, Ben’s manager began to get annoyed and impatient after a few months— why was the team getting “nothing done”?


Ben’s team was actually quite productive and he tried to show the enormous amount of debt that had been paid back. But it turns out there’s just no way this sort of work can impress someone; at an emotional level, it’s just fundamentally boring.


After this bad experience, Ben began to categorize all work as either “offensive” or “defensive.” Offensive work is typically effort toward new user-visible features—shiny things that are easy to show outsiders and get them excited about, or things that noticeably advance the appeal of a product (e.g., improved UI, faster response times).


Defensive work is an effort aimed at the long-term health of a product (e.g., code refactoring, feature rewrites, schema changes, data migration, or improved emergency monitoring).


Defensive activities make the product more maintainable, stable, and reliable. And yet, despite the fact that they’re absolutely critical, you get no political credit for doing them.


If you spend all your time on them, people perceive your product as holding still. And to make wordplay on an old maxim: “Perception is nine-tenths of the law.”


We now have a handy rule we live by: a team should never spend more than one-third to one-half of its time and energy on defensive work, no matter how much technical debt there is. Any more time spent is a recipe for political suicide.



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, wrote that lucky people “are skilled at creating and noticing chance opportunities.”


We think the same tenet applies to create 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 that 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?


This same political bank account is what you’ll tap when you need to ask a favor of someone else in the company. It may be that you need someone to do something for you, or you do something that steps on someone else’s toes, or you even just disagree with someone else in your company.


It’s incredibly useful to develop an awareness of when you’re gaining political capital, and when you’re spending it. If you fail to develop this awareness, there’s a good chance that your account will be drained before you know it, leaving you powerless in your organization (and your career).


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.



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é 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. 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, not just an executive.


A good Three Bullets and a Call to Action email contain (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.”


Plan B: Get Out

In all the years that we’ve spoken about getting things done inside bad organizations and working with bad people, we always get people who come up to us after our talks and, exasperated, tell us they’ve tried everything and just can’t make any improvements or get anything done, so what can they do?


The unfortunate answer here is a simple one: there’s probably nothing else you can do. Don’t be a victim. Get the heck out of there.


If you can’t change the system, there’s no point in continuing to put energy into changing it. Instead, put energy into leaving it: update your résumé, and start asking your close friends if they know of any openings for you at other companies.


Train yourself in new things. One of the great things about being a knowledge worker in this day and age is that good one are in high demand, and that gives you the ability to control your own future.


Once you realize you have this control, it’s incredibly liberating. If you poke around and discover that you have other job options available to you, you may discover that you suddenly get a lot more things done at your work (under a lot less stress) because it’s not the end of the world if your current employer fires you! 


Do the right thing, wait to get fired

New Google employees (we call “Nooglers”) often ask me what makes me effective at what I do. I tell them only half-jokingly that it’s very simple: I do the Right Thing for Google and the world, and then I sit back and wait to get fired.


If I don’t get fired, I’ve done the Right Thing for everyone. If I do get fired, this is the wrong employer to work for in the first place. So, either way, I win. That is my career strategy.


If you’re prepared and know your options, you’re the most liberated person in the world. Don’t be afraid to get out. We’ve been giving this advice after our talks for over five years now, and are happy to report that several people have emailed us to let us know that they heeded our advice and are now doing jobs that they love. And these emails are some of the best we’ve ever gotten—here’s one of our favorites:


All Is Not Lost

All this talk about quitting or waiting to get fired doesn’t mean that if you’re unhappy in your job you should dust off your résumé and hit the streets.


On the contrary, your first objective should be to make the changes necessary to be happy and accomplish your goals at your job, and this blog has given you a lot of the tools you’ll need to do that. If you don’t put the effort into understanding how to navigate your organization, you’re leaving a huge part of your destiny to chance.


Users Are People, Too

We’ve explored a long list of ingredients that are critical to successful product development.

Start with a small group of smart, creative people. Fertilize the team with a strong culture of humility, trust, and respect. Lead them as a servant, empowering them to collaborate and make good decisions.


Give them water, sunlight, direction, and intrinsic motivation as needed. Protect them from negative influences—destructive behaviors (or environments) that threaten the culture and the ability to make progress. Bake at 72°F for six months, and you’ve got some great software. All done, right?


A lot of programmers stop there. They write software for themselves, are pleased with the end result, and then declare victory.

Unfortunately, that’s not how the real world works. “Good software” is an overly narrow definition of success. If you’re trying to pay the bills (or simply boost your résumé) you also need a lot of other people to use your software and be happy with it.


The software development process doesn’t end with throwing a product over a wall; it never ends, in fact. People use your product and you need to react to them, improving it over time. If you don’t learn how to master this feedback loop your creation will die.


We’ll examine three general phases of user engagement in this blog. First, you need to get users to notice your work—are they even aware that it exists? How do they perceive it before they walk in the door? Then you’ll need to think about what people experience when they start using it.


Does it meet their expectations? Is it usable? Does it empower them to do great things? Finally, we’ll look at how to interact productively with them once they’re firmly engaged with your creation. All of these interactions are part of the cyclical nature of product development.


The bottom line is this: collaboration isn’t just about working with your team; to make great things, you need to actively collaborate with your users too. If you’re not on top of these things, all you’ll have is a piece of shiny software with no users. If that’s the case, maybe it’s time to question your career choice!


Managing Public Perception

When you hear the term marketing, what’s the first thing that comes to mind?


If you’re like most folks, the word probably conjures up the image of a dis-honest salesperson, all fake smile and greased-back hair: somebody who’s all about building an image for a client or product. If your product is the raw “meat” to be sold, the marketing person’s job is to add the magic “sizzle” to the steak so that more people flock to it.


Why does this idea bug us so much? Why do we shudder at the thought of the marketing person?


Because, as programmers, the marketer represents the antithesis of engineering culture. We’re obsessed with truth. Either the code compiles or it doesn’t; the software has a feature or it doesn’t; it solves a problem or it doesn’t.


We don’t “spin” our descriptions of the world; we state the facts and then work to change them. We look at the marketing guy and all we see are lies, and we don’t like being lied to. We want order, predictability, and accurate statements when it comes to making decisions.


Because we perceive marketing as something that distorts the truth, it violates the maker’s instinctive desire for meritocracy. We believe the best product should always win. And by “best” we mean the product that objectively is of the highest quality and most effective, not the one with the slickest TV advertisements.


Over and over we’re disappointed when we see superior technologies lose out: many believe that Betamax was superior to VHS, that Laserdisc was better than DVD, or that Lisp is still the best programming language (we just need to get the word out!). Even in the world of version control tools, Subversion has taken over the corporate world despite the technical superiority of newer systems like Git.


What’s worse is we perceive marketing folks as overpromising to customers, which in turn makes engineers look like they’re always underdelivering. It makes steam pour from our ears.


We’re here to give you both bad news and good news.

The bad news is that no, you cannot ignore marketing. It actually matters and you have to deal with it. The good news is that it’s possible to actively cooperate with marketing. It doesn’t need to be a sleazy affair when you do it right. In fact, it can be an incredibly powerful tool for success!


Programmers tend to have an overdeveloped sense of logic, but most humans are driven equally by logic and emotion. The marketing folks are masters of emotional manipulation, and that’s why they’re so effective: they mix the facts with feelings to get attention.


If you want to get new people to use your software, you have to care about their emotional perception of your software. You can not change the way people make decisions.


Apple Inc. is the undisputed master of making technology appeal to the emotions of nontechnical people. Firmly dating ourselves in the year 2015, we ask: is an iPhone objectively superior to an Android phone?


Featurewise they’re almost identical. But if a nontechnical user believes an iPhone is magical, it really is magical, at least to that user. Perception is a reality. Or as we’ve said earlier, “Perception is nine-tenths of the law.”


It’s tempting to think that the only way to win is not to play, but this is a game you’re not allowed to ignore. You need at least a minimal marketing strategy to even get your software in the ring, and if you’re smart about it then you’ll discover that marketing can be a serious force multiplier for great engineering. Here are some basic things you can do to take control, and they’re all based on HRT.



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.



Don’t let your marketing people preempt you here. If users ask about upcoming features or release timelines, take the opportunity to give overly conservative estimates. If you let marketers spread rumors, you’ll end up with a Duke Nukem Forever situation—software that’s teased for shipping 15 years late.


But if your own (more accurate) message gets out first, your users will always be thrilled. Google is great at this; it has a deliberate policy of not preannouncing features for any product.


When new features roll out they’re often a delightful surprise. It also prevents internal death marches to meet unrealistic advertised launch dates. The software is released when it’s actually ready and usable.



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


How Usable Is Your Software?

Here’s a hard truth: unless you’re developing software tools, engineers are not the audience of your software. The corollary is that you, as an engineer, are a terrible evaluator of your software’s usability. An interface that seems totally reasonable to you may very likely make your nontechie neighbor pull out her hair in frustration.


If we assume that “successful software” means “lots of people use and love your software,” you need to pay deep attention to your users. Google has a famous motto:


Focus on the user, and all else will follow.

It sounds fairly campy, but over our careers, we’ve watched this maxim play out over and over across multiple projects. We’ve witnessed projects succeed and fail based on this truth.


One of Google’s big breakthroughs was to begin measuring the effectiveness of search ads. If users click on a particular ad, it must be useful to them; if it never gets clicks, it must be annoying or useless. Bad ads get removed from the system and feedback is given to the advertiser to improve its ads.


At first, this seems counterproductive for the short term: Google is actively rejecting revenue sources. But by making the searcher (rather than the advertiser) the focus of attention, it dramatically increases the usefulness (and usage) of Google’s search advertising system over the long term.


Let’s talk about some important ways you can focus directly on your users.


First things first: imagine your users fall across a spectrum of technical competence.

If you were to draw a vertical line showing which set of users is best suited to your product, where would you put it? A vertical line through the center of the bell curve means that about half of all computer users would be happy using your product (i.e., those to the right of the line).


As an example, let’s take the problem of wanting to display Internet content on your large TV screen. How has the “usability” of competing solutions widened potential audiences?


 Initially, people had to plug their laptop computers directly into their televisions. This involved understanding analog versus digital inputs and having the right sort of audio and video cables.


Apple then came out with an Apple TV product—a small computer-like appliance that you left permanently plugged into your TV.


It could be controlled from a computer or smartphone, and you could stream either your private media or live Internet content. This solved the problem for a much larger (and less technical) audience: it came with the proper cables, and you plugged it in once and left it there.


Google then one-upped things by coming out with the Chromecast, a small stick that plugs directly into a TV’s HDMI port. It was even easier to install and allowed people to “cast” their screen from a wider array of both Apple and non-Apple devices.


At the time of writing, we’re now seeing new TVs being shipped with built-in WiFi and Internet streaming. It’s likely that Ben’s kids will never remember a time when TVs didn’t have Netflix built in!


The point here is that good product development aims to move the vertical line to the left as much as possible. In general, the more users you have, the more successful you are (and the more money your company makes!).


The moral here is that when you’re considering your users, think hard about who your audience is. Is your work usable by the biggest group possible? This is why simple and thoughtful user interfaces matter so much—as well as things like polished documentation and accessible tutorials.



Now think about the first-time users of your software. How hard is it to get going for the first time? If your users can’t easily try it out, you won’t have any. A first-time user usually isn’t thinking about whether your software is more or less powerful than a competitor’s; she just wants to get something done. Quickly.


To illustrate, take a look at popular scripting languages. A majority of programmers will espouse that Perl or Python is a “better” language than PHP. They’ll claim that Perl/Python/Ruby programs are easier to read and maintain over the long run, have more mature libraries, and are inherently safer and more secure when exposed to the open Web.


Yet PHP is far more popular—at least for web development. Why? Because any high school student can just pick it up through osmosis by copying his buddy’s website.


There’s no need to read blogs, do extensive tutorials, or learn serious programming patterns. It’s conducive to tinkering: just start hacking on your site and figure out different PHP tricks from your peers.


Another example can be found in text editors. Should programmers use Emacs or vi? Does it matter? Not really, but why would a person choose one over the other? Here’s a true anecdote: when Ben first started learning Unix (during an internship in 1990) he was looking for a text editor to launch.


He opened an existing file by launching vi for the first time, and was utterly frustrated within 20 seconds—he could move around within the file, but couldn’t type anything!


Of course, vi users know that one has to enter “edit” mode to change the file, but it was still a horrible first experience for a newbie. When Ben launched Emacs instead, he could immediately begin editing a file just like he would do on his familiar home word processor.


Because the initial behavior of Emacs was identical to his previous experiences, Ben decided to become an Emacs user within his first minute. It’s a silly reason to choose one product over another, but this sort of thing happens all the time! That first minute with a product is critical.


Of course, there are other ways to destroy the first impression. The first time your software runs, don’t present the user with a giant form to fill out or a giant panel of mandatory preferences to set.


Forcing the user to create some sort of new account is pretty off-putting as well; it implies long-term commitment before the user has even done anything.


Another personal pet peeve is a website instantly blasting a visitor with a modal “Subscribe to us!” dialog box within the first two seconds. All these things send the user screaming in the other direction.


A great example of a nearly invisible barrier to entry is the TripIt web service, which is designed to manage travel itineraries. To start using the service simply forward your existing travel-confirmation emails (airplane, hotel, rental car, etc.) to Poof, you’re now using TripIt.


The service creates a temporary account for you, parses your emails, creates a gorgeous itinerary page, and then sends an email to tell you it’s ready. It’s like a personal assistant instantly showing up, and all you did was forward a few messages!


With almost no effort on your part, you’ve been sucked in and are browsing the website as an involved user. At this point, you’re willing to create a real service account.


If you’re skeptical about your own product’s barrier to entry, try doing some simple tests. Give your software to ordinary humans—both technical and non-technical—and observe their first minute or two. You may be surprised at what you discover.



In pondering the size of your user base and whether it’s easy to get started, you should also consider how you measure usage. Notice that we said “usage,” not “number of installs”—you want a high number of users who use your product, not a high number of times people download your product.


You’ll often hear someone say, “Hey, my product has had 3 million downloads—that’s 3 million happy users!” Wait; back up. How many of those 3 million users are actually using your software? That’s what we mean by “usage.”


As an extreme example, how many machines is the Unix archive utility “ar” installed on? Answer: just about every Unix-based OS out there, including all versions of Linux, Mac OS X, BSD, and so on. And how many people use that program? How many even know what it is? Here we have a piece of software with millions of installs but near-zero usage.


Usage is something that many companies (including Google) spend a lot of time measuring. Common metrics include “7-day actives” and “30-day actives”— that is, how many users have used the software in the past week or month.


These are the important numbers that actually tell you how well your software is doing. Ignore the download counts. Figure out a way to measure ongoing activity instead.


For example, if your product is a website or web app, try a product like Google Analytics; it not only gives you these metrics, but also gives you insight into where your users came from, how long they stayed, and so on. These are incredibly useful indicators of product uptake.


Design Matters

Before the Internet came into prominence, the biggest challenge to getting any product to market was one of distribution. Few companies had the wherewithal to write a product and get it into thousands of stores across the world, so when a company put a product out there, they would then market the hell out of it.


This typically resulted in one or two “winners” in each software category (e.g., Micro-soft Word versus WordPerfect, Excel vs. Lotus 1-2-3, etc.). The primary criteria you used when choosing a product were features and cost, no matter how ugly or unintuitive the software was.


That, however, has changed.

The Internet is a global distribution network where it costs almost nothing to find and download software. And social media makes it easy for people to share their feelings about various products across the globe in seconds.


The result of these two massive changes (and a host of other, smaller factors) means that consumers today have a choice of what product to use.


In this highly competitive environment, it’s no longer enough to just get a product out there with the necessary features—your product needs to be beautiful and easy to use.


These days, no amount of marketing will rescue a crappy product, but a well-designed product that delights the people that use it will turn these same people into evangelists that market the product for you.


So good design is key, but a big part of good design is putting the user first, hiding complexity, making your product fast, and, most importantly, not being all things to all people.



When we say to “put the user first,” we’re suggesting that you and your team should take on whatever hard product work you can to make using your product easier for your users.


This may mean some hard engineering work, but more frequently it means making hard design decisions instead of letting your users make these decisions every time they use your product.


We refer to this as prod-uct laziness. Some would argue that laziness is a virtue for engineers because it leads to efficient automation of work. On the other hand, it can be easy to create something that results in great pain for users. Making software easy for users is one of the greatest challenges in product development.


A classic example of this kind of laziness is to present too many options to your users. People love to make fun of the late-1990s generation of Microsoft Office products: button bars! They make every possible menu item instantly available…for great convenience! User interface designers love to make fun of this idea, especially when taken to an extreme:


Having too many options is overwhelming. It’s intimidating and off-putting. There have even been blogs written about how too many choices create anxiety and misery. You even need to be careful with your software’s Preferences dialog. (Did you know that Eudora, a popular email client, had 30 different panels of preference values?)


And if you’re making someone fill out a form, be lenient in what you accept: deal with extra whitespace, punctuation, or dashes. Don’t make the user do the parsing! It’s about respecting the user’s time. It’s really obvious (and infuriating) when a programmer could have made something friendly and easy for the end user but didn’t bother.



Most programmers vastly underestimate the importance of application speed (or latency, which sounds more scientific). Its effects are both fundamental and profound.


First, latency is another type of “barrier to entry.” We’ve become spoiled about web page speed. When told to check out a new website, if it doesn’t load within three or four seconds, people often abort and lose interest.


There’s simply no excuse here. The web browser makes it easy to walk away and redirect our attention to 12 other places. We have better things to do than wait for a page to load.


Second, when a program responds quickly, it has a deep subliminal effect on users. They start using it more and more because it feels frictionless. It becomes an unconscious extension of their abilities.


On the other hand, a slow application becomes increasingly frustrating over time. Users start using the software less and less, often without even realizing it.


After a product launch, it’s exciting to see usage grow over time. But after a while the usage often hits a limit—it just sort of flatlines. This is the point where the marketing folks often step in and scream about needing more features, prettier colors, nicer fonts, or more animations that “pop.”


Sometimes, however, the actual reason for the stall is latency. The program has become laggy and frustrating. As the next graph shows, user engagement decreases as latency increases.


A true story from Google: an engineering team one day released some dramatic latency improvements to Google Maps. There was no announcement, no blog post; the launch was completely secret and silent. Yet the activity graph showed a huge (and permanent) jump in usage within the first couple of days. There’s some powerful psychology going on there!


Even small improvements in latency matter when you’re serving a web-based application. Suppose it takes 750 milliseconds for your main application screen to load. That seems fast enough, right? Not too frustrating for any given user. But if you could slash your load times to 250 milliseconds, that extra half of a second makes a huge difference in aggregate.


If you have a million users each doing 20 requests per day, that amounts to 116 years of saved user time—stop killing your users! Improving latency is one of the best ways to increase usage and make your users happy. As Google’s founders like to say, “Speed is a feature.”



Is your software trying to accomplish too much? This sounds like a silly question at first, but some of the worst software out there is bad because it’s overly ambitious. It tries to be absolutely everything to everyone.


Some of the best software succeeds because it defines the problem narrowly and solves it well. Instead of solving every problem badly, it solves really common problems for most users and does it really well.


We often joke about certain gadgets we see in magazine ads: hey, look, it’s a camping lantern, with a built-in weather radio!…and, uh, also a built-in TV, and um, stopwatch, an alarm clock, and…eh? It’s a confusing mess.


Instead, think of your software as a simple toaster oven. Does it cook everything? Absolutely not. But it cooks a lot of really common food and is useful to almost everyone who encounters it without being overwhelming. Be the toaster oven. Less is more.



“But my software is complex,” you may think, “and it’s solving a complex problem. So why should I try to hide that?” That’s a reasonable concern, but it’s also one of the central challenges of good product design.


Elegant design makes easy things easy and hard things possible. Even when doing complex things your software should feel seamless and easy. (Again, we’re focusing on the user’s emotions.)


This is what we like to call “hiding the complexity.” You take a complex problem and break it up, cover it, or do something to make the software seem simple anyway.


Look at Apple again. Apple’s product design is legendary, and one of the cleverest things it did was to creatively tackle the problem of managing MP3 music collections. Before iPods came along, there were a handful of awkward gizmos that tried to manage music right on the portable device.


Apple’s genius was to realize that MP3 management was too difficult a problem to solve on a tiny screen, so it moved the solution to a big computer. iTunes was the answer.


You use your computer (with big screen, keyboard, and mouse) to manage your music collection, and then use the iPod only for playback. The iPod can then be simple and elegant, and organizing your music is no longer frustrating.


Google Search is another well-known example of hiding complexity. Google's interface (and a barrier to entry) is almost nonexistent: it’s just a magic box to type in. Yet behind that box, there are thousands of machines across the planet responding in parallel and doing a search after every keystroke you type.


By the time you hit Enter, the search results have already rendered on your screen. The amount of technology behind that text box is jaw-dropping, and yet the complexity of the problem is hidden from the user. It behaves like Magic. This is a great goal for a creative team to pursue since it’s essentially the epitome of product usability.


Finally, we should mention a caveat about complexity. While masking complexity is laudable, it is not a goal to seal the software so tight that it ends up handcuffing all your users. Hiding complexity almost always involves creating clever abstractions, and as a programmer, you need to assume that the abstractions will eventually “leak.”


When a web browser prints a 404 error, that’s a leaked abstraction; the illusion is cracked. Don’t panic, though—it’s better to assume that abstractions are leaky and simply embrace them by providing deliberate ways to lift the curtain.


A great way to do this is to provide APIs to other programmers. Or for really advanced users, create an “expert mode” that provides more options and choices for those who want to bypass the abstractions.


Not only is it important to keep the interface flexible and circumventable, but the user’s data needs to be accessible as well.


Fitz put a great deal of passion into making sure Google products offer “data liberation”—that it’s trivial for a user to export his data from an application and walk away.


Software shouldn’t lock users in, no matter how elegant the interface is. Allowing users to open the hood and do whatever they want with their data forces you to compete honestly: people use your software because they want to, not because they’re trapped. It’s about engendering trust, which (as we’ll mention) is your most sacred resource.


Managing Your Relationship with Users

OK, so your product is appealing on first sight. It’s easy to get started. And once people begin, it’s really pleasant. What happens months down the line? How do you interact with people who use your product every day, for years at a time?


Believe it or not, many users want to have a relationship with your company or team. Happy users want to know what’s going on with your software’s evolution; angry users want a place to complain.


One of the biggest mistakes programmers make is to toss software over a wall and then stop listening to feedback.


Like marketing, the term customer service also typically has a negative connotation. A career in “customer service” often conjures up an image of a barista working at a coffee shop or a room full of robotic people answering support calls. But in reality, customer service isn’t a nasty, soul-draining task; nor is it something that other people (with lesser job descriptions) do.


It’s a philosophy to live by—a way of thinking about your ongoing connection to users. It’s something you need to do proactively as a creative team, not as a mere reaction to external complaints.


Engineers often dread direct interactions with users. “Users are clueless,” they think. “They’re annoying and impossible to talk to.” And while nobody’s requiring you to shower every user with love, the simple fact is that users want to be heard.


Even if they make inane suggestions or clueless complaints, the most important thing you can possibly do is acknowledge them.


The more you allow them to participate in the discussion and development process, the more loyal and happy they’ll be. You don’t have to agree with them, but you still need to listen. This is the “Respect” in HRT!


Companies are rapidly learning this in the age of social media—just reaching out to someone as a human and not as a giant, faceless corporation is often enough to alleviate that person’s concerns. People love it when corporations openly display HRT.


We like to illustrate the importance of managing users over time by drawing another simple (slightly unscientific) graph. As time goes on, your software gains more and more users. Of course, as you “improve” the product, it also gains more and more complexity:


The problem here is that as the number of users increases, their average level of technical ability decreases because you’re covering more and more of the general population.


Pair this up with ever-increasing complexity and you’ve got a serious issue with users’ despair. More despair means more complaints, angrier users, and an ever-increasing need for open communication with the software developers!


What can you do to avoid this trend?

To begin, don’t be in denial about the problem. Many corporations instinctively do everything they can to put up walls of bureaucracy between programmers and users. They create voicemail trees to navigate through or file complaints as “help tickets” that are tracked by layers of people who aren’t actually writing the software. 


Messages are relayed only indirectly through these layers, as though direct contact with the dangerous rabble might endanger developers (or pointlessly distract them). This is how users end up feeling ignored and disempowered and how developers end up completely disconnected.


A much better mode of interaction is to directly acknowledge users. Give them a public bug tracker to complain in and respond to them directly. Create an email list for them to help one another. Interact directly with users in social media. If your product can be open source, that’s a huge help as well.


The more “human” you appear to users, the more they trust in the product, and despair begins to lessen. Be on the lookout for people using your products in unexpected (and awesome) ways. Only through true dialogue can you discover what they’re really doing with your software, possibly something clever or thrilling.



Give users respect by default. A common misconception that powers our fear of direct user interaction is the myth that users are stupid. They’re not writing the software, after all, so they’re just “clueless users,” right? When you finally have an opportunity to interact with them, the most important thing to remember is to avoid condescension.


Being a savvy computer user is not a fair measure of general intelligence. A lot of brilliant people out there use computers as a tool and nothing more. They’re not interested in debugging or following scientific methods to diagnose a problem.


Remember that most of us have no idea how to take apart and fix our cars; assuming your users are stupid is akin to an auto mechanic thinking you are stupid because you don’t know how to rebuild a transmission, nor even care how to diagnose a transmission problem.


The car is a black box—you just want to drive. For most people, the computer (and your software) is a black box, too. Users don’t want to participate in the analysis process; they just want to get some work done. It has nothing to do with intelligence!



The corollary, then, is to learn great patience. Most users simply don’t have the vocabulary to express their problems succinctly. It takes years of practice to learn to understand what they’re saying: just ask anyone who has tried to provide computer tech support to his parents over the phone (which is probably most of you reading this blog!).


Half of the discussion comprises just trying to agree on the same vocabulary. Many people don’t know what a web browser is, thinking it’s just part of their computer. They describe applications as actions or talk about screen icons as mysterious workflow names.


The thing is, even the most intelligent folks have a knack for creating their own logical universe (and vocabulary) that explains how computers behave. They begin to diagnose problems in terms of imaginary taxonomies and rules that exist only in their minds.


A lot of people also have magical preconceptions of Google’s search service. Many people think it’s just part of their computer. In 2005, we used to get puzzled looks from people when we told them we were engineers at Google: “Oh! I didn’t know anyone worked there?!”


“That’s terrible! How can they all go skiing?” she asked. “Who’s going to do all my searches for me?” Clearly, Google was being negligent, not leaving enough switchboard operators to keep the traffic running.



There are two more watchwords that should become the cornerstones of the way you interact with users: trust and delight.

Trust is a tricky term. We’ve already talked about trust in the context of HRT—about whether and how you exhibit trust toward your coworkers. In this case, we’re talking about garnering trust from users.


When a user trusts your team (or your company) it’s mainly an emotional state: very few people would ever say, “I trust product X because of this long list of facts that prove that my relationship with it carries zero risks.”


They trust you because the cumulative set of interactions they’ve had with you add up to an overall emotionally positive state.


Think about your friends and family for a moment. How many of them have an auto mechanic they really trust? These days the answer is nearly zero.


Almost nobody trusts auto mechanics, because we’ve been badgered by years of what is called “mailboxing”: when you come in for one scheduled service (like an oil change), but a bunch of other unexpected maintenance services is piled on, much like junk mail stuffed into your mailbox.


Nobody believes mechanics any-more because they’ve been instructed to maximize profit at every opportunity. Remember, there is no such thing as a temporary lapse of integrity.


This is a great example of how the long-term relationship can be easily sacrificed for short-term gain. Screw your customers just a teeny bit every now and then, and eventually, they view the relationship through a veil of aggregated disdain. On the other hand, every time your team does something helpful or useful or is responsive, a bit of trust is added to an imaginary bank account in their minds.


When a baker adds a surprise 13th donut to your dozen (“lagniappe,” as they call it in New Orleans), this brings a smile to your face. Over years of dealings, the trust account grows and grows until the mention of your product brings a warm, fuzzy feeling. 


Trust can be dangerous, however, because it can be blown all at once—just like a bank account can be drained with a single stupid, impulsive purchase. If your company does something that shows a total lack of respect for users (even if by accident), the trust bank is emptied overnight.


A good example of this is the way Netflix temporarily messed up its relationship with users in late 2011. Netflix is both a service for streaming movies over the Internet and also a way of renting DVDs by postal mail.


Over the period of a decade, it became increasingly popular: it was easy, convenient, and novel. The price was cheap. By early 2011 it had more than 23 million subscribers.


At some point, the business folks realized their DVD and streaming services were really separate businesses with separate profit models, management needs, and so on. So they decided to start charging for these businesses separately, raising their monthly fees 60% for some users. Customers were furious.


Then Netflix announced that it would be splitting into two separate companies for greater clarity and convenience; to users, this simply read as “now you have the annoyance of two bills to pay instead of one.” Realizing they had a PR disaster on their hands, they then unannounced the splitting of the company, but by that time it was too late.


The damage had been done. Despite a history of continuous growth, they lost 800,000 subscribers in the span of three months. They managed to blow most of a decade’s worth of trust with just a couple of small moves that seemed like simple and necessary business decisions but had little regard for existing relationships.


(Luckily, they managed to totally rebuild their bank of trust over the next few years by paying careful attention to service and content; they came back even stronger!)


Trust is your most sacred resource. Watch it carefully. Measure the size of the bank account. Before every move, think about how it will affect the bank account. Focus on your long-term image, not short-term conveniences. 


Like trust, delight is another feeling that can vastly improve your relationship with users. It’s a way of increasing that warm, fuzzy feeling and making your team seem more human.


You have to start by not taking yourself too seriously. Google has a tradition of making outlandish product announcements on April Fools Day; for example, one year, every video on the front page of YouTube caused a “rickroll.”


Or take a look at Woot: Daily Deals for Electronics, Computers, Home, Tools, Garden, Sport, Accessories, Kids, Shirt, Wine, & more. It’s a daily deal site, but the advertising copy is full of self-deprecating and quirky humor.


Try to surprise your users with amazing, wonderful bits of happiness. (That’s the definition of delight, isn’t it?) Despite Google being a powerhouse of hard computer science, nothing excites its users more than the occasional “doodle” that illustrates a holiday or anniversary. It’s just a tiny bit of artwork injected into people’s day and yet it inspires endless letters of feedback and office water-cooler discussions.


Of course, a bit of horror can inspire users as well, as long as it’s done humorously. A company trying to start a social network once wanted to encourage new users to upload pictures of themselves; eventually, the company decided to start showing a picture of snarling Dick Cheney for every user who hadn’t done so—and the photo uploads suddenly started pouring in!


Adding bits of delight and humor—tactfully—goes a long way toward showing that you’re actually paying attention to users and care about your relationship with them.


Our day jobs as programmers are so full of distractions—code reviews, design reviews, fighting with our tools, putting out production-related fires, triaging bugs—that it’s easy to forget the reason we’re writing software at all. It’s not for you, or your team, or your company.


It’s to make life easier for users. It’s critical to pay attention to what they’re thinking and saying about your product and how they’re experiencing it over the long run. Your users are the lifeblood of your software’s success. You reap what you sow.