3   Criticize Ideas, Not People

“You have a lot invested in your design. You’ve put your heart and soul into it. You know it’s better than anyone else’s. Don’t even bother listening to their ideas; they’ll just confuse the issue.”

You’ve probably seen design discussions that get out of hand and become emotionally charged—decisions get made based on whose idea it was, not on the merits of the ideas themselves. We’ve been in meetings like that, and they aren’t pleasant.

But it’s only natural. When Lee presents a new design, it’s easiest to say, “That’s stupid” (with the clear implication that Lee is stupid as well). It takes a little more effort to elaborate, “That’s stupid; you forgot to make it thread-safe.” And it actually takes real effort and thought to say the far more appropriate, “Thanks, Lee. But I’m curious, what will happen when two users log on at the same time?”

See the difference? Let’s look at common responses to an obvious error:

• Dismiss the person as incompetent.

• Dismiss the idea by pointing out the obvious flaw.

• Ask your teammate to address your concern.

The first choice is a nonstarter. Even if Lee is a complete bozo and couldn’t program his way out of a paper bag, pointing that out isn’t going to advance his education any and will likely dissuade Lee from offering any more ideas in the future. Choice two is at least more focused, but it doesn’t help Lee that much and could well backfire on you. Lee may well respond to the accusation of unsafe threading with something clever: “Oh, it doesn’t need to be multithreaded. Because this is executing in the context of the Frozbot module, it’s already running in its own thread.” Ouch. Forgot about that Frozbot thing. Now you feel stupid, and Lee is annoyed that you thought he was a bozo.

That leaves choice three. No accusation, no judgment, just a simple clarification. It lets Lee identify the problem himself, instead of having it thrown in his face.^[3] It’s the start of a conversation, not an argument.

Venkat says:

Keep It Professional, Not Personal

Years ago, on my first day on the job as a system administrator, a senior admin and I were working on installing some software. I accidentally pushed a button bringing down the server. Within seconds, several frustrated users were knocking on the door.

My mentor earned my trust and respect when—instead of pointing fingers—he said, “Sorry, we’re trying to find what went wrong. The system should be up in a few minutes.” I learned an important and unforgettable lesson.

In the tight confines of a development team, that small amount of politeness and courtesy goes a long way to help keep the team focused on the pure merits of an idea, not on distractions of personal politics. We all are capable of generating excellent, innovative ideas, and we are all equally capable of proposing some real turkeys.

If there’s a substantial risk that your idea will be ridiculed or that you’ll lose face for suggesting it, you won’t be inclined to offer another suggestion. Ever. And that’s a real problem: a good software development effort, and a good design, requires a lot of creativity and insight. The whole project benefits when people with different ideas and concerns share and merge those ideas into something larger than any individual contributor could offer.

Negative comments and attitudes kill innovation. Now, we’re not suggesting that you and your team should hold hands and sing “Kumbaya” during your design meetings. It would slow the meeting down, for one thing. But you need to keep your focus on solving problems rather than trying to prove whose idea is better. Having only one highly talented person on a team is merely ineffective, but it’s much worse to have a few clashing heads who refuse to work together. Productivity and innovation quickly dies on those teams.

We all have some good ideas and some bad ideas, and everyone on the team needs to feel free to express them. Even if your idea is not fully taken up, it may help shape the solution. Don’t be afraid of being criticized. Remember, everyone who became an expert started somewhere. In the words of Les Brown, “You don’t have to be great to get started, but you have to get started to be great.”

Here are some particular techniques that can help:

Set a deadline.

If you’re having a design meeting, or are just having trouble getting to a solution, set a hard deadline such as lunchtime or the end of the day. That kind of time boxing helps keep the team moving and keeps you from getting too hung up on an endless ideological debate. And try to be (dare we say) pragmatic about it: there may not be a best answer, just a more suitable solution. A deadline helps you make the hard choices so you can move on.

Argue the opposite.

Each member of the team should realize that there are always trade-offs involved. One way to be objective about an issue is to argue enthusiastically for it—and then passionately against it.^[4] The goal is to pick a solution that has the most pros and the fewest cons, and this is a good way to collect as many pros and cons as you can. It also helps take some of the emotion out of the process.

Use a mediator.

At the start of a meeting, pick a mediator who will act as the decision maker for that session. Each person should be given an opportunity to present ideas and opinions on various aspects of the problem. The mediator is there to make sure everyone gets a chance to be heard and to keep the meeting moving forward. The mediator can prevent prima donnas from dominating the meeting and can step in to remedy thoughtless remarks.

It’s easiest to step back and monitor the meeting when you aren’t actively participating in the discussion itself, so the mediator should concentrate on mediating, not contributing ideas (and ideally shouldn’t have a vested interest in the project’s timeline). And of course, while technical skills aren’t strictly required for this task, people skills are.

Support the decision.

Once a solution is picked (by whatever means), each team member should switch gears and give their complete cooperation in seeing it through to implementation. Everyone has to keep in mind that the goal is to get the project working to meet your customers’ needs. It doesn’t matter to the customer whose idea it was—they care only that the application works and that it meets their expectations. It’s the outcome that counts.

Design (and life, for that matter) is full of compromises. A winning team is the one that realizes this fact. Working together with the team unemotionally takes effort, but exhibiting such maturity among your team members won’t go unnoticed. This is an area where leading by example pays off—the practice is contagious.

Criticize ideas, not people. Take pride in arriving at a solution rather than proving whose idea is better.

What It Feels Like

It feels comfortable when the team discusses the genuine merits and possible drawbacks of several candidate solutions. You can reject solutions that have too many drawbacks without hurt feelings, and imperfect (but still better) solutions can be adopted without guilt.

Keeping Your Balance

• Always try to contribute a good idea, but don’t be upset if your ideas don’t make it into the product. Don’t add extra cruft to an existing good idea just to add your own input.

• The real debate usually ends up on how realistic the negative points are. It’s easy to slam an idea you’re biased against by raising negatives that might not ever happen or that aren’t realistic. If this starts happening, ask whether the problem has ever happened before and how often it came up.

  In other words, it’s not enough to say, “We can’t adopt that strategy because the database vendor may go out of business,” or “The users would never accept that idea.” You have to also assess just how likely that scenario really is. If you have to prototype or research to back up or refute a position, do so.

• Before setting out to find the best solution, it might be a good idea to make sure everyone agrees on what best means in this context. The best thing for developers may not be the best for users, and vice versa.

• There is no absolute best, only better. Despite the popularity of the term, there is no such thing as “best practices,” only better practices in a particular situation.

• Being unemotional does not mean you blindly accept any and all ideas presented. Choose the right words and reasons to explain why you can’t see the merits of an idea or solution, and ask clarifying questions.