Systems Have to Couple to Human Behavior

There is a specific kind of failure I have watched enough times to recognize it in the first hour. Someone designed a process. The process is coherent. Read on paper, it holds up: inputs defined, stages named, owners assigned, a rule for each branch. And it does not run. Not because anyone rejected it, and not because the team is undisciplined, but because the process quietly requires people to behave in ways that people, under the actual conditions of the job, predictably do not behave.

The instinct in that moment is to blame adoption. We need to retrain the team. We need better enforcement. We need to remind people in the Monday meeting. That framing puts the fault in the humans and preserves the design, which is comfortable, because the design is the thing the designer is attached to. It is also almost always the wrong diagnosis. If a process works only when someone is watching, the watching is the process, and what was written down is documentation of an intention.

A system is not a set of instructions issued to compliant components. It is a structure that a group of people with limited attention, competing incentives, uneven skill, social awareness, fatigue and real client pressure will move through hundreds of times. Design that ignores those properties is not neutral. It is design against its own operating environment.

Designing for the ideal operator

The most common root cause is that the design models an operator who does not exist. The ideal operator has full context on every account, reads documentation before acting, distinguishes an exception from a normal case instantly, updates records at the moment of decision rather than after, and has no incentive to make anything look better than it is. Every process I have seen fail was written for that person.

The real operator is running six accounts, two of which are on fire in ways unrelated to your process. Their context on the third is a Slack thread from eleven days ago. They are measured on something adjacent to but not identical with what the process optimizes. They will do the right thing when the right thing is the path of least resistance and when they can see what the right thing is. They will improvise otherwise, and their improvisation will be locally intelligent and globally invisible.

That last part is what makes this hard to catch. People do not usually break a process loudly. They satisfy it nominally and solve the real problem some other way. The record gets updated so the report looks right. The decision gets made in a direct message. The exception gets handled by whoever has capacity that afternoon. From above, the system appears to run. From inside, everyone knows where the actual routing happens.

The mechanisms people use to route around design

I want to be specific about the patterns, because vague talk about culture and adoption produces vague fixes.

People route around systems they do not trust. Trust here is not sentimental. It means the system has a track record of producing a timely answer. An escalation path that took four days last time will not be used this time, no matter how clearly it is documented, because the person escalating is accountable for the client and the path is not. They will go to the person who answers. If that person is the founder, you have just discovered why founder dependency reproduces itself even after an escalation policy exists.

People ignore documentation that is too expensive to use. Cost is measured in seconds and cognitive effort, not in whether the document is good. A forty page operating manual with the answer on page twenty six is functionally empty during a live client problem. The relevant question is never whether the SOP exists. It is whether the answer is retrievable in under a minute by someone mildly stressed. When it is not, the answer gets retrieved from a colleague instead, and knowledge quietly returns to living inside people.

People escalate when decision rights are ambiguous. Ambiguity is not a small inefficiency. It is an active push toward the top of the org, because escalating is the rational personal move when you cannot tell whether a decision is yours and being wrong is expensive. Most teams have far more ambiguity than they think, because rights are stated by scope rather than by threshold. Owns client relationships is not a decision right. Can approve scope changes up to a stated value, without consultation, and is accountable for the margin impact is a decision right.

Incentives rewrite behavior even when the process text does not change. If the report rewards volume and the process asks for qualification discipline, the process loses, and it loses without anyone objecting to it. Nobody argues with quality standards. They just optimize for the thing being counted. Any design that conflicts with what gets measured and discussed is a design that has already been overruled.

Informal relationships become the real routing layer. This is not a defect so much as a fact. People take problems to whoever has helped them before. A well designed system uses that instead of fighting it, by making the informal path and the formal path the same path where possible. When the two diverge, the formal one is theater.

Automation can reduce cognitive load or increase it, and which one it does depends almost entirely on how exceptions surface. An automation that handles the normal case and fails silently on the strange one produces a new job: checking whether the automation was right. That job has no owner, no schedule and no definition of done, so it lands on whoever is most conscientious, usually the founder. Clicks were saved and supervision was created. Net leverage can easily be negative.

What coupling to behavior actually means

The alternative to designing against behavior is not lowering standards. It is treating observed behavior as a design input with the same status as volume or margin. Before writing a process, watch what people currently do and take it seriously as evidence. When someone consistently bypasses a step, the interesting question is what the bypass is solving. Usually it is solving speed, ambiguity or the absence of context. Those are design problems with design answers.

Three properties matter more than elegance. The correct behavior should be easier than the alternatives. It should be visible, meaning both the operator and their manager can see the state of the work without assembling it. And it should be low friction at the moment of decision, not merely documented somewhere for later reconstruction. A CRM field that must be filled after the decision has been made is a compliance tax. The same field, presented as the mechanism by which the decision gets made, is part of the system.

Exception handling deserves to be treated as a core function rather than a final section nobody reads. The normal case is the easy part, and it is also the part most process design spends its energy on. Reality delivers a steady stream of situations that do not fit: the client who requests something outside scope during a renewal conversation, the deliverable that fails review for a reason the checklist does not name, the account where the primary contact leaves mid engagement. If those have no defined path, they take the shortest one available, which is upward. A system without exception design is a system that routes all of its interesting decisions to the founder by default.

Defined does not mean prescribed. It means the exception has an owner, a maximum response window, a rule about what can proceed while it resolves, and a record so the same exception is recognized the second time. That is enough for the exception to stop being a fire.

Adapting to behavior, not surrendering to it

There is an obvious way to misread all of this. If people avoid the review step, remove the review step. If people do not want to write things down, stop asking. That is not coupling. That is abdication dressed up as pragmatism, and it produces an operation with no standards and a story about being human centered.

The distinction is between accommodating how people work and accepting whatever they produce. A system still sets boundaries. It still names owners and holds them to outcomes. It still enforces a quality bar. What it does not do is achieve those things by requiring behavior the environment punishes. If review is being skipped because it delays delivery and delivery is what gets praised, the fix is not to drop review or to lecture about it. The fix is to make review fast enough that it stops competing with delivery, and to make skipping it visible rather than invisible. The standard stays. The path to meeting it changes.

The same logic applies to judgment. The goal of a system is not to eliminate judgment, which is both impossible and wasteful, since judgment is the thing you are actually paying senior people for. The goal is to place judgment where it produces value and remove it from where it produces variance. Deciding whether to extend an unusual commercial term is judgment worth having. Deciding which of two teammates picks up an inbound request is variance masquerading as judgment, and it should have been a rule.

Most operations get this backwards. They over specify the routine, which annoys competent people, and they under specify the ambiguous, which is where the founder gets pulled in. Fixing the allocation of judgment does more for founder dependency than any amount of new documentation. It is also the part of the work that most resembles design rather than administration, because it requires deciding what the organization is willing to be wrong about occasionally in exchange for speed.

The test

A useful way to evaluate any process before shipping it: describe the person who will run it on their worst reasonable day. Not their bad day, their ordinary busy day. Three competing priorities, partial context, a client waiting. Then walk the process as that person. Every point where they would need unusual discipline, unusual memory or unusual patience is a point where the design will fail, and it will fail intermittently, which is worse than failing consistently, because intermittent failure gets attributed to individuals.

Then run it and watch what happens, because the walkthrough will miss things. Behavior is the only real test data. If the observed path diverges from the designed one, the observed path is telling you what the design got wrong, and the correct response is to change the design rather than to relitigate the behavior. This is the part that requires some ego tolerance. A designer who treats divergence as insubordination will spend years defending a diagram.

Robustness in an operating system does not come from precision. It comes from the ability to keep functioning while the humans inside it get distracted, promoted, tired, overloaded and occasionally self interested. A system built for those conditions will look less tidy than one built for ideal operators, and it will still be running in eighteen months. The tidy one will have been quietly replaced by a set of habits, a handful of trusted relationships and a founder who answers questions.