| name | doerrs-law |
| description | Apply Doerr's Law when discussing product team culture, motivation, team engagement, hiring philosophy, outsourcing decisions, or the difference between intrinsically motivated vs. extrinsically motivated teams. Trigger on phrases like "how do we get our team more engaged?", "should we outsource this?", "our team feels like contractors", "how do we build a product culture?", or any question about what makes product teams excellent vs. mediocre. Doerr's Law is foundational for anyone thinking seriously about building a product organization. |
Doerr's Law
"We need teams of missionaries, not teams of mercenaries."
— John Doerr, ~2015 (popularized by Marty Cagan)
The core idea
A mercenary team works for the reward — they build what they're told, deliver the output, and move on. They're optimized for compliance and execution of a spec.
A missionary team works for the mission — they believe in what they're building, they care about the customer, and they're intrinsically motivated to solve the right problem. They challenge bad ideas, own outcomes (not just outputs), and go beyond the spec when needed.
The difference in what these two kinds of teams produce is enormous.
What mercenary teams look like
- They execute roadmap items without questioning whether those items are the right things to build.
- They measure success by shipping features, not by customer outcomes.
- They feel like a service bureau: "give us a spec and we'll build it."
- Product decisions get escalated rather than made by the team.
- High turnover; team members don't feel invested in success.
What missionary teams look like
- They push back on requirements that won't serve customers.
- They understand the "why" behind every initiative.
- They feel accountability for outcomes, not just delivery.
- They have autonomy to decide how to achieve goals.
- They care enough to disagree — and then commit.
How to build missionary teams
Give them real problems, not prescribed solutions.
Instead of "build a notification system," give them "our users aren't returning after day 7 — figure out why and fix it." Missionaries thrive on problems; mercenaries need solutions.
Connect the work to purpose.
Teams that understand how their work affects real customers are more engaged. Close the loop: share customer stories, show impact metrics, let engineers talk to users.
Give autonomy on the how.
Missionaries are demoralized when every decision is made above them. Set the destination clearly; trust the team to find the route.
Hire for mission fit, not just skill.
Technical skills can be developed. Caring about the mission is harder to install after the fact.
Check your own leadership.
If your team is behaving like mercenaries, ask whether you're treating them like missionaries — giving them real ownership, real information, and real trust.
Key questions to surface
- Does our team know why we're building this, not just what?
- Do they have the autonomy to push back on bad ideas?
- Are we measuring outputs (features shipped) or outcomes (problems solved)?
- Would the team work on this if they weren't paid to? (The answer doesn't have to be yes, but it's a useful diagnostic.)
- Are we outsourcing something we should own, because we want mercenaries for the cost?
