If You Don't Design the Process, Habit Will

Habit designs by default.

When nobody designs how work should move, habit designs it instead.

People often imagine that a process only exists after someone draws a flowchart. The boxes are connected. The responsibilities are assigned. The procedure is documented. Only then, they assume, does an operation become a system.

In reality, the system already existed. Someone was already receiving the work, making decisions, asking questions, handing it to someone else, correcting mistakes, and eventually completing it. The process was simply operating without being intentionally designed.

Why do undocumented processes develop naturally?

Whenever the same task happens repeatedly, people naturally develop ways of handling it.

Emails are forwarded to the person who usually knows the answer. One employee becomes the unofficial problem solver. Approvals follow whatever route worked last time. Information is stored wherever people remember to look.

None of these decisions were necessarily planned. They emerged because the work had to keep moving.

What is a shadow process?

These informal routes have a name: shadow processes. They're the undocumented workflows that run alongside the official ones — the personal spreadsheet, the side conversation that actually gets a decision made, the workaround built because the real system couldn't handle a specific case. Shadow processes aren't a sign that people are cutting corners. They're a sign the official process failed to account for something real.

What is a swivel chair process?

A specific, common version of this is the swivel chair process — someone manually re-typing the same information from one system into another because the two were never connected. It forms the same way every shadow process forms: a tool gets added to fix one problem, nobody builds the bridge between it and everything else, and a person quietly becomes the bridge instead. Nobody decided this should be the process. It's just what happens when tools accumulate faster than integration does.

Why do temporary workarounds become permanent?

A shortcut created during a busy week often survives for years. An exception made for one customer quietly becomes standard practice. A spreadsheet built "just for now" becomes the central operating system for an entire department.

People stop asking why something is done that way because they no longer remember another way. Improvisation slowly becomes policy without anyone noticing the transition.

What is process debt?

This accumulation has a name too: process debt. It works the same way technical debt does in software — a shortcut solves today's problem cheaply, but it accrues interest. Nobody schedules time to go back and fix the workaround properly, so it just sits there, quietly costing a little more each time someone has to work around the workaround. The debt is invisible for a long time. It becomes visible all at once, usually right when the organization can least afford the disruption of finally paying it off.

Why do organizations become dependent on one employee?

Someone always knows who gets asked first. Someone always knows which requests are quietly ignored. Someone knows which approvals matter and which ones are only a formality.

Those rules may never appear in a manual. They still shape how the operation functions every day. The organisation follows them whether they are written down or not.

What is tribal knowledge?

This is usually where tribal knowledge lives — the operational know-how that exists only in people's heads, never written down, passed along through "just watch what I do" rather than documentation. It's efficient right up until the person holding it leaves, at which point the organization discovers how much of its actual process was riding on one person's memory.

What is the bus factor?

That dependency has a blunt, well-known name in operations circles: bus factor — the number of people who'd need to disappear before a process stops working entirely. A process with a bus factor of one isn't really a process. It's a single point of failure wearing a job title.

What does process design actually involve?

Operational design is not drawing prettier flowcharts. It is deciding deliberately how work should move.

Where does the work enter? Who owns it? When does responsibility transfer? How are exceptions handled? How is completion recognised? What information must travel with the work?

Those decisions determine whether people spend their time executing work or recovering from confusion.

Why does good process design reduce mistakes?

A healthy operation does not eliminate human judgement. It eliminates unnecessary guessing.

People should not have to remember who owns the next step. They should not have to wonder which version of a document is current. They should not rely on one experienced employee to explain the process every time someone new joins the team.

Good operational design makes the intended path easier than inventing a new one.

Can an organization have a process without documenting it?

Every organisation has an operating system. Some built it deliberately. Others accumulated it one workaround at a time.

The question is not whether your process has been designed. The question is whether it was designed intentionally or accidentally.