The Cult of Complexity and the TIDOR Syndrome
The Cult of Complexity has spawned many sects over the years, ranging from the forgivably ignorant to the damnably intentional. I’ll begin with the least sinister of these – companies whose cultures are so technology-obsessed that they simply cannot see the complexity they are foisting upon their customers.
Shortly after launching my simplicity crusade at HP, I found myself in a meeting with the vice president for the workstation business and I asked him what his priorities were for the coming year. He told me he had three of them.
“Number one…Performance!” he said boldly.
This made sense. In the workstation business, you won sales by having the fastest machine on the market, the highest throughput rating.
Uh-oh. Trouble ahead.
Let me guess….
I politely suggested that there might be room for one more objective, even if it might run a distant fourth to his beloved “performance.”
“No!” he said with a wave of his hand. “There are no more.” I had to give him credit for embracing simplicity in his business objectives, at least.
In technology-dominated cultures, ambiguity is not a problem. Performance! Functionality! Features! Technology! That’s all that matters. In such cultures, complexity is invisible; customers are mere abstractions. The power centers of the company simply do not recognize that their products are hard to use because they assume everyone who uses their products is just like them. They are scientists and engineers, their customers are scientists and engineers, and if they don’t have a problem with the design, then surely their customers won’t either.
It’s not that complexity is intentional. Engineers don’t come into work each morning thinking, “now how can I make this product even harder to use.” They just can’t help it. Their competence has mutated into a disease.
Every employee of a technology-oriented company – whether they work in marketing, engineering, customer service, design, or manufacturing – is highly susceptible to a disease of perception called the TIDOR Syndrome: Technology-Induced Delusions Of Relevance. The more familiar you are with technology, the easier it is to convince yourself that everything related to that technology is relevant and necessary and must be understood before that technology can be used.
Over time, everyone in the company develops these delusions of relevance, and this mindset removes any considerations for making the product simpler or easier to use. TIDOR-infected companies don’t intentionally build complexity into their products – they literally cannot see it. To them, complexity is relevant, something that everyone who uses the technology must understand, wants to understand, and probably already does understand.
For example, long before there was an Internet as we know it today, there were bulletin board services like that allowed people to post messages and share information. Getting connected to these services through your modem was quite a chore. You can see remnants of this complexity by looking at the configuration settings for the HyperTerminal application that is included with Microsoft Windows.
In these good old days, you had to configure these settings to match the data communication protocols supported by your modem. Most of these settings – like the number of data bits and stop bits – are vestiges from obsolete Teletype machines, but if you didn’t know the correct setting to use, you were doomed to spend many frustrating hours searching for the right combination of parameters that would allow you to connect to your online service provider.
Modern modems are now considerably smarter, making all of these arcane configuration settings unnecessary, but back in the 1980s, data communications engineers would argue that knowing the baud rate of your modem and understanding Xon/Xoff flow control were absolutely relevant to the online experience. Suggesting otherwise would garner looks of disbelief and condescending comments about your lack of technical understanding.
“Of course it’s relevant!” they would exclaim. “How can you possibly expect to go online without knowing whether parity type and protocol setting?” And then they would wink and grin at other members of the club at your profound naiveté.
Trying to explain that the “user” for this product is an accountant who could care less about how his computer and the remote computer talk to each other falls on deaf ears. If you wanted to use a computer, you had to be computer literate in addition to being a CPA. Those were the rules – take it or leave it.
When complexity is revealed to those suffering from the TIDOR Syndrome, the response can be vigorous denial. After watching users struggle through usability tests, exposing for the first time the sharp-edges of technology that prevent real users from getting results from the product, many engineers blame the test subjects for the problem.
“That’s not a representative user!” exclaims employee #1.
“Our customers are smarter than that!” declares employee #2.
“Where did you find these morons?” hoots employee #3.
Such are the comments I’ve heard from engineers, marketers, and even user experience specialists while observing usability tests. Product teams gather in meetings to watch the foibles of representative users as they try in vain to use the product to achieve a critical result. Instead of evoking sober humiliation at their failure to understand and satisfy the customer, the team erupts in self-righteous laughter.
“If that guy’s one of our users, we need to find a better quality of customer!” Everyone nods in agreement, a certain sign that the TIDOR Syndrome pervades the company’s culture.
Because technology is second nature to product team, requirements foisted upon users may seem perfectly natural to them, which explains why it may seem perfectly reasonable to require customers to memorize an awkward sequence of buttons to press when setting the time on their clocks, or enter data communication parameters before they can send an email message.
Because of technology-induced delusions of relevance, they cannot even see – much less solve – the problem.