Purpose-Backwards Policy Design
Replace inherited rules by designing backward from the outcome they must produce
- Difficulty
- Moderate
- Time to result
- ~weeks to results
- Steps
- 6
- Confidence
- 98%
Purpose-Backwards Policy Design applies product and engineering thinking to organizational rules. First, identify the result a policy is supposed to create, such as useful performance feedback, controlled travel spending, or regulatory compliance. Next, separate genuine legal requirements from conventions that merely resemble requirements. Evaluate whether the existing mechanism produces the result at the necessary frequency and with acceptable cost. If not, discard the inherited implementation, work backward from the desired outcome, and test simpler alternatives. Netflix used this reasoning when questioning paid-time-off rules, expense approvals, and other standard practices. The method does not eliminate responsibility: it replaces blanket control with explicit constraints, financial visibility, capable employees, and consequences for poor judgment.
Origin
McCord describes how Reed Hastings repeatedly questioned conventional policies at Netflix. She translated those challenges into workable systems by checking legal requirements, preserving necessary information, and redesigning processes around their actual purpose.
Core principles
- 01Every policy should solve a defined problem
- 02The desired outcome determines the mechanism
- 03Inherited best practices are choices, not laws
- 04Frequent needs require frequent feedback loops
- 05Business context can replace unnecessary control
How to run it
- 1
State the intended result
Write one sentence explaining what the policy should accomplish. Distinguish the outcome from the current procedure.
Pro tip Ask what would become worse if the policy disappeared.
Watch out A vague purpose such as maintaining professionalism cannot guide design.
- 2
Identify hard constraints
Research applicable legal, regulatory, accounting, and contractual obligations. Mark everything else as a design choice.
Pro tip Ask whether a supposed requirement is legally mandatory or merely customary.
Watch out Never remove a control based only on an assumption about the law.
- 3
Test the current mechanism
Assess whether the existing process creates the intended result at the right time. Compare its benefits with delays, administrative cost, and distorted behavior.
Pro tip Examine edge cases and feedback from the people subject to the process.
Watch out Longevity and popularity are not evidence of effectiveness.
- 4
Design backward
Start from the outcome and propose the shortest reliable feedback loop or control mechanism. Use current technology and business information rather than inherited bureaucracy.
Pro tip For recurring performance needs, favor recurring feedback over an annual event.
Watch out Do not confuse removing a policy with removing the underlying responsibility.
- 5
Add context and visibility
Give decision-makers the financial, customer, or operational information needed to exercise judgment. Monitor actual outcomes rather than routing every choice through approvals.
Pro tip Embed specialists near teams when their context is more valuable than centralized permission.
Watch out Autonomy without accessible information invites avoidable mistakes.
- 6
Pilot and choose
Test one or more alternatives, inspect results, and deliberately retain the best mechanism. Revisit it when the business changes.
Pro tip Use a bounded team or period for reversible experiments.
Watch out Do not keep an old process merely because the experiment was imperfect.
In the wild
If the purpose of an annual review is to provide performance feedback, the once-a-year mechanism is poorly matched to the need. A company can instead create frequent, specific conversations close to the work and test whether employees receive clearer guidance sooner.
→ Feedback becomes timely enough to influence performance rather than documenting it after the fact.
Rather than requiring finance to approve each trip, a company defines the purpose of its travel policy, gives teams spending limits and business context, and monitors actual expenditure against budgets.
→ The company retains financial control while reducing permission-seeking and administrative delay.
Common mistakes
Automating a bad process
Making an inherited procedure faster does not correct a mechanism that was never suited to its stated outcome.
Removing controls without context
Employees cannot make company-centered decisions if they lack budgets, customer knowledge, or relevant operating data.
Calling convention a requirement
Assuming every common practice is legally mandatory prevents useful experimentation before the real constraints are investigated.
Is it for you?
Best for
Teams redesigning inherited HR, expense, travel, feedback, or approval systems.
Not ideal for
Processes fixed by non-negotiable law or regulation unless qualified experts first define the permitted design space.
From the transcript
“Let's start with the end game and work backwards and test a couple of things so we can figure out the system that really does…”
“So what's the purpose? What's the purpose of the travel policy?”
“I start thinking, well, if we really have hired adults who are really smart and really capable and really responsible, then you do we really…”
From the episode
Patty McCord Discusses Recruitment and Corporate Culture