“Featuritis” is a common affliction because we humans are afraid of conflict, and many software team leads are afraid to say no. Sometimes the fear isn’t of conflict, but rather of not being good enough; software team leads are frequently afraid that the software won’t do everything it could and acutely aware of how much it could do. This attitude leads to fear-based design and in turn generates overly complicated products that never ship. There’s a simple solution to this problem.

Any feature that isn’t part of the absolute minimum viable feature set can go into V2. The test for any feature is, “Can the user complete the basic task for which this software was invented?” If the user can complete the task without the feature, even if the accomplishment of that task was particularly painful and ugly, then the feature can go into V2. You must be diligent about this test, because every line of code (except for unit tests!) decreases the probability of shipping, and without shipping there is no greatness.

If you suggest that a feature go into V2 and you hit resistance, it’s time to negotiate.

Nearly every feature or user experience debate ends up as some form of hostage negotiation. You have their baby, or they have yours, and unless someone’s way is gotten…the baby gets it. Whether you’re debating if a bug is a blocker or the icons should be green or blue, this conversation is a negotiation—and the baby in jeopardy is your product. If you were the Big Boss, you could take the baby and run, but you’re not. Instead, you probably have little or no legitimate authority, so negotiating to a great consensus quickly is critical to your success.

The first step in negotiating properly is to understand that even though you are a product owner, you’re not the boss. Your team is working with you because they like you or they like the product. They’re not working on your product because they have to. It’s a given in the software industry that anyone you’d want to work with could easily work somewhere else. Therefore, it’s critical to bring your team along in the decision-making process and enable them to own the product with you.

Team leads commonly make the mistake of conducting decision-making meetings in small groups. Having a small meeting seems efficient on its face, but isolating the meeting from your engineering team can isolate the team from the decision-making process. If you isolate the team from decisions, they will disengage from the product development process and leave you. If you want to be great at shipping, you need a team that feels engaged and empowered to participate and voice their concerns.

A better process for team decision making is to engage with all the members of the team at an early stage, before your plans are finalized. In my experience, this approach is more efficient in the long term because you have the opportunity to explain the business objectives and team goals to the entire team at the beginning of the project. If you instead have many small meetings with senior stakeholders and then deliver a fully baked plan, you will probably need many more small meetings to deal with concerns that arise late in the game. Even worse, one or more of those concerns might be legitimate and cause some substantial change in your plans. Good project management technique says that you want to take all changes as early as possible in the development process.

Management guru Peter Drucker has a slightly different take in his book The Effective Executive, arguing that you want to have brief meetings with clear goals and relatively few attendees. His advice differs a bit from mine, but he also says that the effective executive should publish the agenda for the meeting to all concerned parties and plan to send clear notes afterward. This enables concerned parties to join the meeting and marginally concerned parties to understand the outcome. The details in his approach align well with what I suggest, so feel free to follow Peter’s advice, even though it is somewhat less collaborative.

If there’s a guiding principle that you should embrace when thinking about whom to involve in decisions, it’s transparency. Be transparent about why decisions are made. Be transparent about when decisions will be made. Be transparent about how your team can engage in the product process.

Once you’ve brought the right people together, you need to negotiate to consensus, not to a victory for yourself. Many software leaders can be a bit macho, and this leads to a victory-first approach. In a classic example, a young, tough, macho Google product manager went into a naming review at Google to decide the public name for his product. He was remembered by the marketing team later as saying, “Let’s call it Google Turbo!” and was, unfortunately, laughed at. Macho tends to be bossy, confrontational, and occasionally comic.

It is therefore unsurprising to me that many of the best software leads are women, even though men primarily populate the profession. Anita Woolley and Thomas Malone conducted some studies that offer insight into why this might be the case.^[6] By comparing the IQ of individuals to the IQ of groups composed of the same individuals, the researchers discovered a remarkable and strong correlation: the higher the ratio of women to men in a group, the higher the collective IQ of the group. Their theory of causation is not the lack of a Y chromosome. Instead, they believe that the women in their study brought more collaborative skills to the exercise, whereas the “macho” types tended to act like a boss and dictate an answer.

Woolley and Malone’s conclusion makes complete sense to me. Brian Marsh, an engineering manager at Google responsible for a substantial part of Google Apps’ and Google+’s success, says that a team lead “needs to learn to move at the speed of N, where N is the size of the team.” The women in the study were able to reach a consensus that was smarter than they were individually, and the men weren’t. In other words, their collaborative approach generates a product name that’s better than “Google Turbo.”

Put another way, in an old-style compromise between you and a teammate, both of you win 50%, but both of you also you lose 50%. Alternatively, if you and your teammate can work together to reach a creative consensus that achieves your collective goals, 100% of you win and you have achieved what the women-influenced groups in the study achieved—a smarter outcome than either of the individual solutions.

Your goal, therefore, is to facilitate a creative solution that meets the needs of all parties. The Harvard Negotiation Project, popularized by Roger Fisher and William Ury in their book Getting to Yes (Penguin), identified the first key step in this process, which is to agree on the objectives.

Let’s pretend that I want to use your address book service in my Hello World application. I ask nicely, and you say no initially, because you’re already underprovisioned and you don’t have additional capacity in your servers. I bet this is feeling familiar, right?

You and I can state and agree upon the objectives that we have in this conflict:

These objectives seem pretty reasonable, and because we agreed that they were reasonable, we started from a point of consensus. Now we can work through each objective to invent a number of solutions that meet all the criteria, such as locally caching address book data on my servers, adding more capacity to your fleet, or building in support for HTTP 503 messages with a response field that points to a read-only version of the database, etc. Inventing a win-win solution that meets the needs of all parties is one of the most important and satisfying parts of being in a leadership role, and should inspire you to embrace negotiations as opportunities for invention.

Sometimes you’ll get stuck in your negotiation before you can even discuss the objectives. When this happens, there are three techniques that I’ve seen help get the negotiation back on track:

Up to now, we’ve focused on negotiation and collaboration in general, but there’s a common scenario that requires a slightly more specific set of skills: financial negotiations. Sooner or later, you’re going to do a deal for real money, not your Monopoly money stock. Your first deal, or even your 1,000th deal, can be intimidating, particularly if you own the company and it’s your money you’re going to spend. However, nearly all deals are pretty straightforward even though they feel fraught with craziness. I’ve done quite a few of these deals, including two corporate acquisitions at Google, and I’ve learned that negotiating financial transactions is like grieving: there are stages, and if you understand them you can better cope with your life and the outcome of the deal.

The third and final tool you need to reach a great consensus is conflict management. We can assert from the start that there are a lot of a-holes out there, and they breed conflict. You may even think you work with a unique nexus of a-holes, idiots, and self-absorbed twits. But because you’re in the software industry, the odds are really quite small that this is the case. The odds are much better that the people you work with have subnormal communication skills and supernormal technical skills.

“But wait,” you may be saying, “I work with product managers and engineering VPs and designers—they certainly can’t have bad communication skills!” Ergo, they must be a-holes. You might be right. More likely, these people are so used to dealing with engineers and folks like you that they’re desperately insecure and afraid that you’re going to randomize their efforts. These people also care about shipping. Perhaps they care less about shipping than you do, but they care enough to be afraid that you’re going to alter their designs, objectives, or question their decisions in such a way that you’ll spark a reset.

Tony Schwartz is a management guru who wrote that in situations like this, you need to tell yourself a different story.^[7] The story he’s talking about is the explanation you create for yourself to explain someone’s bizarre behavior. But it’s just that: a story, and it’s created from assumptions. Instead of assuming that the other person in this conflict is an a-hole, consider telling yourself a different story.

I’ll give you an example. When I joined the Maps team at Google, I was really frustrated by the design team. They seemed sharp and nice, but I was constantly butting heads with them when I asked normal questions like “What is the user problem you are trying to solve?” They would respond with, “Our design goal is ‘the map is the UI.’ You really need to spend more time with the other product managers.”

I was inclined to believe the Maps designers were idiots because “the map is the UI” is not a design goal and it doesn’t help users. But late into a whining rant over a bottle of white Côtes du Rhône, a designer friend of mine suggested a different story. “They’ve had no business goal,” she said. “Instead, they’ve been getting random complaints for years and since they’ve had no business goals, they’ve had to try to do your job on their own. They invented an organizing principle that could absorb all these tiny complaints from random VPs. And they may see you as just another one of those VPs.”

It’s not every day that your friends will give you brilliant insight, I know. But you can effect the same outcome, and save some bank on the vino, by saying, “OK, I’m telling myself the story that they’re idiots. I don’t actually have the IQ scores to back that up. Perhaps the story is that the former VP gave them a horrible objective, and they’re trying to live to it—in which case, it makes sense that they’re defending it.”

If you change the story you’re telling yourself about the other party, you can internally position yourself to have a more positive response to a conflict.

Now that you’ve convinced yourself that the guy you’re dealing with might not be an a-hole, you can get to the root of the problem. About 90% of the time, the root cause for your conflict is miscommunication. The other 10% of the time is divided between 1% genuine a-holes and 9% misaligned objectives.

All you really need to understand is that 90% of the time, you and your counterpart are “talking past each other.” In other words, you agree about the important things and are getting hung up on some detail or language problem. I find that engineers and engineering managers frequently focus on details when they really care about something much bigger, like not writing duplicate code, because it’s easier to be specific about a detail. By understanding that you’re most likely talking past each other, you can take a step back and ask yourself what the other party is really trying to say. This is the first major step.

Once you’ve established that you’re talking past each other, you can use that opportunity to establish a common vocabulary for the discussion so you can avoid miscommunication that results from language problems. To do this, you need to understand that engineers and teams frequently imbue certain words with special meaning. On one team a “hack” might be a horrible, dangerous thing, while on another team a “hack” might be a nice shortcut. Or, as I learned on the Maps team at Google, a common word like “landmark” might represent a whole class of things (restaurants, hotels, and the Eiffel Tower), rather than just the Eiffel Tower, which was referred to as an “attraction.” Such generalizations and naming conventions are de rigueur in software because that’s how software works—it operates on abstract objects and applies properties to make them specific. Therefore, it’s extremely common and entirely reasonable for teams to develop their own language.

Luckily, it’s simple to get past taxonomy problems. Say, “I’m sorry—so we’re on the same page, what are you referring to when you say ‘landmark’?” Engineering teams will be happy to explain because they love defining things. It’s one of the reasons why they write code.

If you are both using the same words with the same meaning, you may be “talking past each other” because one of you doesn’t understand the context of the conversation fully. Most of the nonengineers you work with are spread very thin across many projects. They do not necessarily know why you’re discussing a topic, and you don’t necessarily know why they are being a jerk. Take a step back and say, “I think we might be talking past each other.” Then get, or give, the context. For example:

This example reveals two critical and common contextual elements. First, time is always a challenge, and clearly articulating the time constraints will help the other person understand what is possible. Don’t believe me that time is a problem? Have a friend tie two moderately complicated knots. Then, you and another friend untie the knots while blindfolded and not speaking. Repeat this task but with a one-minute limit. The difference between the two experiences is remarkable, and you probably encountered some frustrating, nonverbal conflict because although it’s initially challenging to communicate while blindfolded and mute, everything gets worse under time pressure.

The second dimension that the example shows is that there are frequently assumptions that other people make or don’t know about. In this example, the design target is a blind user, and that user has different needs than a typical text-to-speech user. When you provide context to teammates, be sure to tease out these assumptions because they frequently lead to miscommunication.

On a related note, try to keep your project name the same throughout the life of the product, because if you change it, you’ll confuse the people who didn’t hear about the name change. If you’re in a tiny company, changing the name doesn’t matter, but it does in a big company. Renaming a project rarely delivers enough benefit to make dealing with the resulting miscommunication worthwhile. And it will increase your Excedrin bill.

When words are failing you, and your attempts to clarify them through taxonomy and context are also met with hostility and dismay, turn to the whiteboard. I always have a big whiteboard by my desk for this reason. I’ve found that pictures and lists drive clarity. By writing down what you’re talking about, the other party can focus on the pictures or the words on the board, rather than words in the air. This is a simple technique, but it’s remarkably powerful.

There are times, however, when conflict is not the result of explicit miscommunication or fundamentally divergent viewpoints. Sometimes conflict occurs when someone pokes you in a place you don’t like being poked. You’ll know when you get poked because you either want to slug the bastard or run away. You had a classic fight-or-flight response.

When someone pokes you in a way that triggers you, take a full minute to understand what just happened. Stall. Say, “Huh.” It takes 60 seconds for the initial bolus of adrenaline to be absorbed into your system after you’ve been poked, and 20 minutes for that adrenaline to be completely absorbed. Therefore, doing absolutely nothing but stalling for 60 seconds gives you time to avoid running from the room or from poking that person right back.

If you want to get better at coping with the strong emotional responses we all have, you need to identify what triggers such a response. Maybe people who use your childhood nickname upset you, or maybe engineers who question your technical judgment really get your goat. Regardless of what the specific trigger is, being aware that you were poked in a sensitive place will give you the handle you need to wrestle your reactions back into shape, and over time your sensitivity will decrease.

Even if you can manage your triggers, it’s clear that working on software is an intense business that will occasionally cause tempers to flare. Most people work longer-than-average days and care passionately about the work they produce. It’s not surprising that emotions are strong, and you’d best accept right now that you’re going to piss someone off, especially if you’re trying to ship. But you may be able to minimize the frequency with which you piss people off if you can depersonalize your conversations.

Depersonalizing conversations means making the discussion about the software, the user, or the problem—not about the humans involved in the conversation. There are some powerful techniques you can employ every day to help ensure that you depersonalize your discussions and increase the probability of a stressless outcome. My top three favorite depersonalization techniques are: