False Consensus
Engineering Insights
False Consensus is term I have coined that describes a situation where two parties believe that they are in agreement, but they are actually not.
Although this may seem paradoxical, it is, in fact, a fairly common occurrence.
False consensus usually happens when the two parties are in agreement in broad outline, but haven’t taken the time to go over the finer details. Later it is discovered that there are, indeed, fundamental disagreements about the proposed plan, but because these problems were discovered late they become very expensive to fix.
(Note: In Psychology there is something called the “False Consensus Effect”, which is a different phenomena than the one I have described. It refers to people’s tendency to think that their opinions and beliefs are typical.)
Here’s a fictional example of false consensus, loosely inspired by a few different real-life incidents:
The web server team for project X is having a meeting with the analytics team to discuss a plan for adding instrumentation for measuring page latency. This means that each time the web page loads, the JavaScript code will send a signal back to the metrics service saying how long it took to load the page.
The discussion covers the broad range of topics: how the data samples will be recorded, what client-side libraries will be used, what format will be used for records in the database, how the reports will be generated, where the real-time dashboards will appear.
Everyone is in agreement. Except for one thing: No one on the analytics team mentioned the fact that the analytics engine has a scaling limit of 100 million users — with their current architecture, they can’t handle more traffic than that. Surely, 100 million should be enough capacity for any conceivable project, right?
And no one on the project X web team mentioned the fact that their current traffic load is half a billion users.
This isn’t just a minor detail. It means that the entire agreement between the parties is now void. It means that project X can’t use that particular analytics solution at all. Instead, they are going to have to come up with a completely different solution, and all of the effort that has been spent so far to integrate the two solutions is now wasted work.
So how do you avoid this kind of situation? It’s difficult, but I have found a couple of things that can help:
First, you need someone on the team — preferably a senior engineer or analyst — who can immerse themselves in the details of both systems and look for points of contradiction, before work begins. As they say, “the Devil is in the details.”
Second, when it comes time for the two parties to meet, you have to go over every aspect of the agreement, making sure that both parties understand the ramifications of each point. You have to resist the temptation to end the meeting early and declare “mission accomplished”.
If you can do this well, you will save yourself and your company a lot of money.
