Consensus vs. Collaboration

While mostly I focus on the techniques and best practices for creating great products, I have truly come to appreciate just how important culture is in contributing to great products.  By culture I am including both company culture as well as the cultures of the people working at the company.

I plan to write more on this general topic, but today I wanted to focus on what I think is one of the most common cultural problems at product companies.

Many companies pride themselves on being a “consensus culture.”  And of course if I had the choice between everybody on the team excited and supportive of something versus not having everyone excited and supportive, holding everything else constant, I would certainly rather have everyone on board.

However, in practice that is not the choice I find.  In consensus cultures people are rarely excited or supportive.  Mostly because they are very frustrated at how slow things move, how risk-averse the company is, how hard it is to make a decision, and especially how unimpressive the products are.

In my experience, the leaders in these consensus culture companies usually have their hearts in the right place, and they are working hard to create a culture of inclusiveness, where people feel heard, and teams work together towards a greater good.  They don’t understand how this worked so well when they were a small startup, and they have tried so hard to retain this culture as they grew, and they are reluctant to let go of this key aspect of their corporate identity.

My view is that these companies are confusing consensus with collaboration.

Seth Godin has a great line: “nothing is what happens when everyone has to agree.”  And of course it’s very easy for this to turn into design by committee (see www.svpg.com/avoiding-design-by-committee).

Many things really are easier to do in a small startup.  When you only have a few people in your company, then consensus and collaboration aren’t really so different.

While consensus is a nice to have, we absolutely need collaboration.  Great products are a fusion of customer value or functionality, usability and design, and technology.    We must work together closely to come up with solutions that satisfy all three of these dimensions.

Working closely certainly means communicating effectively, arguing viewpoints passionately, and negotiating trade-offs.  But it does not mean that everyone has to agree.

We also want to ensure we have a culture where anyone in the company that has information that could be helpful to the product team feels that it is not only okay to approach the product team with that information, but that it’s their responsibility to do so.

There are entire methodologies, like RACI, that exist to make very clear to everyone what their role is in any given decision.  Are they someone that is responsible for doing the work?  Are they the person that is ultimately responsible for approving the decision?  Do they have veto power?  Are they there to be consulted with when necessary?  Or are they just meant to be informed of the decision?

I am an advocate of RACI for companies that are trying to change their culture, but I always think it’s a bit sad when companies have to resort to this.

Even within the core team (product manager, lead designer, lead engineer), they should absolutely strive for agreement on key decisions, but it’s still not consensus.  Each has their area of decision authority, but when there are trade-offs among the areas, the product manager is the person ultimately responsible for the call.

The most common source of conflict I see is a trade-off between user experience and time-to-market.  Typically all parties agree which is better, and also which is more expensive in terms of time, so then the team has to decide if the incremental benefit is worth the incremental cost.  There is no blanket answer to this.  Hopefully the core team agrees on the best decision, but sometimes they won’t, so that’s where you need someone to consider the options and make the call.

In some cultures, this results in an escalation to senior management, and they make the call.  The disadvantage to this is that the product owner may come away feeling disempowered and might no longer be willing to take responsibility for the outcome.

In my experience, if people don’t feel like they can be heard by the product team when they believe they have something to say, that’s a real problem.  However, as long as people feel heard, they understand that they won’t always agree with the decisions, and further they understand that there may be other considerations beyond what they can see.

And any lack of control at losing the power to veto something because they don’t agree is more than offset by the realization that while everyone should be able to have input on what they are working on, consensus is not required for them either.

Finally, I realize that consensus and collaboration are not the only two cultures out there.  In quite a few companies, it’s really a culture where all important decisions are driven by one or two people, or there are cultures where the developers rule.  We’ll be talking about the strengths and limitations of those approaches as well.