Cognitive bias series #3: Avoiding trivial product decisions
What’s easier to discuss: the pros and cons of using an atomic reactor, or choosing the colour of a bikeshed? This is the example used by writer C Northcote Parkinson when explaining his Law of Triviality, which is the tendency for us humans to spend more time discussing easy, or trivial, matters over more important ones. In Parkinson’s anecdote, a committee spends more time discussing the colour of the bike shed because everyone can have an opinion as it’s easy to understand.
We’ve been looking at cognitive biases in the workplace in our latest series, and the Law of Triviality probably hits closest to home in terms of biases I find myself needing to manage.
I head up the 7-strong developer team in charge of product development for both Wisembly and its sister platform, Solid. We’ve been really lucky to have found super talented devs who are exceptional at what they do, and the products we’ve built together speak to this.
But over the years I’ve found that developers tend to have 2 reactions when faced with complex issues:
1) They focus on small details in the code that they can easily optimise rather than look at the bigger picture, i.e. they bug patch rather than try to fix the root problem.
2) They suggest a change of framework or language, pointing at specific characteristics of the new framework that would solve our problems.
We had an example of the latter recently when trying to improve our note-taking capabilities for Solid. Now, the note-taking system was one of the first things we built when we started developing the product, and we’d chosen to use a Javascript framework called Ember. Fast-forward 2 years, and we were hitting a stonewall that encouraged many of our team to look to another framework, React, as the be-all and end-all to our note-taking issues.
While switching to React may have solved many of the problems we ran into, we also had to consider that making the switch would likely have brought it’s own set of issues. There’s such a huge unknown when changing frameworks, and ultimately any issues you run into are because of how the product was built and coded in the first place: changing frameworks is just a neat way of avoiding the real issue. This is the case even when you have an ageing framework, as no matter how old the framework there should be no need to change if you have made good architectural decisions to start with.
I’ve learned over the years is that it’s very easy to get sidetracked and expend a lot of time and effort on trivial matters, which ultimately don’t fix the problem and may bring their own set of unintended consequences in the future. I’d encourage other product owners or team managers to look at cases where this has happened, and identify what set of circumstances brought about the decision that was made so that they too can manage them better in future!
Comments