The hum of the projector fan is the only thing moving. For the third time, Anya is explaining why the login button can’t just ‘remember you everywhere.’ Her voice is a model of practiced patience, the kind you develop after 17 of these meetings. She’s using an analogy about house keys and master keys, but you can see the concept dissolving before it reaches the other side of the polished mahogany table. Across from her, the Head of Partnership smiles a tight, encouraging smile that doesn’t reach his eyes. He just wants the friction gone for his new affiliates. He doesn’t understand that what he calls ‘friction’ is what the engineers call ‘security.’
We don’t have a communication problem. We have a contract problem.
I met an algorithm auditor named Thomas L. a few years back. His job was to parachute into massive companies and figure out why their AI and machine learning models were underperforming. He told me the root cause was almost never the algorithm itself. The math was usually sound. The failure, he found in 77% of his audits, was in the ‘organizational middleware.’ That was his term for the endless chain of humans who had to translate business goals to product managers, who translated them to engineering leads, who translated them to developers. At each step, a little bit of fidelity was lost. A key constraint was forgotten. A nuance was smoothed over. The final instruction given to the machine was a blurry, fifth-generation photocopy of the original idea.
The Cost of “Organizational Middleware”
Failure in Organizational Middleware
Estimated in wasted expert-hours & opportunity cost
Thomas calculated that this translation tax was costing one of his clients an estimated $277,000 per week in wasted expert-hours and opportunity cost. Not because anyone was incompetent. But because the very structure of the organization demanded this lossy, exhausting process. Everyone was doing their best, but they were working within a system that guaranteed mediocrity by forcing the most complex ideas through the narrowest funnels of common understanding.
It’s a bit like untangling those ridiculously long strings of Christmas lights. The ones I, for some reason, decided to tackle in July. You can’t just pull on one end. That only tightens the knots somewhere else in the mess. You have to respect the structure of the tangle itself, see how one loop creates another, and gently persuade them apart. The solution isn’t brute force; it’s understanding the interface points. When you treat the whole thing as one giant, monolithic problem, you get nowhere. When you find the clean, simple connection point between two bulbs, you can start making real progress.
Understanding Interface Points
Imagine a world where the marketing team doesn’t need to ask engineering, “Can we get user activity data from the last 7 days?” They go to an internal ‘data contract’ portal, see the available endpoint is getUserActivity(period='7d'), and know it’s possible. The contract is the documentation. The interface is the promise. The meeting is now about the brilliant campaign they can build with that data, not a debate about whether the data is accessible. The conversation shifts from feasibility to creativity.
(Can we do this?)
(What can we build?)
We made a mistake when we designed our company. We organized it around disciplines-Sales, Marketing, Engineering, Product-and then were shocked when we had to spend all our time building temporary bridges between them. We created silos and now we pay a tax to yell across the empty space. It is an absurd way to work. It’s also an incredible opportunity for a competitive advantage, because almost every company over 37 people operates this way.