Legibility vs Value

Every dysfunctional engineering organization I have ever worked inside or consulted for shares a single root pathology: the structure has been optimized to make itself intelligible to the people who fund it, not useful to the people it serves. This is not a failure of individuals. It is an emergent property of systems where the incentive to explain the work has overtaken the incentive to do it.

The symptoms are so common they have become invisible. Headcount is treated as a signal of seriousness -- a fifty-person department is taken more seriously than a ten-person team that ships more, because scale implies complexity and complexity implies sophistication. Titles inflate because the org chart is the primary artifact leadership reads, and a flat chart looks unmanaged. Layers breed layers because each new layer can explain, coordinate, summarize, and defend the existence of the others. A director justifies a senior manager who justifies a manager who justifies a tech lead who does the work that four layers above cannot describe in technical detail.

The organization becomes extraordinarily articulate about its own intentions. Roadmaps are detailed and color-coded. Operating plans are precise. Strategy decks are polished. Quarterly business reviews are rehearsed. The org can describe the river in perfect detail -- its depth, its current, the composition of its banks -- while drifting steadily farther from the water. And because the drift is gradual, it escapes notice until it has become culture. Until describing the work is the work.

Watch the meetings. A meeting ends without a decision but with a clean summary and a follow-up owner, so it feels productive. Nobody tracks whether the follow-up produced anything. The meeting existed to be held, not to decide. A postmortem finds the real issue -- the actual technical root cause is identified by the on-call engineer in the first ten minutes. Then the remaining fifty minutes are spent assigning procedural remedies because the structural remedy would require someone important to admit the problem is not local. So the fix is a new checklist, a new review step, a new approval gate. The org gets heavier. The system gets no better. The postmortem is filed. It will be referenced in the next postmortem when the same thing happens.

Architecture review boards staffed by people who have not touched production code in years make decisions about systems they could not operate. They review design documents written by engineers who spent more time on the document than on the design, because the review board evaluates the document, not the system. Calibration meetings where careers are negotiated by people who have never read the engineer's code. Platform initiatives with eighteen-month timelines and success criteria so vague that failure is impossible because nobody defined success. Strategy off-sites that produce mission statements no one references and values documents no one follows.

None of this is catastrophic in isolation. All of it compounds. Each ritual consumes time and attention. Each layer adds latency between the person who sees the problem and the person who can fix it. Each abstraction loses fidelity. The engineer who discovered the issue describes it to the tech lead, who describes it to the manager, who describes it to the director, who describes it to the VP in language safe enough to present without triggering a reorganization. By the time the information reaches someone with the authority to act, it has been translated so many times it no longer resembles the original signal.

People learn to survive inside this. They learn which truths can be spoken plainly and which need translation into safer language. They learn to convert frustration into process improvement proposals. They learn that if a problem is old enough, it can be treated as weather -- an ambient condition nobody is responsible for. They learn that the official narrative and the private one are related but not identical. If they stay long enough, many become fluent in both. That fluency is usually called maturity. Sometimes it is. Sometimes it is adaptation to unreality.

The diagnostic question is simple and uncomfortable: does this increase the organization's ability to create value, or has it become overhead defending its own right to exist? Apply it to any meeting, any role, any process, any layer. Not hypothetically. Concretely. If this meeting did not happen, would users notice? If this role were vacant for a month, would output change? If this process were removed, would quality degrade or would people simply build faster?

Most organizations will not ask this question honestly because the honest answer threatens the people asking it. That is the trap. The structure that needs diagnosis is the same structure that controls the diagnostic process. The VP who should be evaluating whether VPs are necessary is not going to conclude that the answer is no. The planning process that should be evaluated for ROI is run by the people whose jobs depend on planning being indispensable.

The compression will come anyway. Not because someone reads this and acts on it. Because economics will enforce what introspection will not. The startup that ships with four people what the incumbent ships with forty is not making a philosophical argument. It is making a market argument. And markets, eventually, settle every debate that organizations refuse to.