A System Is What It Does

Ask a company what its approval process is for and you will get an answer about quality. Watch the approval process for two weeks and you may find it is producing something else entirely: a queue in front of one person, a delay measured in days, and a workforce that has stopped forming independent judgment about quality because someone downstream always checks. Quality was the intention. The output is dependency.

Both descriptions are honest. The people who built the process were not lying and the people running it are not sabotaging it. There are simply two different objects being discussed. One is the process as designed, which lives in a document. The other is the process as run, which lives in behavior. The second one is the system. The first one is a hypothesis about the second one, and hypotheses are frequently wrong.

This sounds like a philosophical point and it is actually a diagnostic one. If you want to know how a company works, you cannot start from its diagrams, because diagrams describe what people wish were true and are updated far less often than behavior changes. You start from outputs and observed paths, and you let the design documents be evidence about history rather than evidence about the present.

Five examples worth reasoning through

The approval process above is the first and the most consequential in agencies. A founder who reviews client work before it ships is doing something valuable, right up to the point where the review becomes the only mechanism that catches errors. Then the review is not a quality gate on top of a capable process. It is the capable process. Remove it and quality drops immediately, which everyone interprets as proof that the review is essential. It is proof that nothing else was ever built. The stated purpose is quality assurance. The revealed purpose is centralized judgment, and the cost is that the founder cannot leave.

Second, the CRM installed for visibility that operators update after the fact. The intended system is a shared, current picture of the pipeline that informs decisions. The actual system is a records department. People decide in conversations and calls, then encode the outcome later, often in batches, often shortly before a review meeting. What the CRM reliably produces is a report of decisions already made. That is not visibility. Visibility would mean the state of the work is knowable before someone asks. If you have ever heard let me clean up my pipeline before the meeting, you have heard someone describe the real system accurately.

Third, the escalation policy that exists and still ends in Slack. The policy names a path: raise it with the account lead, who has authority up to a threshold, and only past that does it go higher. The behavior is a direct message to the founder. The reason is almost never ignorance of the policy. It is that the policy has never returned an answer fast enough, or the person is unsure whether their case qualifies, or the account lead defers anyway so the extra hop only adds hours. Whatever the reason, the escalation system in operation is the founder's direct messages, and the document is a preference. Any plan that starts from the document will fail.

Fourth, the automation that saves clicks and increases babysitting. Somebody built a workflow that moves records, sends a notification and updates a field. It works most of the time. When it does not work, nothing announces the failure, so a person now checks. Time spent clicking went down. Time spent verifying went up, and verification is worse work: it is unbounded, it has no completion signal, and it produces anxiety rather than output. Judged by intention, this is an efficiency gain. Judged by what it reliably produces, it converted labor into supervision.

Fifth, the dashboard that reports activity but cannot support a decision. Sends, opens, replies, calls, meetings booked, all accurate, all current, and no view that tells anyone what to do differently tomorrow. It is a reporting system in name and a reassurance system in practice. Its real output is the feeling of being informed. The tell is that nothing in the dashboard has ever changed a plan. A measurement that cannot change a decision is decoration, however precise it is.

Why intention keeps winning arguments it should lose

Documented intention has structural advantages in a meeting. It is written down, it is legible, it is attributable to a decision someone made deliberately, and it flatters everyone present. Behavior is diffuse, partly embarrassing, and known mostly by the people furthest from the meeting. So conversations about operations tend to happen at the level of the diagram, where the system looks better than it is, and the interventions produced at that level are new diagrams.

There is also a language problem. Software categories smuggle in claims about function. Calling something a CRM implies relationship management is happening. Calling something a project management tool implies work is being managed. The category describes what the vendor built, not what your company does with it. The same applies to internal vocabulary. We have a QA process may mean a defined set of checks with owners and pass criteria, or it may mean a senior person looks at things. Both sentences are true; only one is a system.

The practical move is to insist on outputs whenever function is claimed. Not what is this for, but what does this reliably produce, how often, and who could tell me without looking anything up. A step that cannot answer that is either unnecessary or undesigned, and both of those are worth knowing.

Reading behavior as design information

The temptation, once you see the gap, is to close it by force. The behavior is wrong, the design is right, so enforce the design. Sometimes that is correct. Often it is a way of avoiding what the behavior is telling you, which is that the design has a defect the designer could not see from outside the work.

Every persistent workaround is a solution to something. Someone is trading one cost for another and their trade is usually locally rational. If account leads skip a documentation step, ask what the step costs them at the moment they are asked to do it and what happens to them if they skip it. If a stage in the pipeline is systematically mislabeled, ask what the labels are used for, because people label defensively when labels are used to judge them. Behavior is compressed information about incentives, friction and trust. Overriding it discards the information.

This is where I would resist an overly mechanical conclusion. It is tempting to treat an operation like a machine that has drifted from spec and needs recalibration. But the reason behavior diverges from design is not mechanical wear. It is that systems in companies run inside a human environment, one with incentives, status, fear, habit, relationships and finite attention. Those forces are not noise around the system. They are part of its operating conditions, as real as data quality or headcount.

Which means the fix is rarely more specification. It is design that anticipates how people actually move. A rule that is easy to follow while busy will outperform a better rule that requires calm. Visibility that is a byproduct of doing the work will outperform reporting that is a separate task. An exception path that returns an answer within the hour will be used; one that returns an answer eventually will not, no matter what the document says.

So the principle stands: a system is what it does. But the useful next question is not how do I make people conform to the design. It is what does this design assume about human behavior, and are those assumptions true here. That is a harder question, and it is where operating work stops being documentation and starts being architecture.