What is “yak shaving”?
Yak shaving describes the long recursive chain of tasks that must be completed before the actual task can be done — each prerequisite spawning its own prerequisite. The phrase, popularised by MIT AI Lab and later by Jeremy Stone, references a hypothetical engineer who needs to wax the car, which requires a hose, which requires going to the store, which requires the car, which is at the garage… ultimately ending with the engineer shaving a yak.
Where yak shaving appears in startups
- Engineering: “I just need to ship feature X” → “X needs library Y” → “Y needs migration Z” → 2 weeks later, X is still unshipped.
- Operations: “We need to send a campaign” → “We need to clean the CRM” → “We need to define lead stages” → “We need a sales ops hire.”
- Product strategy: “We should expand to enterprise” → “We need SOC 2” → “We need a security engineer” → “We need to define security policies” → “We need a CISO.”
When yak shaving is necessary vs. wasteful
- Necessary: the foundation is genuinely broken (technical debt blocking releases, security gap blocking enterprise sales).
- Wasteful: the prerequisite is a preference, not a hard blocker. “We should refactor before adding the feature” is often wasteful in early-stage code.
- Trap: yak shaving feels productive because each sub-task is real work; only the original goal slips.
How to break out
- Time-box the chain: if a single task fans out beyond 2-3 prerequisites, escalate.
- Question the goal: sometimes the original task wasn’t actually critical and the chain proves it.
- Add scope, not depth: short-cut the chain even at the cost of a workaround that needs cleanup later.
- Recognise the pattern: teams often name yak shaving in stand-ups once they have the vocabulary.
Do: name yak shaving explicitly when it appears; create lightweight workarounds rather than perfecting the foundation.
Don’t: let “we have to do it eventually” justify pulling foundation work into the critical path — eventually is not now, and now is what gets shipped.