Most of what’s wrong with an organization was once somebody’s solution.
When an organization is struggling, the usual diagnosis is that something is missing: a process, a platform, a better leader. So it adds one. Suppose integration between teams is messy, with every team writing its own glue code and tripping over everyone else’s. A reasonable fix is to adopt a new technology and stand up a team to own it. Within a year, every other team has handed its integration work to the new team and is waiting on it. One team now does the work of ten, and the other nine have a respectable excuse for not delivering.
The original problem was real and the fix was sensible. So why did things get worse, and why does nobody say so?
Solutions that breed problems
The integration team is a case of solution pollution: a solution that creates more or bigger problems than the one it was meant to solve. Messy but distributed work became a single point of failure with no spare capacity. The new problem is worse than the old one, and it is also harder to see, because it looks like progress. There is a platform, a roadmap and an owner.
The next move is predictable. The bottleneck is treated as a fresh problem and gets its own solution: an intake process for integration requests, a prioritization committee, a quarterly plan to sequence the backlog. Each adds overhead, and the overhead gets its own fix in turn. After a few rounds the solution layer is thicker than the problem it started from. Repeat that across every department and you have the general pattern: most organizational dysfunction is solution pollution — the accumulation of solutions that each created new problems, layered on top of each other until the solution stack is heavier than the work itself. Meanwhile the products that depend on integration keep slipping, until the slip threatens the business. The organization answers with more planning, because planning is the move it knows. You cannot plan your way out of an existential crisis.
Why nobody deletes the solution
The obvious repair is to admit the integration team was a mistake and unwind it. That rarely happens, and the reason has less to do with stupidity than with how blame moves.
Whoever proposes unwinding it has to say out loud that it failed, and in most organizations raising a problem means owning it. The Copenhagen Interpretation of Ethics makes this worse: when you observe or interact with a problem in any way, you can be blamed for it, even if you make it slightly better. So the rational employee looks away. Problems nobody will touch become orphaned responsibilities, accumulating silently like dark matter until they cause a crisis. The hot-potato game settles into CYA culture: nobody catches the potato, but everyone keeps receipts proving they saw it in the air.
Nor will the numbers force the issue, because nobody collects them, and the integration team’s growing backlog reads as proof of its importance. The platform is declared a success by announcing it, which amounts to signaling and calling it a success by not measuring any outcomes. Entropic organizations prefer accountability over learning: tracking who failed is safer than asking what was learned, and measuring the outcome might show that the solution was worse than the problem.
Some complexity is real
The standard defense is that the work is genuinely hard. Customers are demanding, the domain is complicated, and the legacy systems are load-bearing. Some of that is true. Even God cannot refactor: the giraffe’s recurrent laryngeal nerve loops pointlessly around the aorta because evolution cannot redesign a load-bearing system, and critical legacy code is impossible to clean up for the same reason.
But “Enterprise customers” is not an excuse to build complicated crap slowly. Most complexity defended as inherent is camouflage for solution pollution that nobody has the incentive to clean up. A system that cannot tell genuine complexity from the manufactured kind ends up rewarding the person who plays arsonist and firefighter, creating the crises they then heroically resolve. In that world most people do not come to work serving a customer or a user. They serve some process, and working extra hard or extra smart inside it does not create new value. In a bizarre way, it feeds the stack.
The rare and valuable organization is the one that can delete a solution, that can say “we will live with this problem because the solution is worse.” For the integration team, that would mean handing the work back to the teams, mess and all, and admitting the mess was cheaper. Every new process is proposed on the strength of the problem in front of it. The better question is who, a year from now, would be able to say that it made things worse.
References:
- Workplace observations, various organizations