DRY ("Don’t Repeat Yourself”) is a software principle, but the same failure mode shows up in operations: duplicated rules and duplicated work drift, create errors, and quietly raise cost. This article uses the DRY/WET metaphor to look at purely analog process design: templates, standard work, physical flow, checklists, and kanban cards (long before anyone mentions software).
"We already have the process. People just need to follow it".
Most leadership teams I meet don’t say "we need automation". They say something that sounds more reasonable and more innocent:
"We already have the process. People just need to follow it" (I need a note here: remember to write an article about the "trust the process" claim).
It’s a comforting diagnosis, because it implies the fix is cultural: communicate better, enforce harder, add one more training session, maybe put the procedure in a nicer PDF. And sometimes that works, for a week or two, especially right after someone important makes the point in a meeting.
Then reality returns. The same mistakes reappear. The same handoffs jam. The same "how did this happen?” escalations land on the same desks.
What’s usually hiding underneath is not a lack of discipline. It’s a structural issue: the organization is asking people to reconstruct the process from fragments every time they do the work.
The rule exists in a policy document, but the form says something slightly different. The training deck reflects last year’s exception. The team lead explains it one way, operations explains it another. The checklist was updated, but only in one department. So people "follow the process", but each person is following a local interpretation of it.
This is the moment where, without trying to be clever, I often borrow a metaphor from software engineering, because it describes the operational smell with uncomfortable precision: WET vs DRY.
DRY and WET, explained like developers actually mean it
In software, DRY isn’t merely "don’t copy-paste". The classic phrasing is about knowledge: every piece of knowledge should have a single, unambiguous, authoritative representation within a system.
WET is the joking counter-principle: "Write Everything Twice” (also glossed as "We Enjoy Typing” or "Waste Everyone’s Time”). The humor lands because it’s true: in a multi-layer system, adding one "simple” field can force you to repeat the same concept across labels, forms, functions, queries, and scripts.
Operations has the same phenomenon, just with binders, forms, oral tradition, and "how we do it here".
Why DRY appears naturally in process analysis
When you map real work end-to-end, repetition announces itself:
-
the same data rewritten onto multiple forms,
-
the same checks performed in different corners of the organization,
-
the same exception handled manually every morning,
-
the same training explanation delivered differently by each supervisor.
In code, DRY asks: why is the same knowledge stored in multiple places?
In process design, DRY asks: why does the organization need to "re-derive” the same decision or the same work step repeatedly, and why is it allowed to diverge?
That question is not digital. It is operational.
DRY/WET translated into process language
Here is the cleanest mapping I’ve found in practice:
| Software metaphor | What it protects | Analog process equivalent |
|---|---|---|
| DRY | One authoritative "knowledge object” | One authoritative rule/procedure/version (SOP, standard work sheet, checklist, training script) |
| WET | Duplicated knowledge that drifts | The same rule described differently across teams, forms, manuals, and training |
In BPM governance terms, many organizations explicitly aim for a single source of truth for process documentation, because fragmentation creates compliance and execution risk.
But there’s a practical nuance that matters: eliminating duplication is not always the goal.
A necessary correction: some repetition is intentional
In software, over-DRY can produce fragile abstractions. In operations, over-DRY often looks like:
-
one universal procedure nobody can actually follow,
-
decisions centralized into bottlenecks,
-
"standardization” that ignores context,
-
local workarounds that recreate WET in the shadows.
More importantly: some repetition is a control mechanism. Independent checks, dual sign-offs, and safety routines are "duplicated work” by design. That is not WET; it is risk management.
A pragmatic operational rule is:
DRY the rules and definitions. Duplicate checks only when the risk justifies it.
"Automation” before computers: the analog chain of encoding repetition
If we keep this fully analog, "automation” doesn’t mean software. It means encoding repetition into mechanisms so the work becomes reliable and cheap - through tools, layouts, procedures, and signals.
A useful historical ladder looks like this:
1) Mechanization: letting nature do repetitive work
A watermill uses hydropower to drive mechanical work such as milling (grinding), rolling, or hammering—replacing repeated human effort with a repeatable mechanism.
Long before digital, this is the core move: repeated work becomes a system behavior.
2) Methods and measurement: making work observable and redesignable
Time and motion study combines time study with motion study to analyze and improve work systems by decomposing tasks, measuring, and redesigning method. [Read more]
This is DRY applied to human motion: stop "reinventing” method; converge on a teachable baseline.
3) Flow and sequence: encoding order into the environment
The moving assembly line is a blunt but powerful idea: encode sequence and pace into the production system so the work arrives in the intended order. Ford’s Highland Park plant implemented the moving assembly line for automobile production in 1913, with widely cited milestones in October and December of that year.
4) Signals and pull: encoding decisions into tokens
A kanban is a signaling device that authorizes production or withdrawal of items in a pull system, often implemented as physical cards.
It is, essentially, a decision that has been "externalized” from memory into a shared convention.
5) Standard work: encoding the current best method into a baseline
Lean "standard work” typically formalizes elements such as work sequence, timing/takt, and standard work-in-process so the system has stability and improvement has a reference point.
The intent is not bureaucracy; it’s to reduce random variation and make improvement real rather than rhetorical.
Notice the consistent pattern: the more something repeats, the more value there is in encoding it, even if the encoding is paper, fixtures, or flow.
A brief vignette: where "people should follow the process” collapses
One of the most common WET patterns I see (especially in service operations) looks like this:
A customer request enters through three channels. Each channel has its own intake form. Each intake form uses slightly different definitions for the same fields. Downstream, someone reconciles the differences manually "because we need it in the template finance expects". Finance then revalidates because they don’t trust upstream data. Operations then rechecks because finance sometimes blocks items late.
No single step is irrational in isolation. But the whole system is WET: the same knowledge (what the request is, what qualifies, what data is required) exists in multiple representations, so everyone compensates with more repetition.
The fix, in an analog-only framing, is not "train harder". It is to make the system less dependent on reconstruction:
-
one authoritative definition of required data,
-
one authoritative rule-set for qualification,
-
one intake pattern with controlled variants (by channel, language, or customer type),
-
one visible control mechanism for exceptions.
That is "process DRY".
Where PM and BPM disciplines sharpen the DRY lens
Even if you never digitize, classic PM and BPM thinking improves your ability to apply DRY without turning it into dogma.
PM: decomposition and control boundaries
Project management disciplines (at their best) force clarity on scope and interfaces: what belongs inside the system, what is an external dependency, where approvals actually change risk, and where they are merely tradition. That boundary-setting is essential to avoid "DRY everywhere” abstractions that ignore reality.
BPM: process architecture and governance
BPM contributes a different strength: it treats processes as assets that need ownership, versioning, and governance. In practice, that often becomes a push toward a consistent repository and "single source of truth” for process knowledge, because uncontrolled duplication becomes a compliance and execution hazard.
The combined insight is simple:
-
PM keeps you honest about constraints, interfaces, and risk.
-
BPM keeps you honest about consistency, ownership, and drift.
Practical guidance: "process DRY” without going digital
You can do meaningful process DRY with paper, layout, and discipline:
-
Make rules explicit and singular.
If a rule changes, there must be exactly one place to change it (and a controlled way to propagate it). -
Standardize the repeatable core, not the exceptions.
Standard work is a baseline for stability and improvement, not a denial of context.
Externalize recurring decisions into visible signals.
Kanban is a canonical example: the "when to replenish” decision becomes a token and a convention.
-
Encode constraints into forms, tools, and physical flow.
Templates, pre-filled forms, labeled bins, routing, and checklists are analog "validation rules". They reduce dependence on memory and interpretation.
Design before digitizing
DRY was coined for software, but it describes a much older operational reality: duplicated knowledge drifts, and drift creates cost. In business process design, the analog path to automation is often available before the digital one, through standard work, physical flow, templates, checklists, and signaling systems.
If you later digitize, you may gain speed. But if you first make the analog system coherent, you gain something more valuable: predictability.