Race-Winning Process Design
Build systems that let reliable operators deliver exceptional results
- Difficulty
- Advanced
- Time to result
- ~months to results
- Steps
- 5
- Confidence
- 96%
Race-Winning Process Design divides team contribution into two complementary functions: creating valuable systems and operating those systems consistently. A small proportion of highly autonomous employees generate revenue, design workflows, manage themselves, and teach others to execute what they built. The larger group supplies the strength and consistency that keeps those workflows running. Leaders therefore stop expecting every hire to be a rare self-starting system architect and instead invest in an operating system that makes success repeatable. A strong process defines standards, ownership, deadlines, handoffs, training, and accountability clearly enough that a capable operator can win with it. If performance remains poor after the process, training, and expectations have been validated, the evidence points more reliably toward a role or organizational mismatch.
Origin
Jasmine Star attributes the unicorn-and-donkey analogy to a friend's mentor and connects it to her own experience building and consulting teams on The Jasmine Star Show.
Core principles
- 01Exceptional results should not depend exclusively on exceptional individuals.
- 02System creators and reliable operators perform complementary roles.
- 03Strong processes reduce supervision and preserve quality during delegation.
- 04A process should be teachable, repeatable, and resilient to personnel changes.
- 05Persistent failure inside a proven system can reveal a role mismatch.
How to run it
- 1
Separate creation from operation
Identify the employees who independently generate revenue or build systems and those whose strength is operating established workflows consistently. Treat both contributions as necessary rather than ranking all work by the same standard.
Pro tip Map each important workflow to a named creator, operator, and business outcome.
Watch out Do not use the animal labels publicly in ways that demean reliable operators.
- 2
Design the operating system
Document the workflow, expected output, deadlines, ownership, handoffs, and accountability rules. Remove unnecessary dependence on memory, personality, or repeated manager follow-up.
Pro tip Begin with a recurring workflow that currently produces missed deadlines or inconsistent quality.
Watch out Documentation alone is not a system unless employees can actually follow it.
- 3
Make the process teachable
Require the system creator to train another person to operate the workflow. A system is stronger when its creator can transfer it without remaining the permanent bottleneck.
Pro tip Ask the trainee to run the process while the creator observes rather than taking over.
Watch out Do not promote a system creator before their critical responsibilities can be transferred safely.
- 4
Test repeatability
Run the workflow with a trained operator and measure output quality, speed, and deadline reliability. Use failures to distinguish unclear process design from individual performance issues.
Pro tip Track a small number of objective measures for several complete cycles.
Watch out Avoid judging the operator from a single unusual case.
- 5
Improve or reassess fit
Repair process weaknesses, provide necessary training, and test again. If a capable employee still cannot succeed with a clear and proven process, assess whether the role or organization is the wrong fit.
Pro tip Record what support was provided so the final decision rests on evidence.
Watch out Never describe a process as perfect without validating it through real users and outcomes.
In the wild
A support department assigns conversations to individual part-time employees, causing customers to wait until the original employee returns. The leader standardizes response practices, trains every representative to continue any conversation, and organizes the queue around response time rather than personalities. This converts individual knowledge into a shared operating system.
→ Customers receive faster responses without immediately increasing headcount.
A founder personally prepares a weekly revenue report because only she understands the data sources. She documents the inputs, formulas, quality checks, delivery deadline, and escalation rules, then trains an operations assistant to run it for four weeks while she reviews exceptions.
→ The report becomes dependable without requiring the founder to produce it personally.
Common mistakes
Hiring only imagined unicorns
Expecting every role to attract a rare autonomous system creator ignores the value of reliable operators and makes hiring unnecessarily difficult.
Calling documentation a finished system
A process is not proven until another trained person can use it to deliver the expected result consistently.
Blaming people before testing the process
Poor results may reflect missing tools, ambiguous standards, weak training, or unrealistic workloads rather than a lack of ability.
Is it for you?
Best for
It is best for growing businesses that need dependable execution across a team with varied strengths.
Not ideal for
It is not ideal for highly exploratory work where processes and successful outcomes are not yet understood.
From the transcript
“build process is so good that even donkeys can win races”
“The process should be so good that most people can win using that system.”
“Unicorns can train a donkey to take over the system because the system is that strong.”
From the episode
How to Identify and Lead A, B, and C Players for Business Success