What Was Never Written Down
Most organisations suffer not from a lack of documentation but from a lack of documents that are structurally permitted to be true. An artefact only matters if it removes options, collapses ambiguity, and forces consequences.
The new senior engineer spends her first week reading. The team lead has been thorough: a shared drive with architecture diagrams, a Confluence space with process descriptions, a wiki with onboarding guides. There is an operating model document, updated seven months ago, that describes the end-to-end vehicle configuration-to-delivery pipeline in careful detail.
By her third day, she has questions. The operating model describes an automated validation step for customer configurations that checks battery options, drivetrain compatibility, and regional compliance before the order enters the manufacturing queue. The system she has been given access to does not contain this step. There is a comment in the code, dated two years ago, that says “validation bypassed pending new battery config rules.” The rules were never written. The automated validation exists in the documentation and in the quarterly metrics report, which lists configuration validation rates as a KPI. It does not exist in production.
The new senior engineer asks the team lead. He is not surprised. “That document describes what we were building towards,” he says. “The system describes what we actually did.” He opens a Slack channel and scrolls to a thread from eighteen months ago. “This is where the real decisions are. Most of them, anyway.”
Over the next two months, she will learn what the system actually does, one incident at a time. By the time she understands it, she will also understand why nobody updated the documentation. Updating it would mean admitting how far the system has drifted from what was approved. That admission has a cost, and nobody has been willing to pay it. Most software-dependent corporates suffer not from a lack of documentation, but from a profound lack of documents that are structurally permitted to be true. The artefacts exist in abundance, but they create the appearance of clarity without constraining behaviour.
The crucial distinction is between writing something down and committing to it. An artefact only matters if it removes options, collapses ambiguity, and forces consequences.
In organisations where reality is optional, documents are designed to do the opposite. They preserve flexibility. They allow multiple interpretations. They defer hard decisions. They can be agreed without changing how anything actually works.
Every reader will have encountered the document that is sixty pages long, was reviewed by eleven people, took three months to produce, and constrains absolutely nothing. It exists to have been written. Its purpose is to be referenceable, not to be true. It is the organisational equivalent of a safety certificate hanging in a building that has never been inspected: present, official, and entirely disconnected from the condition of the structure.
Sooner than most organisations expect, someone outside the building will ask to see the inspection record rather than the certificate in the corridor. The question will be operational: what did the system do, why did it do it, and who owns the answer. If the process exists mainly as institutional memory and meeting output, the only possible response is improvisation, which can pass for governance in a meeting but reads very differently when someone writes it down and compares it to what the system actually did.
...
Continue reading in the interactive reader
Read this chapterSee also: Full contents · Preview chapters · Illusions in the Boardroom