Missionaries, Mercenaries, and the Team That Needs Both
A junior who became a staff engineer taught me what missionary energy really looks like — and why the best teams don't need everyone to have it.
I watched a junior developer grow into a staff engineer in a way that surprised almost everyone around him — except, maybe, himself.
He wasn’t the fastest coder on the team. He wasn’t the one with the flashiest resume or the deepest systems knowledge at the start. What set him apart was something quieter: he cared about the product in a way that most engineers simply don’t.
He’d question a feature’s purpose before writing the first line. He’d push back on designs that technically worked but felt wrong to a user. He’d refactor not because the ticket said so, but because the code didn’t reflect what the product was trying to be.
The other engineers on his team weren’t bad. Some were quite good. They shipped clean code, hit deadlines, and worked well together. But they stayed inside the boundary of what was asked. He kept crossing it — not out of restlessness, but out of care.
That difference — care at the level of craft and product — is what I’ve come to think of as missionary energy. And it changed how I think about building teams.
The missionary and the mercenary
John Doerr popularized this framing years ago: missionaries build because they believe in something; mercenaries build because there’s a job to do.
It’s a useful distinction, but it’s often misused. Leaders romanticize missionaries and quietly look down on mercenaries — as if caring less makes someone lesser.
That’s wrong.
Mercenaries — and I use the term with respect — are the execution backbone of any team. They show up, they deliver, they don’t need the work to feel meaningful to do it well. They’re pragmatic, scope-aware, and emotionally resilient in ways that missionaries sometimes aren’t.
The junior who became a staff engineer? He was extraordinary. But a team of five of him would have spent half its time debating product direction and the other half refactoring code that was already fine.
You need both. The question is how to mix them.
Why missionaries are hard to find
Genuine missionary energy is rare — not because people lack passion, but because most environments quietly suppress it.
When priorities rotate every quarter, ownership erodes. When “just ship it” is the default culture, craft becomes a luxury. When product context is locked inside a PM’s head and never shared with engineers, there’s nothing for a missionary to attach to.
Most engineers don’t start as mercenaries. They become transactional because the system rewards transactions.
The junior who stood out didn’t have more talent than his peers. He had an environment where product context was visible, where asking “why are we building this?” wasn’t seen as slowing things down, and where someone — his lead, his PM, the culture around him — gave him permission to care beyond the spec.
Missionaries aren’t born. They’re uncovered — in systems that make caring safe and visible.
The ones who don’t know they’re missionaries
There’s a subtler version of this I’ve seen more than once: the engineer who exhibits deep ownership, quiet pride, attention to detail — but doesn’t identify as “passionate.” They’d never call themselves a missionary. They just think they’re being thorough.
These are the most dangerous ones to miss.
They don’t perform enthusiasm. They don’t pitch vision in meetings. They just quietly hold the quality bar when no one’s watching. And because they don’t signal loudly, they get managed like everyone else — same check-ins, same expectations, same level of investment.
That’s a mistake. These quiet missionaries often carry more institutional knowledge, more product intuition, and more influence on team culture than anyone realizes — until they leave.
Missionary energy has a cost
Here’s what no one warns you about: the same energy that makes a missionary valuable makes them fragile.
When you care deeply about the product, you feel every shortcut. Every compromised release. Every decision that trades quality for speed. It accumulates — not as resentment, but as fatigue.
The junior who grew into a staff engineer? There were stretches where I could see the weight of caring more than his environment demanded. He wasn’t burning out from workload. He was burning out from the gap between his standards and the team’s defaults.
Missionaries don’t need less work. They need their care to be met — with clarity, with standards, and with at least a few people around them who operate at the same frequency.
Without that, purpose eats balance. And the best people quietly start protecting themselves by caring less.
The mercenary’s underrated gift
Mercenaries bring something missionaries struggle with: detachment.
They can ship a feature they don’t love and sleep fine. They can pivot away from a project they invested in without grieving. They can look at a messy codebase and say “it works, let’s move on” — and sometimes that’s exactly right.
This isn’t apathy. It’s pragmatism.
In a team, mercenary energy provides:
- Delivery pressure — someone has to care about the deadline, not just the craft
- Emotional stability — they don’t ride the highs and lows of every product decision
- Scope discipline — they naturally resist over-engineering and gold-plating
- Resilience during pivots — when direction changes, they adapt without existential crisis
A team with no mercenary energy stalls in idealism. A team with no missionary energy delivers without soul. The magic is in the mix.
Designing the mix
This is where leadership gets practical. Not every role needs missionary energy, and not every person needs to care at the same depth. The leader’s job is composition.
Where missionary energy matters most:
- Roles with high ambiguity — where the spec doesn’t exist yet and someone needs to shape it
- Ownership-heavy positions — where the person is the product’s conscience
- Culture-shaping seats — tech leads, founding engineers, senior ICs who set the standard
Where mercenary clarity works well:
- Execution-heavy sprints — clear scope, tight timelines, known patterns
- Scaling phases — when the architecture is set and the team needs to build fast
- Support and maintenance — where reliability matters more than reinvention
How to pair them:
- Put a missionary next to a mercenary on the same project. One pushes for depth, the other pushes for delivery. The friction is productive.
- Don’t ask mercenaries to “care more” — ask them to respect the standard. There’s a difference.
- Don’t let missionaries set the pace for everyone — protect their energy, but don’t let their intensity become the team’s implicit expectation.
How to protect the balance:
- Give missionaries explicit permission to care — and explicit boundaries so they don’t burn out doing it
- Give mercenaries clarity and structure — they thrive when scope is crisp and expectations are visible
- Watch for drift: missionaries becoming cynical (they’ve been ignored too long) or mercenaries becoming disengaged (the work lost even transactional interest)
What I learned from watching that junior grow
Looking back, what made that engineer’s trajectory possible wasn’t just his wiring. It was that the team around him — a mix of people who cared at different levels — created a space where his energy had somewhere to go.
The mercenaries on the team kept things shipping. The missionaries (quiet or loud) kept things meaningful. And the tension between them — the debates about “is this good enough?” — was the engine that drove quality up without grinding velocity to a halt.
If everyone had been a missionary, the team would have been slow, intense, and emotionally exhausting. If everyone had been a mercenary, the product would have been functional but forgettable.
The blend was the point.
A closing thought
The goal isn’t to convert mercenaries into missionaries. It’s not to find a team of people who all care at the same depth.
The goal is clarity — clear enough that missionaries can find meaning in the work, and mercenaries can find structure in it. Clear enough that different levels of care aren’t judged, but channeled.
The best teams I’ve been part of weren’t unified by passion. They were unified by respect — for the mission, for each other’s wiring, and for the reality that building something good requires people who dream and people who ship.
Your job as a leader isn’t to make everyone a missionary.
It’s to make the mission worth caring about — and then trust that each person will bring exactly what they can.
