The Captain, Quartermaster, and Crew: Leadership Lessons from Pirate Ships for Product Teams

by Kristen DeLap


This is the second article in my Pirate Product Teams Series, following The Pirate Code: What 18th Century Crews Can Teach Modern Product Teams.

The first essay explored how pirates built trust and order through shared agreements, and this one dives into the people side. You’ll learn how the structure and leadership of a pirate ship mirror the balance of roles on a modern product team.

The connection might surprise you: both are high-stakes environments powered by collaboration, specialization, and clarity of purpose. And both succeed (or sink) based on how well each member understands their role in the mission.

pirate ship on a horizon at sunrise

🧭 The Captain: Vision and Direction

When you imagine a pirate captain, pop culture gives us a certain image — the loud, power-hungry commander yelling orders through a storm. But historically, captains were elected. Their authority was limited, and their success depended entirely on earning the trust of their crew.

Sound familiar?
That’s the product manager.

A captain’s job was to set the course, define the mission, and rally the crew around a shared vision. The product manager does the same: articulating what the team is building, why it matters, and where they’re headed.

A captain’s vision is what rallies the team — it is the North Star. A product manager is similarly creating the vision for how this product will serve and delight users. The product manager is setting the product vision, just as a pirate captain sets the mission vision. The product vision is the foundation of the product but also of the team. It is a guide for all team members and stakeholders, ensuring everyone is working toward the same long-term objective of what the product will become and the impact it will have.

On a product team, a strong product vision guides decisions, aligns priorities, and keeps the team inspired. The best ones share three traits:

  1. Centered on the problem, not the company.
    As Radhika Dutt writes in Radical Product Thinking, a good vision should outlive your org chart. It’s about the change you want to see in the world, not your market position.

  2. Tangible and visual.
    A clear end state that the team can picture — not just a slogan. “Access to the world’s information in one click” (Google’s vision statement) works because you can see it.

  3. Meaningful to both team and users.
    “Be the best in the industry” motivates no one. “Solve this real, human problem” does.

A product vision should be referenced often — like a compass, not a poster. If every opportunity fits under your vision, it’s too broad. The best visions help you say no as confidently as you say yes.

⚓ The Quartermaster: Execution and Order

If the captain sets the course, the quartermaster keeps the ship afloat. On pirate ships, the quartermaster handled day-to-day operations — provisioning supplies, settling disputes, and ensuring tasks got done.

In today’s product teams, this role often looks like your scrum master, delivery lead, or agile coach. They ensure work flows smoothly, dependencies are managed, and communication stays open.

The separation between captain and quartermaster mattered. One led with vision, the other with systems. This division of duty insures that those two very different skillsets are not in conflict. It is unlikely the person who can think big and broad and set a vision is the same person who wants to manage the minutiae of day-to-day work. A major part of a successful cross-functional team is understanding people’s strengths and letting them play to those. They should understand each other’s work, and respect its place in the team, but you don’t want a visionary captain responsible for tarring holes in the bilge.

The same holds true for product organizations.

  • The PM shouldn’t be buried in Jira tickets.

  • The delivery lead shouldn’t have to pitch the long-term strategy.

They’re partners in motion: one scanning the horizon, one checking the ropes.

And yes, likely, if pirate ships had daily stand-ups, the quartermaster would have run them.

🧑‍🔧 The Crew: Cross-Functional Expertise

Pirate ships were remarkably diverse places. Crews included sailors, navigators, carpenters, cooks, and gunners — many from different nations, languages, and backgrounds. What united them wasn’t uniformity, but shared purpose.

That’s the product team.
Designers, engineers, researchers, analysts, QA — all specialists, each critical to the mission.

No one could do everything, but everyone needed to understand how their craft contributed to the whole. That mutual respect kept ships efficient, and alive.

In modern teams, we sometimes over-index on “T-shaped” skills and forget that deep expertise is valuable too. The goal isn’t for everyone to do everything, but for everyone to see the system, and to understand how their work ladders up to the collective goal. You must respect the skill — or occasionally not the skill, but just the sheer grunt work or heavy lifting — of your teammates and how it helps you and your shared goals.

🤝 Respecting Roles, Building Trust

The real power of a well-run pirate crew — and a great product team — lies in clarity and respect.

When people know who leads, who supports, and how decisions are made, it builds psychological safety. Misunderstanding roles leads to duplicated work, frustration, and burnout.

Think of role clarity not as hierarchy, but as choreography. Each person moves in rhythm with the rest of the crew — confident in what they’re responsible for and supported in doing it well.

So whether your “ship” is a distributed team, an AI-driven startup, or a legacy platform mid-transformation, the same principle holds:
Define your vision. Empower your executors. Respect your experts.

That’s what kept pirate crews afloat — and it’s what keeps great product teams sailing forward.

If you missed the first part of this series, check out The Pirate Code: What 18th Century Crews Can Teach Modern Product Teams, which explores how trust and shared norms shaped pirate culture — and what that means for building stronger teams today.


🏴‍☠️ The Pirate Code: What 18th Century Crews Can Teach Modern Product Teams

by Kristen DeLap


When you picture a pirate ship, you might imagine chaos: rum-fueled arguments, shouting over crashing waves, and a parrot squawking orders from the captain’s shoulder. But historically, pirate crews were democratic, effective, and organized. In short, they were good teams.

Therefore, they have a lot to teach us about how to run modern product teams.

Both pirate ships and product teams operate in high-stakes environments, often with limited resources and enormous pressure. Success depends not on who shouts the loudest, but on clarity of roles, strong working agreements, and deep trust among the crew.

And the key to holding all that together?
The Pirate Code.


The Pirate Code, Explained

Long before "Agile" or "Scrum" hit the scene, pirates were creating their own ways of working documents. Known as the pirate code, articles of agreement, or ship’s charter, these were formalized rules crafted collectively by each crew before setting sail.

These agreements covered:

  • Roles and responsibilities

  • Behavioral expectations

  • Reward distribution

  • Conflict resolution

Each crew tailored its code to their mission, signed it together, and often posted it in a visible place on the ship. It wasn’t top-down governance — it was an alignment tool, designed to keep everyone rowing in the same direction (sometimes literally).

Sound familiar?


Working Agreements: Then and Now

Pirate codes may have included rules about rum rations or gambling on deck, but the goals were timeless:

  1. Prevent in-fighting

  2. Maintain loyalty

  3. Create shared understanding

Today, we call these "ways of working" or "team agreements," and they do the same thing. When done well, they provide clarity and consistency across your product team — especially when it’s cross-functional and distributed.

Here are a few examples of how pirate-era challenges show up in modern teams:

Cramped Quarters = Zoom Fatigue

Pirates lived shoulder to shoulder in hammocks below deck. Your remote team might not be sharing salted pork and sea air, but working in constant Slack threads and back-to-back meetings isn’t far off. Understanding the expectations of those around you is paramount to not causing additional frustration or resentment.

Crew Norms

Pirate codes were incredibly specific, even outlining bedtimes and chores. Your team might align on “no meetings before 10am Eastern,” or “acknowledge Slack messages by EOD.” These seemingly small decisions reduce tension and improve flow.

Rewards and Risks

Pirates clearly defined how loot was split and what happened if someone was wounded. Similarly, modern teams need clarity on things like:

  • How success is shared

  • What happens when priorities shift

  • Who owns what (and when)


Six Things to Include in Your Product Team’s Pirate Code

If you're writing or revisiting your team's ways of working doc, consider covering these six areas:

  1. 🧭 Principles & Values
    What’s your product’s mission? What values or principles guide how you work together and the decisions you make?

  2. ⚙️ Processes & Workflows
    How does work get done — from research and design to QA and release? What does a proper handoff look like?

  3. 📣 Communication & Collaboration
    What Slack channels exist and how should they be used? What is the cadence of meetings and who needs to attend? How is feedback shared?

  4. 🛠️ Tools & Technology
    Which platforms does your team use for design / project management / analytics / etc. and how do they connect or integrate?

  5. 🧑‍✈️ Roles & Responsibilities
    Who owns what? What’s the decision-making structure?

  6. 📜 Norms & Expectations
    Think of these as the team’s behavioral agreements — camera policies, emoji etiquette, response expectations, and escalation paths.

Also, don’t underestimate the power of naming your behaviors. A well-phrased motto like “Talk less, do more” or “Find the yes” can become a north star for your team culture.


Why Trust Is the Real Treasure

The real goal of all of this? Trust.

You can’t build a high-performing product team without it. Especially in remote or hybrid environments, trust is what allows teams to take risks, speak candidly, and show up as their full selves. The heart of the pirate code is building trust and loyalty within a crew. 

To understand how that plays out, we can use the model of the Trust Equation, coined by The Trusted Advisor:

Trustworthiness = (Credibility + Reliability + Intimacy) / Self-Orientation

Let’s break it down: you build trust by increasing:

  • Credibility = your expertise and accuracy

  • Reliability = your consistency and follow-through

  • Intimacy = your emotional safety and connection

And decreasing:

  • Self-orientation = how much you're focused on yourself vs. the team

How? Build trust by:

  • Delivering consistently

  • Creating space for vulnerability

  • Prioritizing team success over ego

Every time your team upholds the shared code — by following through, giving honest feedback, or asking for help — you're reinforcing a culture of trust.



Bringing It Ashore

The Pirate Code wasn’t just a set of rules — it was a survival strategy. It enabled a diverse crew to live, work, and thrive together under pressure.

Your product team may not be chasing treasure, but you are navigating complexity, uncertainty, and constant change. A clear, living ways-of-working agreement can be your anchor.

So take a page from the pirate playbook:

  • Write your agreements together.

  • Make it visible.

  • Revisit it regularly.

You won’t just be guiding behavior; you’ll be building the kind of team that’s ready to weather any storm.