The screen glowed a sickly corporate blue, reflecting perfectly in the unused water carafe on the long conference table. Project Phoenix, they called it. The mandatory training was mercifully over, or maybe mercilessly begun, depending on how you viewed the three hours of required certification to log a single activity.
I sat there, staring at the new dashboard. It looked, undeniably, magnificent. Like the flight deck of some bespoke, Scandinavian spaceship. Every corner had a widget, every widget had a metric, and every metric was, presumably, essential. My immediate task? Submit an expense report for lunch-a $23 transaction, nothing complex. But to complete this act of basic financial hygiene, the system demanded verification of vendor trust, two-factor authentication for the receipt image upload, categorization via a six-level hierarchy that included ‘Miscellaneous, Sub-Category 4, Level 3,’ and finally, the required approval routing based not on my direct manager, but on the cost center associated with my current project phase.
The Count:
Seventeen clicks. I counted them. Seventeen clicks just to tell the company that I bought a sandwich. And the core frustration isn’t the number 17, but the sheer, agonizing why. Why would an organization spend millions, maybe $373 million, on a platform designed ostensibly to streamline operations, only to build it out of layers of digital friction, like trying to run through wet cement?
The Allure of the Single Source of Truth
They sell us the promise of the ‘Single Source of Truth’-a monolithic, gleaming data repository where every fact lives happily ever after. We buy into this because, conceptually, it sounds marvelous. No more chasing data ghosts across shared drives, no more version control nightmares. But what we actually implement is often a ‘Single Point of Failure and Resentment.’ The moment the software makes a basic job harder, people revert. They open Excel. They email drafts of reports. They start shadow systems-small, personal rebellions built on simplicity and speed-because the magnificent Project Phoenix is too heavy to actually lift.
“And I get criticized for simplifying things, for saying, ‘Look, if we trust Sarah to talk to a client and bring in $133,000 in revenue, why do we need four mandatory fields and a dropdown menu with 43 options just to capture her notes on that conversation?’ They push back, saying, ‘We need the granular data!’ But what they really mean is, ‘We don’t trust Sarah to capture what we deem important, so we’ve engineered a cage for her workflow.'”
The Uncomfortable Truth
That’s the uncomfortable truth: the complexity of your enterprise software is rarely a user experience problem. It is an organizational trust problem.
Control, Anxiety, and the Plumb Line
The software doesn’t care about efficiency; it cares about control. Every mandatory field is a reflection of a policy committee’s failure to trust the employee to exercise judgment. Every automated approval loop is a management team outsourcing the difficult work of establishing clear, simple rules to a piece of code. If you cannot articulate your process simply enough to fit on a sticktail napkin, you shouldn’t be building a spaceship stickpit to house it.
I remember talking to a man named Hugo B.K. once, a stonemason who specialized in historic building repair. He was repairing the foundation of an old municipal building-built, he told me, in 1913. He had a meticulous approach, but his tools were profoundly simple. Hammer, chisel, level, plumb line. When I asked him why he didn’t use the new laser scanning equipment for alignment, he simply shrugged. “The laser tells me where the wall is supposed to be. The plumb line and my eye tell me what the stone wants to do.”
His expertise wasn’t in following a complex procedure; it was in knowing when to trust the material and when to trust his own hands. He achieved near-perfect alignment (he aimed for 99.3% accuracy, he said, because 100% was a lie) by respecting simplicity. His value was his judgment, not his compliance with an unnecessarily complex workflow.
The Value of Clear Execution
Time Spent on Task
Time Spent on Value
That same philosophy should apply to how we design our internal systems, especially in service-driven industries where complexity obscures the real job. Think about measuring a space for new material installation. It seems inherently straightforward-measure, calculate, install. But often, complexity creeps in through unnecessary steps: mandatory digital forms that mirror physical paperwork, confusing inventory management systems designed for warehouses thousands of miles away, and internal routing that demands approvals from three different geographical locations before an installer can even load a truck. This overhead kills morale and margin, complicating what should be a straightforward customer experience.
This is precisely why simplicity wins. When operations are streamlined, transparent, and focused on core delivery-whether that’s laying a precise cut of wood or logging a simple client call-the value is clear. Businesses need systems that empower expertise, not systems that enforce compliance through digital obstacle courses. If you value this kind of clear, focused service, then you’d appreciate how much easier the process is when dealing with companies like Floor Coverings International of Southeast Knoxville. They remove the needless layers of complication that define so many vendor experiences, focusing instead on delivering the core service effectively and transparently. The friction we accept in enterprise software is exactly the friction customers hate encountering when they hire us.
The Duct Tape Analogy
I made a mistake once, a few weeks ago. A very small, irritating mistake. I had a splinter deep in my finger, a tiny fragment of wood, and I convinced myself I needed surgical precision to remove it. I tried tweezers, then a needle under a magnifying glass, turning a five-second job into a sweating, twenty-three-minute ordeal, ultimately driving the splinter deeper. My wife came in, saw my state, and simply used a piece of duct tape, peeling it back sharply. Problem solved. The complexity was in my head, not in the job.
The same institutional over-thinking infects ‘Project Phoenix.’ We start with a simple goal-log the call, submit the expense-and then leadership adds friction because they feel exposed. If the system is too simple, they worry they won’t catch that 0.3% margin error, or that one employee (out of 233) who might cut a corner.
Cost of Mistrust (Internal Overhead)
99.7% Distrusted
So, the software is engineered to catch the bad actor, but in doing so, it punishes the 99.7% of trustworthy, hardworking people. It doesn’t solve the organizational trust issue; it simply automates the mistrust, creating a bureaucratic monument to the executive team’s anxiety. Every delay, every error message, every confusing pathway is just a tiny digital whisper saying: We don’t believe you.
The Final Realization
We pay hundreds of millions for the privilege of being disbelieved, then we spend countless hours in training learning how to navigate the fortress built around our data. We accept the 17 clicks because we confuse complexity with thoroughness, and size with importance. We tolerate the ‘Phoenix’ dashboard that looks like a spaceship, even though all we needed was a bicycle.
We need to stop solving organizational problems with software that costs more than the organization itself. If you can’t trust your people to log a call or file an expense report without 17 layers of digital scrutiny, your problem isn’t a system deficiency. It’s a leadership failure.
What are you trying to manage away, rather than lead through?
That’s the question that costs $373 million to avoid answering.