ManagementSpeak: You are empowered to make decisions on your own.
Translation: I expect you to figure out what I want you to do, and do it, even if I don’t know what I want you to do.
KJR Club member Chris Keating knew what I wanted him to do (and you, too!): Submit a great examples of ManagementSpeak.
Year: 2006
The consensus trap
As I get older, science fiction seems to have less science, which is too bad. Science is the hard work of figuring out how the universe works. It’s been replaced with swords and sorcery, which is simply wishful thinking, and as David Brin has pointed out, part of “wishful” is the assumption that in a feudal society you’d end up as something other than one of the peons who made up 90% of the population.
And so, while I wait for the next Discworld novel to appear each year, I’ve been reading more history. Regrettably, not quite enough, as several subscribers pointed out in response to last week’s column: Well before the Revolutionary War, England largely rejected the idea of the divine right of kings, replacing it with the inherent right of the aristocracy. Not that this was much better, nor do I know whether the English of the time claimed God wanted those with titles to be entitled.
People being what they are, I’d bet that they did.
Much of the rest of my correspondence had to do with the role of consensus in corporate decision-making. One source told me that a number of large corporations teach decision-making in their leadership training programs. Their programs (which, unlike the leadership seminars we provide, apparently require lexicographical activism) define both consensus and collaboration as conflict resolution processes, and then explain that consensus is bad while collaboration is good.
And if I define black as a shade of lavender, and white as a shade of tan, I can easily make the case that white suits make a better fashion statement for male business executives than black ones. “Collaborate” is widely understood (and defined in dictionaries) to refer to all situations in which people work together in a cooperative fashion. It’s a process. Not only is it not limited to conflict resolution, but it’s unlikely to resolve serious conflicts, since serious conflicts generally arise when people lose their ability to cooperate.
Consensus isn’t a process. It’s a result — general agreement, or more formally, a state of being in which everyone involved agrees to support a decision, regardless of what they personally would consider to have been ideal. The best consensus decisions start with collaboration, but collaboration isn’t required.
What is required is a shared desire to find some way to move forward.
Consensus isn’t the only way to make business decisions. It isn’t suited to all situations, or even most situations. It’s time-consuming, and is in consequence expensive. For engineering situations it’s risky, because the process of compromise required for consensus easily leads to design inconsistencies, and those, in turn, lead to kludges, deep in the heart of the architecture.
Use consensus when what matters, more than anything else, is buy-in — commitment to the course of action chosen by the organization. Use other methods for other circumstances.
Take product design as an example. A very good way to design products is to put a product manager in charge of a small team, consisting of experts from marketing, design, engineering, manufacturing, and cost-accounting. This gives you your best shot at creating a well-built product that’s easy to manufacture and appealing to customers.
Except that it’s never that easy. The most marketable product might be hard to manufacture. The best engineering might have too little market appeal, or be too hard to manufacture as well. What’s easiest to manufacture could require the elimination of highly desirable product features.
And what everyone else wants to build might end up costing too much, thinning margins to unacceptable levels.
Every member of the design team will have to make … that’s right … compromises. Which means that with all the best of intentions, your attempt to avoid the expense of consensus has simply shifted the responsibility for arriving at consensus to a different group of people. You don’t seriously think that having everyone make their case to the product manager, who then makes all of the decisions, will work, do you?
So here’s your guideline when it comes to design decisions of any kind: Unless one person knows enough to design the entire entity, whatever it is, charter a design team. Keep it small — no more than five people; three is better. Choose people who already know and trust each other’s judgment. Failing that, choose people who you know can work well with others.
Who can, that is, collaborate to arrive at consensus.