Trends

A Case of Mistaken Identities

Cautionary Tales Against the Dangers of Perception Fallacy

By Paul Tibbert, CEO of GRID

Don Quixote didn’t believe he was tilting at windmills. He thought he was reviving chivalry and fighting a noble fight befitting a gallant knight in the honor of damsels in distress and for the good of a people. But just because he was choosing the battle of his own wishing, that did not make it the reality. 

We see this same dynamic at play in the modern business world, where leadership and management choose their battles — unwisely, at times — out of expediency or a preference to “dance with the devil you know,” as it is said. What ends up at risk is that the true dragon never gets slayed, and resources are diverted toward well-meaning but errant initiatives. Not only do problems persist; so too do their costs continue to pile up, while money and labor get spent in the wrong places and to the wrong ends.

If it feels like you may have people tilting at windmills in your organization, it’s important to realign your infantry so as to avoid the tragic ending of Cervantes’ epic saga — a cautionary tale as old as time.

Lesson #1: The “Two Toms” Fallacy

You have two friends, both named Tom. Obviously, it would be foolish to assume that these two people are the same, right? On a very superficial level, yes, they are similar. Both men. Both named Tom. Both have two eyes, a nose, and a mouth. Both are humans; perhaps they both speak English natively; perhaps they are even the same age.

But think of two Toms in your own life — such different people, yes? They don’t have the same job; they don’t have the same family; they don’t have the same genetic DNA; they don’t even talk the same. 

Yet it is not unheard of to see companies and individuals live out this perception fallacy, despite the obvious category errors and to undesirable ends.

Example: A developer finds some redundancy in programming code. The two instances are executing the same logical commands — two programs doing the same thing. If they were two identical “Toms,” one could be eliminated, and a simple update allows both sections of code to reference the same logical function, thereby eliminating redundancy and avoiding bugs with the logic drifting over time when changes are applied in one spot but not the other. The code is neater and lighter, and now the entire system is better off for it, right? Not so fast…

By way of illustration, let’s say this developer finds code that automatically adds six percent state sales tax to every transaction. 

One piece of code originated to account for Michigan sales tax, and the other to calculate Ohio sales tax. For the moment, this code appears to be redundant. If you were to eliminate one — delete it to have one, simpler section of code to achieve both ends — what happens when either Ohio or Michigan enacts a change to its sales tax? Suddenly, what looked like a redundancy reveals itself to be two discrete Toms, each serving its own discrete end.

Just because there are two Toms, it doesn’t necessarily mean that there are two instances of the same thing/issue/problem. Start from that premise, and you will have installed internal guardrails against a common perception fallacy that could be surreptitiously costing your money and competitive advantage.

Lesson #2: The “This is That” Fallacy

Where companies also go tilting at windmills is when they enact wishful thinking to force one tool to serve multiple purposes, despite the reality that the tool was never intended to serve in a capacity outside of its primary utility. 

You’ve heard the expression, “If the only tool you have is a hammer, you tend to see every problem as a nail.” This is a famous quote attributed to American psychologist Abraham Maslow and one commonly used to illustrate another common perception fallacy.

The hidden danger is not only that hammers do a terrible job of screwing in screws; it’s the fact that it’s costing you more to have poorly affixed screws than it would be to invest in both a hammer and a screwdriver.

Allow me to provide a common illustration: Consider software like Salesforce, Basecamp, or Hubspot. Even something as simple as Slack. Slack can be a remarkable hammer, if all you have to do is pound in proverbial nails with it. Where I find issues is when I see organizations trying to turn the Slacks of the world — single-purpose hammers — into a screwdriver, monkey wrench and handsaw all at once. The same goes for “all”-purpose tools, like the aforementioned Salesforce-s of the world. Because an investment has been made in one tool, there arises the temptation to configure that tool to perform a whole host of seemingly ancillary (but actually disparate) tasks, perhaps in order to maximize the investment made.

There is no question that Slack far surpasses email as a collaborative communication platform across an enterprise. But too often, I’ve seen instances in which teams will start to use Slack as much more than a communication tool, but also as a file server, a joint calendar, a project management solution, a conferencing platform, and more. 

There are much better alternatives for each of these discrete needs; and they can all be easily integrated. But by force feeding one solution as a do-everything cure-all, the team ultimately settles for suboptimal solutions across many day-to-day functions, all because of some sense of expediency, cost savings or misconstrued convenience.

If this sort of thing is happening with something as simple as Slack, imagine the dangers of the “This Is That” fallacy embedded throughout an entire organization, forcing the suboptimal on teams with little cost savings and next to no benefit as a result!

This is not that; and we shouldn’t allow ourselves to succumb to complacency when operating in such highly competitive times and industries.

The Case for a Happier Ending to the Story

What I am advocating for as an antidote to these common perception fallacies is simple: Take the time and spend the little extra effort required to address every challenge as its own unique problem to solve. Don’t settle for the easy way out (“Let’s eliminate one of the Toms!”) or give prejudicial preference to the convenient (“Slack can do pretty much everything!”), when you can and should solve problems creatively and optimize processes strategically.

Life presents perception fallacies at every turn, as does the business world. In the worst-case scenario, the pursuit of such windmills jeopardizes corporate missions and balance sheets — in very common instances it results in under-motivated or mis-motivated teams and personnel.

Don Quixote was a work of fiction. It has stood the test of time, in part, because it speaks to universal truths. But whether history repeats itself inside your organization is an ending to the cautionary tale that you, yourself, gets to write. 

 

The Reality of Artificial Intelligence

Knowing When AI is the Right Tool…and When it Isn’t By Paul Tibbert, CEO of GRID “By far, the greatest danger of artificial intelligence is that people conclude too early that they understand it.” — Eliezer Yudkowsky, artificial intelligence theorist Artificial intelligence, or AI, is perhaps one of the most discussed, broadly embraced and eagerly adopted disciplines in all of…

Read more

Corporate Departments: Siloed, Solo or Solidly Embedded?

Rethinking the “All Silos are Bad” Article of Faith By Paul Tibbert, CEO of GRID Maybe silos aren’t so bad after all. In the business world, the word “silo” has received (perhaps earned) a bad reputation. The notion that organizational departments get entrenched in their own priorities and their own objectives at the expense of the greater good for the…

Read more

Feast Nor Famine

A Better Way to Manage Projects, Develop Teams, and Nurture Expertise By Paul Tibbert, CEO of GRID Hurry up and wait. Feast or famine. All or nothing. I doubt that many would advocate an on/off approach to resource allocation in the business world. However, the recent turn of a new calendar year brought with it a surprising number of conversations…

Read more
Copyright 2017, Grid LLC Technology + Design