“Don’t pave the cow path” means you should not automate or polish an inherited workflow before checking whether its destination and route still make sense. A familiar process may contain obsolete assumptions, duplicate work and exceptions that accumulated over time. Digitizing it can make that waste faster and harder to change.
What “don’t pave the cow path” means
The metaphor is about process design, not literal roads. A cow path is a route created by repeated use rather than deliberate planning. In an organization, it can be a paper form copied into a web form, a series of approvals retained because “that is how it has always been done,” or a spreadsheet workaround that became an unofficial system.
Paving the path means embedding that route in software, policy or infrastructure. The result may look modern while preserving the original delays, handoffs and unnecessary decisions.
J. A. Wesley described this progression in a 1989 Computers in Healthcare contribution: “Our first impulse was to pave the cow path, to computerize the way manual procedures were done. Then we tried to straighten out the cow path, to make those procedures more efficient.” The deeper lesson is to question the path itself before optimizing it.
Free tools Windows power users keep installed
One-click scans. No signup required.
#1 Best Overall
Why automation can preserve waste
Speed does not equal effectiveness
An automated step can complete in seconds and still serve an obsolete goal. Removing typing time does not help if the request should never require three approvals, or if the output is no longer what customers or staff need.
Digital systems make old assumptions durable
Once a legacy route is encoded, changing it can require new requirements, migrations, training, compliance review and vendor work. A temporary workaround can become the organization’s official operating model.
Exceptions become hidden complexity
Manual processes often rely on judgment and informal fixes. A direct translation into software may produce long conditional rules, duplicate data entry and confusing exception queues rather than a simpler experience.
Start with the outcome, not the existing steps
Process-innovation guidance in Leading Innovation, 2nd Edition puts goal-setting first and measurement next. Before choosing a platform or writing requirements, state what the user must accomplish, under which constraints, and what a successful result looks like.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Rank #3
- User outcome: What decision, service or result must the person obtain?
- Constraints: Which legal, safety, contractual, privacy or policy conditions genuinely apply?
- Quality: What makes the result accurate, complete and useful?
- Time: How quickly must the outcome be delivered?
Then ask three diagnostic questions: Is the current process effective? Is its original goal still the goal? Is the route efficient for today’s environment?
A practical method for redesigning a legacy workflow
- Write the outcome in user terms. Describe the job to be done without naming the current form, department or software. For example, “a customer receives a verified answer” is more useful than “the agent completes Form 12.”
- Map the workflow as it really operates. Capture triggers, handoffs, approvals, data entry, queues, exceptions, rework and workarounds. Observe users rather than relying only on procedure documents; actual behavior is evidence, not automatically the specification.
- Establish a baseline. Where data is available, record elapsed time, user effort, error rate, rework, abandonment, cost and outcome quality before changing anything. Note the period and population measured so later comparisons are meaningful.
- Classify every step. Mark each activity as required by law, safety or policy; necessary to achieve the outcome; or historical convention. Do not remove a control merely because it is inconvenient, but do challenge controls that no longer have a defensible purpose.
- Design two routes. Create a minimally improved version that preserves the basic path and a redesigned version that uses the new environment’s capabilities. The second option might remove a handoff, reuse verified data, provide self-service or make a decision rule explicit.
- Pilot the smallest meaningful change. Test with a defined group or transaction type. Compare results with the baseline, collect user observations and watch for new failure modes, including cases that were previously handled informally.
- Keep only justified steps. Retain activities that improve the outcome or satisfy a real constraint. Document why each retained control exists and assign ownership for reviewing it as conditions change.
When to improve the existing path and when to replace it
| Decision factor | Legacy-preserving improvement | Full redesign |
|---|---|---|
| Outcome effectiveness | The current route reliably achieves the current goal. | The goal, service or required result has changed. |
| User effort | Small reductions in clicks, typing or waiting address the main burden. | The route requires avoidable handoffs, repeated explanations or duplicate entry. |
| Process complexity | Rules and exceptions are limited and understandable. | Exceptions dominate, responsibilities are unclear or workarounds are routine. |
| Technology opportunity | The new system mainly offers faster execution or better visibility. | The environment enables a materially different model, such as real-time validation, self-service or integrated data. |
| Implementation risk | A controlled change can deliver value without disrupting essential service. | The cost of preserving the old route, including maintenance and training, exceeds transition risk. |
| Compliance and safety | Existing controls are necessary and can be implemented more clearly. | Controls can be met through a different, demonstrably safe and compliant design. |
| Measured performance | Baseline results are already strong and targeted changes improve them. | Baseline results show persistent delay, errors, abandonment or poor outcomes. |
Familiarity alone is not a reason to preserve a path, and novelty alone is not a reason to replace it. Observation and before-and-after measures should decide.
How to use user behavior correctly
Watching users navigate a process reveals what documentation misses: shortcuts, informal approvals, copied values, abandoned screens and recovery tactics. Those observations help you find the real path.
They do not prove that every observed behavior should become a feature. A workaround may exist because the system is confusing, because a policy is unclear or because a step is unnecessary. Treat behavior as a clue to investigate. Ask what outcome the behavior supports, what constraint it reflects and whether a cleaner route could meet the same need.
Recommended Free Tools
Best Value
Example: modernizing an approval request
Suppose employees submit a request by email, an administrator retypes it into a spreadsheet, two managers approve it, and finance re-enters the same details. A literal digital conversion might replace email with a form and preserve every approval and re-entry.
A cow-path review would first define the outcome: a verified request reaches finance with an accountable decision. Mapping may show that one approval exists only because the original paper form lacked validation. A redesigned pilot could validate required fields once, route only high-risk requests for a second review, and pass the verified record directly to finance. The comparison should measure completion time, corrections, abandonment and decision quality against the old route.
Common failure modes
- Starting with a tool demo: A platform’s features can dictate a solution before the problem is understood.
- Trusting procedure manuals as reality: Official diagrams often omit queues, exceptions and unofficial work.
- Optimizing a local step: A faster department can create more work for the next handoff.
- Deleting controls casually: A step that looks historical may protect safety, privacy or legal obligations.
- Measuring activity instead of outcomes: Fewer clicks or faster processing is not success if accuracy or service quality falls.
- Skipping a baseline: Without pre-change measurements, teams cannot tell whether the redesign helped.
- Calling preference a requirement: “Users are used to it” should prompt investigation, not automatic preservation.
Where the phrase came from—and what is uncertain
The expression is sometimes linked informally to Boston street stories or Sam Walter Foss’s poem “The Calf-Path.” A primary archival origin is not established here, so those stories should not be treated as settled authorship. The well-supported modern use is the process-innovation warning documented by Wesley and later digital-transformation guidance.
Applying the principle in a digital transformation
Digital operations require more than converting paper actions into screens. As Kate Simpson wrote in Canadian Lawyer in 2019, “operational efficiencies are achieved only by fully analyzing the manual process and redesigning it for a digital world.” That means using capabilities such as shared data, validation, workflow visibility and appropriately scoped automation while preserving only necessary controls.
Make the review repeatable: assign an owner, publish the baseline and target measures, test changes with real cases, and schedule a review when regulations, products or user needs change. A process that was well designed last year can become a new cow path after circumstances move on.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
