How do I install the Doerrs Law skill?

Run npx skillmds@latest add the-artificer-of-ciphers-llc/doerrs-law in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Doerrs Law safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Doerrs Law?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Doerrs Law free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Doerrs Law?

The-Artificer-of-Ciphers-LLC (@the-artificer-of-ciphers-llc) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Doerrs Law by the-artificer-of-ciphers-llc

Name: Doerrs Law
Author: The-Artificer-of-Ciphers-LLC

Doerrs Law

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.

File contents

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?

---name: doerrs-lawdescription: 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 ideaA **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 surface1. Does our team know *why* we're building this, not just *what*?2. Do they have the autonomy to push back on bad ideas?3. Are we measuring outputs (features shipped) or outcomes (problems solved)?4. 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.)5. Are we outsourcing something we should own, because we want mercenaries for the cost?

Frequently asked questions