Legibility vs Value

Dysfunctional engineering teams and organizations seem to share a pathology. I have seen it or heard it enough times from insiders to name it. The structure was built to explain itself to the people who fund it, not to be useful to the people it serves.

This is not a failure of individuals. It is what systems do when the incentive to narrate the work outpaces the incentive to ship it.

Before the argument goes further, define the terms.

Value is external. A user's problem got smaller. A customer renewed. A team that was spending eight hours a week on manual work spends two, or none. Revenue landed that would not have landed. A capability exists in production that did not exist six weeks ago. The test for value is whether something measurable changed for somebody outside the person who created the measurement. Internal metrics that roll up into a presentation for other internal people are not value. They are narration.

Legibility is internal. It is the ability of the organization to present itself to people who do not do the work. A roadmap, a status report, a promotion packet, a slide deck summarizing last quarter. All legibility. Some legibility is necessary. Investors ask questions. Regulators audit. A new engineer on day one has to find the owner of a service. Succession planning requires somebody above the work to know who is doing what and why. In moderate doses, legibility is how a large organization avoids a single person's laptop becoming the only record of how something works.

The pathology is not legibility itself. The pathology is the slow inversion where legibility becomes more important than value, because legibility is what leadership sees and therefore what leadership rewards.

The symptoms are so common they have become invisible. Headcount becomes a signal of seriousness. Fifty people is taken more seriously than ten who ship 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 coordinate and defend the one below it. A director explains a manager who explains a tech lead who does work that four layers above cannot describe in technical detail.

Roadmaps are color-coded. Strategy decks are polished. The org can describe the river in perfect detail, its depth, its current, the composition of its banks, while drifting farther from the water.

Until describing the work is the work.

Watch a meeting end without a decision but with a clean summary and a follow-up owner. It feels productive. Nobody tracks whether the follow-up produced anything. The meeting existed to be held, not to decide.

Watch a postmortem. The real root cause is identified by the on-call engineer in the first ten minutes. The remaining fifty 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 one, when the same thing happens.

People survive inside this. Some call the survival maturity. Sometimes it is. Sometimes it is just fluency in the maintenance of unreality.

Here is the trade-off the honest version of this argument includes. Killing all legibility leaves an org that cannot onboard a new hire, cannot answer a regulator, cannot defend its runway to a board, cannot maintain continuity when a key person leaves. The question is not whether to have legibility. The question is whether the legibility you have is load-bearing or decorative.

Load-bearing legibility is the kind a regulator asks for, a new engineer needs on day one, or an investor requires to make a capital decision. It is minimum viable narration for a known reader with a known use. It stops existing the moment the reader stops needing it.

Decorative legibility exists to make somebody inside the org look competent to somebody else inside the org. It has no external reader. It is produced on a schedule rather than in response to a question. Nothing breaks if it disappears, which is why nothing stops it from expanding.

Most orgs have the ratio wrong. They have far more decorative legibility than load-bearing legibility, because decorative legibility is what gets rewarded in calibration rooms, and load-bearing legibility is assumed to exist even when nobody has checked.

The diagnostic question is simple and uncomfortable. Does this meeting, role, process, or layer increase the organization's ability to create value, or has it become overhead defending its own right to exist?

Three tests, ordered from narrowest to most structural. A reader can pass the first with self-flattery. By the third they cannot.

The meeting test. If this meeting did not happen this week, would any user notice? Not any stakeholder. User.

The approval test. If we removed this approval step tomorrow, what specific failure mode returns? "Quality might degrade" fails. Name the failure. Price it. Compare it to the weekly cost of the approval step itself.

The role test. If we cut this role, what function leaves the org? Not what person. What function.

Run it on an architecture review board. Users would notice nothing if the ARB went dark for a month. The failure it defends against is a junior engineer picking the wrong datastore once. That failure is cheaper than the weekly cost of fifty engineers writing documents to a rubric designed to prevent it. Cut the ARB and the function that leaves is "centralized taste." Taste does not require a standing board. It requires a senior engineer in the room at kickoff.

Holding the balance is the whole skill. Keep load-bearing narration. Kill the decorative kind. A quarterly letter to the board is load-bearing if the board reads it and makes capital decisions on it. A weekly status deck summarizing the same information four layers down the org is decorative. A runbook that exists so a new on-call can find the right dashboard is load-bearing. A leveling matrix may be either, depending on whether it drives development conversations or just ratifies decisions made in a side channel.

Most orgs will not run this test honestly. 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 the answer is no. The planning process that should be audited for ROI is run by the people whose jobs depend on planning being indispensable.

The compression will come anyway. Not because anyone reads this and acts on it. Because economics enforces what introspection will not. The startup that ships with four what the incumbent ships with forty is not making a philosophical argument. It is making a market argument.

Markets settle every debate organizations refuse to.

Or just chat with the founder of SCI.