It seems only natural that we are our most confident when talking about subjects we know a thing or two about.
As a programmer, you might find joy and passion to talk about the latest paradigm you’ve learned, or new GNU/Linux utilities, or a hack you managed to do to patch up a production-line halting bug.
If, on the other hand, you’re asked to provide your opinion on an ongoing issue that the marketing team is confronted with, then, it’s normal to feel jittery and to say that it’s out of your circle of competence.
And that’s to be expected. But what happens when this overt sincerity is downplayed in favor of appearing knowledgeable?
Well, you run around in circles in meetings, you present yourself as somebody else, and overall you get yourself in trouble in the long run, as you sweep under the rug of assumed knowledge all the things you don’t know but present as known.
This is known as the bike-shed effect, also known as Parkinson’s Law of Triviality.
What is the bike shed-effect?
Coined by Cyril Northcote Parkinson in the 1950s, he used what would become known as the famous “bike-shed” example to explain the phenomenon.
Basically, a committee decides to meet in order to discuss three issues:
- A proposal for a £10 million nuclear power plant
- A proposal for a £350 bike shed
- A proposal for a £21 annual coffee budget
They start in order, by first talking about the nuclear power plant.
Being that nobody is even marginally knowledgeable about what to look for in a nuclear power plant, let alone choosing the best option for one, they quickly skim over the issue.
“Let’s move on to the bike shed proposal”
Next, they turn to the bike shed proposal. Since most people know what a bike shed is, most people are able to chip in with an opinion on it, spending significantly more time on this issue than the previous one.
Lastly, they get around to talk about the annual coffee budget. Everybody knows what coffee is, so everybody expresses their opinion on the matter, analyzing the issue to such a degree that even some quick napkin-math is done to provide examples.
The coffee issue has thus consumed the largest amount of time of the meeting.
Not only this, but the meeting has provided the committee members with a (justifiable?) sense of accomplishment, since they managed to express opinions and to (allegedly) move forward with these issues.
Even to the detriment of spending the least amount of time on the most pressing issue, the nuclear power plant.
As we mentioned in the beginning of the article, this is because we tend to (sometimes unconsciously) keep to our circle of competence, meaning that we gravitate towards talking about subjects we know.
We could even assume that the bike-shedding effect is directly proportional to our lack of knowledge on a specific topic.
And probably there are other factors too, such as ego protection and trying to maintain a perpetually knowledgeable version of yourself in the eyes of others.
We all do this, mostly unconsciously, and for those of us who managed to notice this behavior, there are ways to circumvent it.
How to rid yourself of the bike-shed effect?
Our first piece of advice is to have a clear enough itinerary for your meeting, and to try and detail the issues as much as you can.
Sure, you might not be able to do it without the help of an expert in the field or there might even be unexpected topics that will pop-up during the meeting.
This doesn’t mean that you shouldn’t reach an expert or try to cover as much as you can, even if that means writing down further questions and not answers.
It’s important to not make perfect the enemy of the good.
So, instead of writing just “A proposal for a £10 million nuclear power plant”, have an underlying list that asks questions on the technology used, timeline, manpower, legal factors, etc., trying to break it down into smaller, answerable parts. Divide and conquer.
Also, it’s important to arrange your committee in such a way that there is no one person that isn’t knowledgeable in at least one of the topics discussed.
This means that not only will nobody feel useless, but that every area of your subjects will be covered.
There can also be a designated “captain” of the meeting that is able to step back and steer the mast clear of unnecessary conversations.
As clients and product owners, we focus too much on where a specific button should be placed instead of revising our faulty business model.
As programmers and designers, we spend too much time tinkering with the perfect tool-set instead of actually getting hard stuff done.
As project managers, business analysts and marketing people, we try to feel as comfortable as we can, trying to pull new experiences and new information to our circle of competence, instead of trying our best to expand the circle and mold ourselves after the information, not the other way around.
Overall, let this article be a wake up call for all of us who spend too much time on the trivial parts, and not enough time on the hard and truly valuable stuff.