When Bad Things Happen to Good Concepts - Attack of the Consensus Blob

Skip, over at Random Thoughts of a CTO, asks is there a downside to collaboration?

"I face this kind of struggle in many of the decisions I need to be involved in as one of the key project stakeholders with every project. I don't want to hurt feelings, egos, etc...to the point that when I really need to hear from those people they choose not to participate. On the other hand, too many cooks can spoil the pot, and we must move on especially with minor decisions.

I am a firm believer that collaboration and communication is essential if you want to have a successful project. I also believe it is good if the team can agree on many of the decisions because they will be more motivated to make the project successful and they believe in the goals of the project.

So is my organization suffering from too much consensus, or is this just a challenge that comes with the many benefits of collaboration, communication, team building and consensus?"

I think the key insight in answering Skip’s question is understanding the difference between collaboration and consensus. The former connotes working together to solve a problem or accomplish a goal. The latter implies that everyone agrees with that solution – or at least stops agreeing vociferously.

Collaboration is vital to solving complex problems or accomplishing stretch goals. Rarely does one person have the person have the perspective to see all of the unintended consequences of their decisions. A team of people with a variety of viewpoints and experiences will provide a better context for evaluating potential options.

Good context definition leads to good decisions. Sadly, it’s easier said than done. Each of us has a hard time separating “What’s the right thing to do?” from “What’s in it for me?” Our brains trick our minds into thinking the two are identical. And of course, the answers to those questions are highly dynamic, changing according to circumstance and mood.

[Ponder the consequences of that last paragraph for a minute before proceeding.]

Skip, being a Chief Information Officer, has certainly participated in projects where the users, upon seeing the finished product, say “that isn’t what I wanted!” or “that’s nice, but what we really need is…”. Everyone in I.T. has had this happen, and I suspect that everyone who has ever been involved in a project of any sort has had this experience, for the reasons outlined above.

Experienced project managers know that the key to preventing this problem lies in defining requirements well up front. Good problem solvers know that the first thing they need to do to succeed is clearly define the problem in terms of what will be different when it is solved. How can you reach a goal if you don’t know how to tell if you’ve reached it (and consequently how far away you are now, and if the changes you’re considering are moving you closer or farther away)?

This is vitally important in collaborative work. Remember, our individual brains are constantly working to align “What is the right thing to do” to “What’s in it for me”. Mark Brady at Fouroboros discussed this topic (in a more eloquent way) in his post about leadership and innovation:

”Any breakthrough effort must set the context—provide its overarching relevance—in such a way that tinkering and hedging with its intent are viewed as blasphemous to the core effort and ambition. There is a very simple reason that this requirement must be in place—people get in their own way; their best intentions have the unintended consequence of diluting the power and the definition of high ROI opportunities.

People try and find ways to make themselves relevant. It’s human nature, but it can tend to undermine the essential nature of breakthrough creative efforts. Imagine a group you’ve sat in during the embryonic planning stages. Did you witness people referencing their previous “similar” experiences on such and such, or perhaps, find them (or yourself) translating past work into future potential skill on the particular project under discussion?

Were they analogizing links to stuff they’d done in the past? Did folks wheel out ideas and “tweaks” that seemed, at least to some ears, to be tone deaf to the declared mission and ambition?

That’s because their minds are tenaciously looking to make connections between the idea and themselves, not between the idea and its ultimate benefactors. In many cases, we set to ‘flesh out’ a concept and end up, not growing it, but rather binding its feet

So maybe here's where group identity overcomes--okay, tramples--adherence to the idea. Belonging to the project becomes just as important (truthfully, often more important) as the intent of the project itself. In this way, unknowingly, we often nibble away at the original idea, at its power and purity, in order to maintain our connection to it. Our fanatical adherence to a noble and aggrandizing principle suddenly wanes because its realization and the execution may not need us. And it sucks to learn the future can, and sometimes must, happen without us. In this way, our ideas “abandon” us. Like baby birds, they flee the nest and fly.”

So what can you do to prevent a group from sabotaging itself? Mark again:

"If I have an intrinsically motivated goal that I must match/steer towards that all have previously agreed upon, then it precludes arguments down in the weeds. Take Mazda. When they design an exhaust system, or lots of things, they use Kansei as their pole star. It must feel right and sound right to the ear. It is Don Norman's emotional design, except 250 years older. I don't know if this is what the IT guy is referring to, but Mazda creates psychological markers (as do we) to go along with the physical benchmarks. And, the pyschological always holds sway. That is the final estimation and evaluation of a product or effort, so it must as they see it.

If people are arguing minutiae or turf, the effects must measured in terms of contribution to or detraction from the agreed upon Kansei goal. I know this helps me from time to time because it's often folks jockeying for "relevance" within a certain design or effort. Asking them to assess the impact of following their suggested course's impact on their earlier claimed goal of creating sensation or experience X slows them down and sometimes quells the inertia completely. It takes balls for mgmt to do this, but it works if you work it. Hard to argue a metaphysical truth you yourself have affirmed as righteous, even if it's as basic as "sounds like the Mustang in Bullitt."

[Sometimes those marketing folks' metaphors sail right over my head]


Good Consensus vs. Bad Consensus

Remember, the original intent of consensus was to provide an integrity / ecology check of a proposed decision. Does everyone agree that the proposal meets the goals without creating significant undesired effects? This works great when everyone’s playing nice. But that doesn’t always happen. People do jockey for relevance and redefine “what’s right” as “what’s in it for me”. The search for consensus then turns from focusing on the goal to focusing on what needs to be done to placate the recalcitrant group members.

Admit it. You’ve seen it happen. You’ve done it, too. You threw someone a bone, figuring they’d get with the program if they “had skin in the game”. And sometimes it works. But not always, and the placated often find ways to subvert their consent. I think Aristotle said it best:


The Role of Consensus in Change Management

That’s not to say consensus-building doesn’t have an important and legitimate role in getting people on board with a decision. Change management guru Robert Gleason is fond of saying

“People don’t resist change itself, they resist someone obscuring their rules for success.”

If your group has a common bond of trust, you don’t have to worry about this. People know that you’ll figure out the new rules together, sooner or later.

But if your group doesn’t have innate trust, group members are going to need know the new rules before they consent to the change. This is an important opportunity and obligation for the team. An opportunity because the changes likely effect more than just the team members, and the reluctant team members represent a number of their colleagues. If the team understands how to communicate the new rules for success to respective team members, they can use can communicate those same new rules to the larger population. Even better, they can have the team members – who have a bond of trust with their colleagues – communicate the new rules!

An obligation, because if you don’t work out the new rules with your team members, they’ll make up new ones on their own, and you may not like the results. Even worse, each effected person will make up their own dynamic set of rules, which probably conflict with everyone else’s rules, according to circumstance and mood. You’ve seen it happen, haven’t you?

And that’s why working out the new rules for success in the context of, and without subverting, the goal is crucial to ultimate success. And that’s why change management gurus get big bucks for facilitating big changes.



So, Skip, in judging how much consensus-building is appropriate in any situation, ask yourself these two questions:

1. How much inquiry is needed to insure the integrity of our solution?
2. How will we insure that effected parties understand their new rules for success resulting from the solution?

[h/t to Rob for the original link to Skip's post]