The Org Chart, the Tube Map, and Models That Are Wrong on Purpose
Ashby says a manager needs a model of their system. Every model is wrong. The London Tube map explains how both are true.
The Org Chart, the Tube Map, and Models That Are Wrong on Purpose
Ashby says a manager needs a model of their system. Every model is wrong. The London Tube map explains how both are true.
Rock Hall, Maryland
Bottom line. A model of your organization that matches reality in every detail would be as hard to use as the organization itself, so every working model distorts something. A model used outside the questions it was built for produces confident decisions that fail. The skill lies in knowing which questions yours answers correctly and which it will quietly get wrong. Harry Beck’s Tube map is deliberately wrong about distance and direction, and it became the template for metro diagrams worldwide. Riders needed to know which line and which change, not how far. Your org chart, your architecture diagram, and your roadmap all distort something deliberately, and the trouble starts when someone forgets what each one was built to distort.
Two rules that contradict each other
Conant and Ashby’s 1970 theorem says a regulator that is both effective and simple has to contain a model of the thing it regulates. A manager who does not carry a working model of their own system will regulate it badly, since every response they make is chosen against some internal picture of what is happening.
George Box, a statistician working the same decades, put the other half in place. In a 1976 paper in the Journal of the American Statistical Association, he argued that since all models are wrong, a scientist cannot get a correct one through excessive elaboration, and should instead follow Occam and seek an economical description. Two years later, at a 1978 workshop published in 1979, he titled a section of a workshop paper: all models are wrong but some are useful. That heading is now quoted far more often than the paper. He and Norman Draper put the fuller line in a 1987 book, noting that a polynomial being an approximation does not detract from its usefulness, because all models are approximations.
Put the two together and the manager’s position looks awkward. Control requires a model. Every model is wrong. Both hold, and the resolution comes from understanding what a model is for rather than from building a better one.
Beck’s diagram
In 1931 Harry Beck was an out-of-work technical draughtsman who had been laid off by the Underground Electric Railways of London. In his spare time he redrew the Tube map, and what he produced broke the rules of mapmaking on purpose.
Existing Underground maps were geographically accurate, laid over a street plan, which meant the central stations bunched into an unreadable knot while the suburban lines sprawled. Beck’s insight was that riders cared which line to take and where to change, rather than where the stations sat. So he threw away geography. The tunnels became horizontal, vertical, and 45-degree lines, borrowing the visual grammar of the electrical circuit diagrams he drew for a living. Stations sat roughly evenly spaced rather than at true distance, and central London grew relative to the outskirts so the names would fit.
What Beck produced is a diagram rather than a map, and its errors are easy to list: false distances, approximate directions, and a relative position on the page that may bear little relation to where two stations actually sit in the city.
London Underground’s publicity department rejected it as too revolutionary. Beck resubmitted in 1932 and got a trial run of 500 copies at a few stations. The public response settled it. The first pocket edition ran 750,000 copies in January 1933, with another 100,000 in February and a poster edition in March. It became the template for metro maps worldwide, and the design is still in use ninety years later.
The riders picked the geographically inaccurate diagram over the accurate maps it replaced, and they picked it quickly.
Topology over topography
Beck made a map that was accurate about one thing and indifferent to another. Cartographers describe the move as favoring topology over topography: connectivity over geographical fidelity.
A rider needs connectivity. Which stations sit on this line, in what order, and where can I change to another line. Beck’s diagram answers all of that correctly, and reads more easily than any geographically accurate alternative. Distance and direction are where it becomes unreliable, which is the price of the clarity.
The distortion has real effects on the people using it. Alexander Kent, a cartographer who has studied the map’s influence, notes that it changed how users pictured London itself, distorting distance, direction, and even existence, by which he means whether a place appears on the map at all. A rider who consults the diagram to judge whether two stations are within walking distance is asking it a question it was never built to answer, and it will answer anyway.
Steele’s objection
The phrase “all models are wrong” gets used as a shrug, and at least one statistician has objected. J. Michael Steele argues that when you hear it, there is a good chance you are about to be sold a bill of goods. His example is a street map of Philadelphia. If a map is wrong, he says, it means a building is misnamed or a one-way street is mislabeled. He never expected the map to recreate physical reality, and only feels cheated when it fails to answer the questions it claims to answer.
Steele’s correction sharpens the whole idea. Beck’s diagram is wrong only against questions it never claimed to answer, and scrupulously right about the ones it does, which is a different thing from being defective. A model gets graded against the specific questions put to it, rather than against reality in full.
That makes the manager’s problem tractable. Accuracy stops being the useful question, replaced by two better ones: which questions does this model answer, and are those the questions being put to it?
The models a manager already runs
Organizations run on diagrams that are wrong in Beck’s sense, and they work anyway.
Consider the org chart. Real influence follows relationships, expertise, and history rather than reporting lines, so as a picture of how decisions get made it fails immediately. As a picture of accountability and escalation it has no serious rival, which is why it survives every attempt to replace it. The failure mode is using it to predict who will actually be consulted.
Story points measure nothing physical and do not convert to hours, so as a unit they are meaningless. Within one team over a stable period they capture relative size well enough to forecast a sprint, and that narrow job is the whole reason they exist. Compare two teams’ velocities and the number stops meaning anything at all.
An architecture diagram is stale the day after it is drawn and staler every week, yet a new engineer reading one learns the intended structure and the direction of dependencies faster than any other method delivers. Ask it for a capacity estimate or a blast radius and it will mislead. The subject is design intent, not runtime behavior.
Roadmaps get dates wrong. They get sequence and intent right, which is a fair trade at planning time and an unfair one in a customer conversation.
Each of these stays in use by being simple enough to hold in your head, and each buys that simplicity by throwing something away. A model of an organization that carried every relationship, every unwritten rule, and every piece of institutional history would be as hard to reason about as the organization, at which point it stops being a model.
Surprise as a measurement
A surprise is a state the system could occupy that the model did not contain. Beck’s diagram makes that definition more specific and more useful.
A surprise means a question was put to the model that the model was not built to answer, and the model answered anyway. Diagrams do not decline to respond. The Tube map renders two stations far apart on the page, offers no warning that its distances are decorative, and lets the rider draw the obvious conclusion.
That makes surprises diagnostic rather than shameful. A reorganization that does not change how work flows means the org chart was asked to model information flow, which is not its subject. Two teams whose velocity numbers turn out to be incomparable were running story points as a unit. And an incident that spreads further than anyone expected has usually been reasoned about from an architecture diagram, which describes intent at design time rather than coupling at runtime.
The model was fine in all three cases. The question was the thing that failed, which points to a cheap and unglamorous fix.
Label the boundary
Write down, next to each model an organization runs, the questions it answers and the questions it will get wrong. Not as documentation for its own sake, but as a note on the map, in the way a chart carries a scale and a projection.
An org chart answers who is accountable and who to escalate to; it gets influence and information flow wrong. Use a velocity chart to ask whether one team’s near-term throughput is stable, never to compare teams or judge individuals. The architecture diagram will tell you what depends on what by design, and mislead you about runtime behavior and current state.
The exercise protects against a confident decision made from a model answering a question nobody checked it could answer. It also makes the models easier to defend, since an honest boundary is a stronger position than a claim of accuracy nobody believes.
Beck never pretended his diagram showed where anything was. He labeled it in the corner of the page: a diagram, not a map. Ninety years later riders are still using it, and the label is a large part of why it has held up.
By Joshua McDonald on August 20, 2026.
Exported from Medium on August 26, 2026.
Reader discussion