Different thought patterns can lead to different results by the same person. We may get stuck with our interpretation of a situation or circumstances just out of habit. Similar negative pattern matching can also happen in group environments where, for example, the work culture has adopted a negative thought process - a time-wasting workflow.
One of these is the never-ending vortex of “it depends”. I call it the grey area bias. The remedy is a process of determining threshold variables, that pivot decision making.
Let’s backtrack for some context first - why the name grey area bias?
A bias is a mental error of disproportionately overweighing one side of an observation or an argument. For example, with slot machines one might give a great emphasis to a winning while ignoring several small losses.
Black-and-white thinking is considering options in a binary fashion. For example, thinking in terms of good, bad, and nothing in between is black-and-white - two-sided - binary. It’s also called all-or-nothing thinking.
Grey area thinking alleviates black-and-white thinking by considering gradient stages in between the two margins. It’s a beneficial pattern to learn, if one is hampered by compulsive binary thinking.
Despite the benefits, grey area thinking can still lead to problems in a group setting. For example, it can lead to indecision when reconsidering ad finitum the various aspects of a problem or a task. And indecision can be costly. If the discussion in a meeting keeps oscillating between options for a prolonged duration - “on the other hand… though it depends…” - that’s my cue for considering threshold variables. Those define the tipping points for choosing different options instead of trying to find a silver bullet.
Instead of thinking about different sides of an ordeal, for example, if I should work around the graphics framework, or rewrite pieces of it from scratch, I switch to thinking about what the deciding factors are that lead to those options. I might consider what’s my budget for the work, and what else am I supposed to complete. Are the refactorred snippets leaf-components, or do they form the base dependencies for the rest of the framework - in which case they might lead to bugs along the software’s life cycle. What is acceptable in means of wasted time and effort dealing with the system - how fast could the developer experience be ideally - and how low should the lower-bound be, to have an impact to overall efficiency.
If a meeting loops on with people commenting on how contrary options would be beneficial, it’s more helpful to turn the question on its head: what are the tipping points for either option? Is it volume, robustness, resources? What is the context in which option A is an obvious choice and option B is non-sensical - and in what context would option B be more fitting?
Challenging the views with this probing percolates the actionable threshold at which point the options would fade their shade of grey. It makes decision points stand out.
I write about things I’ve learned to work. The tongue-in-cheek names I give them serve as mnemonics and help to remember - not to illusion myself with false grandiosity while coining laws or common statements. I might stop calling it the grey area bias when I find that someone has come up with a better name for it.