Designed Work vs. Person-Dependent Work: How to Tell Which One Is Producing Your Results
What is designed work?
Designed work is work whose method exists outside the person performing it, in a form that can be examined, changed, and compared over time. The test is not whether a document exists. It is whether the method can be pulled up, moved around, tried differently, and looked back at across years.
That last property is the one organizations skip. A method you can only describe cannot be iterated against, because there is nothing to compare this year’s version to. Organizations that treat process definition as a governance function rather than a filing exercise usually formalize it inside a business process management framework so that design, control, and revision have an owner.
How can you tell whether a good result came from the design or from the person?
You cannot tell from the result. An outcome records what happened, not what produced it. Two operations producing identical output — one running a designed method, one running a capable individual’s improvisation — are indistinguishable from the outside.
The check has to run upstream of the outcome. Read the defined process first: the documented procedures, workflows, work instructions, or the configured workflows inside a software system. Then establish which direction the influence runs. Does the defined procedure drive the process, or is the procedure trailing behind how operators have iterated on the work? Those are two different states, and only the first is designed work. Where performance data exists across multiple operators, the spread between them is a selection tool for whom to interview — it is a signal, not a conclusion.
Why undesigned work still produces acceptable results
Two forces correct undesigned work toward effective. Leadership intuition adjusts what looks wrong. Downstream commercial pressure — customers, cost, delivery, complaints — forces correction on what the market will not absorb. Both are real and both work, to a degree that varies with the organization’s capability and its awareness of its own context.
Both forces share one limitation. They read outcomes. Neither can distinguish a result produced by the design from a result produced by the person, because the outcome is silent on the question. The ceiling of both correcting mechanisms is not quality. It is attribution.
Can work be designed without being documented?
It can be agreed and held in consensus, and that arrangement sometimes functions — but it cannot be evaluated. Higher-level management processes are the common case: a monthly leadership routine can live in the memory of the people who run it and still behave like a design.
What that arrangement gives up is the ability to improve deliberately. Design is iterated by examining it, changing one part, and comparing the result against what came before. None of that is available for a method nobody can look at, and none of it survives the departure of the people holding it.
Why a procedure that never changes is not a living design
A design has to stay responsive to operational context, and operational context changes constantly. Teams make iterative adjustments daily, weekly, and monthly, and that is normal and healthy. The question is whether the notable ones — the changes made for a reason someone could state — land back in the design.
When the work iterates and the design does not, the design has stopped driving the work. It is now a record of what someone believed was happening on the day they wrote it. This is the failure that business process optimization work exists to correct: improvements that are made in practice but never embedded, so they leave with the person who made them.
How to check whether process leadership engages with the design
Engagement leaves a trail, which makes it checkable rather than self-reported. Look for change records, revision history, meeting notes referencing the process, the version posted where the work is performed, and the diagram or deck someone actually pulls up in a review.
If the design is being engaged with, evidence of the engagement exists. If no such evidence exists, that absence is the finding. This is the same discipline applied to attendance and competence: presence is established by what it leaves behind, not by whether people believe they were present.
Two states inside one organization: a worked example
Designed and undesigned work commonly coexist inside the same organization, under the same leadership and the same maturity claim.
A contract manufacturer runs a mature manufacturing execution system. Every step of the product realization lifecycle carries a work instruction, authored by engineers, delivered to the floor, and engaged with electronically at the workstation. Performance against those instructions is monitored, and when a concern appears the instruction is revised within a day or two. That is designed work with a functioning iteration loop.
The same organization administers its training program out of a few people’s heads. The underlying records system is mature — mandated training is attached to roles and status is maintained electronically — but the administration of the program is not designed work. The results are inconsistent: gaps in awareness and reportability of training status, and difficulty producing evidence on demand. The technical system is not the weak point. The management layer running it is. Organizations resolving this pattern usually treat it as a business process consulting problem rather than a systems problem, because the software was never what was missing.
Why "nothing has gone wrong" is not evidence of low risk
An absence of failures is not a measurement. Process control requires knowing the performance of the process parameters. Where nothing measures the parameters, the absence of an escape says nothing about what was caught, or how narrowly.
An undesigned training administration layer of the kind described above is an unquantified exposure rather than a low one. Training programs carry genuinely critical qualifications, and trained human judgment is frequently the safeguard an operation falls back on when its designed controls miss something. An undesigned administrative layer sitting on top of that safeguard means no accountability structure and no effectiveness measure on the last line of defense. ISO training requirements set the expectation that competence is demonstrable and risk-based; an undesigned administration layer can satisfy the records and still not satisfy that expectation.
There is a second concealment effect worth naming. A technically impressive system running very high transaction volume is harder to audit, not easier. The interface signals competence, and the volume defeats sampling — an outside reviewer is unlikely to encounter a problem by chance, or to interpret it correctly if they do.
Why capability belongs to the organization, not to the individual
Organizational capability is a property of the population, not of any one person. An individual’s performance can be evaluated, and comparing several individuals is possible where the same work is performed by several people. But the question a business needs answered is what the organization is capable of, and that question cannot be answered without designed work.
The reason is definitional. Capability means capable of something, and the something has to exist outside a person’s head to be taught, assigned, or transferred. Enabling people is done through process design; the alternative routes are all substantially harder. Organizations that build this deliberately usually connect it to a continuous improvement framework so that capability and method improve together rather than separately.
When is undesigned work an acceptable risk?
Undesigned work is acceptable where scope is small, tenure is stable, business context is stable, and the consequences of variation are low. Shadowing an expert who holds the method closely is not never viable. It is viable in narrow conditions that the organization does not control.
The cost curve is the argument, not an impossibility claim. Undesigned work can be transferred and even scaled — but each transfer costs more and holds less, because nothing anyone learned about why it worked travels with it. As headcount grows, roles turn over, and context shifts, the returns diminish. Where an organization sits on that curve is a judgment call, and it is the judgment that operational excellence consulting and process optimization consulting engagements are usually hired to make explicit.
FAQ
How do you know if a process is designed or just settled into?
Pull up the design and check when it last changed and why. Designed work has a method that exists outside the person, can be versioned, and shows evidence of engagement — change records, revision history, meeting notes. Work that has been settled into has no examinable method, so there is nothing to compare against and no record of deliberate change.
Does good output mean the process is well designed?
No. Outcomes cannot distinguish a designed process from a capable person compensating for the absence of one. Leadership intuition and market pressure both push undesigned work toward acceptable results, and both read outcomes only. Attribution has to be established upstream of the result.
Is documentation the same as work design?
No. Documentation is evidence of a design, not proof of one. A procedure that exists but never changes while the work changes around it has stopped driving the process. The useful test is whether the design is examinable, versioned, and actively engaged with by the people accountable for the process.
Can a process be designed if it only exists in people’s memory?
Sometimes it functions that way, particularly for higher-level management routines held by consensus. What it gives up is evaluation. A method nobody can examine cannot be compared to its earlier versions, improved deliberately, or transferred intact when the people holding it move on.
Why does undesigned work become more expensive as an organization grows?
Because transfer costs rise while retention falls. Each handoff passes the method without the reasoning behind it, so the receiving person rebuilds rather than inherits. Adding people, sites, or product lines multiplies those handoffs, and the returns on the informal approach diminish accordingly.
