After graduating college in 2007, I followed the most obvious path for a slightly awkward and too-clever-by-half anxious nerd:  improv comedy.  I threw myself into class after class at the Upright Citizens Brigade Theatre, then the biggest and most heralded comedy theatre in New York.  A half decade and a few thousand dollars of improv classes later, it was clear that a SNL audition was not in my future.  Still, that experience have given me a creative experiences and toolkit I continue to pull from as an engineering leader.

My favorite framework for thinking about Improv performers was “Pirate, Robot, Ninja”.  “Pirate, Robot, Ninja” began as a forum post from the wonderful teacher and performer Billy Merritt.  His original post outlined the archetypes of performers as he saw them.  Over the years, he’s expanded on that original post in interviews and even a [book](https://www.amazon.com/Pirate-Robot-Ninja-Improv-Fable/dp/1099142245) (co-authored with the equally talented Will Hines).  

As quoted in [LA Weekly in 2012](https://www.laweekly.com/pirate-robot-or-ninja-ucb-vet-billy-merritts-theory-on-the-three-types-of-improv-performers/), Billy describes the profiles of Pirate, Robots, and Ninjas as such:

> "A **pirate** is happiest when he swings on board a boat ready to attack and has no idea what will happen next," explained Merritt. And that is what a pirate improviser does. S/he is fearless, even reckless. Pirates initiate scenes with a strong, crazy choices and the other players work to justify and support them. You need the energy and creativity of a pirate to drive a ½ hour improv show.
> 
> 
> **Robots** are all logic. "A robot player is always analyzing, running the program of the scene," said Merritt. "S/he is constantly bringing the audience back to reality and asking, 'what is my character and how would they react truthfully to this?'" Every scene needs the straight person to counter the pirate and define what is funny so the scene doesn't veer off into crazy-land.
> 
> "There is just as much honor to not being the main player in a scene," Merritt assured. "The **ninja** is the one who steers the scene here or there, the great justifier, the one with no ego. I used to use the word Samurai, but a Samurai is all about glory. For the ninja, the glory is running away, getting in getting out unnoticed. A ninja-like player edits and you never see them edit. The ninja is the one who connects all the scenes together".
> 

As a CTO, I’ve seen these same archetypes in software engineering.   Software engineering might not have as many company meetings that start with “Everybody get in here!” or employees named Johnson, but Billy’s field guide is a valuable tool for software leaders to understand their teams with.

## Pirate, Robot and Ninja Engineers

### Pirates

Pirate Engineers thrive in the melee of “Get Stuff Done.”  For the pirate engineer, work isn’t real until it’s in production solving a real problem.  Technology is the sword of the pirate engineer; it matters less how sharp it is or expertly crafted, so long as it does the job.  Pirate engineers have a bias for action and are happiest when they are able to dive into problems headfirst, quickly iterating and finding solutions. They are fearless, often taking risks that other engineers might shy away from, and their enthusiasm can be contagious, inspiring their teammates to think outside the box and push boundaries.

Pirate engineers are crucial for startups and ‘go-fast’ projects, where quick decision-making and the ability trump other concerns. They are the first ones into a problem. Their passion for getting things done means they don't get bogged down in analysis paralysis or endless debates about the "perfect" solution.  In fact, they might sometimes come off as technically limited, since their bias for action leads them to prefer tools they already know, proven technologies, and lean solutions.

Pirate engineers can sometimes struggle with long-term planning, documentation, and organization. Their tendency to prioritize immediate action over careful consideration can lead to technical debt and challenges in scaling their solutions. Platforms built for one set of requirements are naturally going to struggle as those requirements change, but the pirate’s emphasis on efficiency and speed can lead to more limited solutions long term.  To maximize their potential, it's essential to pair pirate engineers with team members who complement their strengths and can help mitigate their weaknesses.

In a team setting, the pirate engineer's fearlessness and energy are assets that push projects forward and break through cycles of endless plannig, but can be frustrating for more process or technically driven team members. It’s crucial to ensure that their penchant for bold, sometimes reckless decisions is balanced by the more methodical, detail-oriented approach of their robot and ninja counterparts.

### Robots

Robot Engineers are the masters of patterns, the priests of predictability, and the architects of system-level operations. They flourish when working with clear inputs, generating well defined outputs, and embracing any uncertainty they face as an opportunity to refine and optimize structures for the future. Robots leverage frameworks, best practices, and well-established processes to deliver top notch work.

While they may require some initial cultural programming, once they are properly set up, robot engineers operate like well-oiled machines. They efficiently manage tasks, tests, performance tracking, and more – all within the structures they so meticulously design and maintain. Structure is not only the playground of the robot engineer, but also their canvas, where they paint a masterpiece of organization and stability.

In a team setting, robot engineers bring a sense of order and reliability to the development process. Their passion for best practices and process-driven approaches ensures that projects are built on solid foundations, paving the way for long-term success. They thrive in environments where clarity and consistency are valued, and they often become the go-to experts on a team for questions related to systems, patterns, and optimization.

However, it's essential to recognize that robot engineers may struggle in situations that demand rapid adaptation or lack well-defined structures. To maximize their potential, it's important to pair robot engineers with team members who can balance their focus on structure and process with a more flexible, action-oriented mindset.

### Ninjas

Silent. Deadly. Unappreciated?

Ninjas are a mysterious and elusive breed of engineer. They don't quite possess the wild energy of pirates, but they bring a deadly precision to the chaotic melee of software development – always prepared for whatever challenges may arise. They aren't robots, yet they effortlessly blend into their surroundings, leveraging the resources around them until the perfect moment to strike presents itself. Ninjas are the master assassins of their teams: they solve problems before anyone even realizes there's an issue. They fix crushing vulnerabilities before it becomes a headline on HackerNews. They share their wisdom subtly, teaching others without letting them know they're being guided.

On teams, ninjas make their impact quietly, through their uncanny ability to anticipate problems and deploy solutions before they escalate. They're the silent guardians working behind the scenes to ensure the team's success. Ninjas excel in identifying operating patterns and drawing on their vast technical knowledge to resolve issues such as version upgrades, optimizing test suite performance, and implementing efficient design patterns. They're always on the lookout for ways to cut costs, streamline processes, and enhance code quality.

Culturally, ninjas bring a unique blend of humility and expertise to a team. They understand the value of collaboration and are often the ones who mediate conflicts or offer support during challenging moments. Their quiet confidence enables them to share their knowledge and experience without overshadowing others, fostering a sense of unity and shared purpose within the group. They're skilled at creating an environment where everyone feels empowered to contribute and grow, all while remaining virtually invisible.

Ninjas can find themselves frustrated on some engineering teams, with pirates creating leaving a trail of wreckage for the ninja to clean up and the robot seemingly locked into process to the point work grinds to a halt. Ninjas can struggle to see the big picture: the reasons why a team might ****want**** to defer certain kinds of work or take on technical debt.  It’s not that Ninja’s are perfectionists, but they can preemptively worry about solutions that cause more work later… understandable, since they’re usually the ones doing it.

## Tensions

Conflicts among pirates, robots, and ninjas can arise from their distinct approaches to problem-solving, communication styles, and priorities in a software engineering team. Each archetype has its own strengths, but their differences can sometimes lead to tension and disagreements. Recognizing these potential conflicts can help create a collaborative and harmonious environment.

Pirates, with their action-oriented nature, may clash with robots who prioritize structure and predictability. Pirates love to dive headfirst into challenges, making bold moves that could disrupt established processes and methodologies. This can drive robots nuts, who value order and consistency. Robots might see pirates as reckless and disruptive, while pirates may view robots as overly rigid and resistant to change. This tension can manifest in disagreements over project timelines, technical approaches, or the adoption of new tools and technologies.

Ninjas, the silent and adaptive problem-solvers, may find themselves navigating the challenges created by both pirates and robots. While ninjas are masters at resolving issues before they escalate, their contributions can sometimes be overshadowed by their flashier counterparts. They might also end up constantly adapting to the inefficient systems created by robots or compensating for the lack of systems resulting from pirates' actions. Pirates might think ninjas are too passive, lacking the drive to make bold decisions or take control in critical situations. The ninja engineer can feel like they’re the glue keeping ‘this whole thing’ from falling apart, and the emotional burden of that style of work can lead to individual burnout without the rest of the team realizing it.  

## In Harmony

When pirates, robots, and ninjas work together, they create a mix of software engineering talent that leads to remarkable outcomes. In this balanced state, the energy and creativity of pirates, the orderliness and precision of robots, and the adaptability and foresight of ninjas come together to form a cohesive and efficient team.

Imagine a pirate engineer introducing a bold solution to a complex problem. The robot refines the idea, ensuring stability and alignment with best practices, while the ninja anticipates potential issues and suggests adjustments, optimizing the solution. The unique strengths of each archetype complement one another, creating a well-rounded team that tackles challenges effectively and delivers high-quality results.

“Pirate, Robot, Ninja” also works as a coaching framework.  Asking a pirate engineer to “Think Like a Robot” can contextualize the endless list of procedural concerns and process that can cause the Pirate’s eyes to glaze over.  Telling a team of Robots do to do a Pirate Sprint will shake up routine and surprise the team with just how much they’re capable of when they hoist the colors and feel the salt spray of the sea.  Ninja’s can be coached to build and share their work in ways that the Pirates and Robots on their team will understand and appreciate.

## Conclusion

I’ve found the “Pirate, Robot, Ninja” valuable again and again to understand a the dynamics of technical teams and how best to manage the personalities on them.  Yes, there are limitations to analogy and of course there are gaps in a 3 role archetype that risk going down a role-playing game rabbit hole (”Okay, so “Monks” are supportive like Ninja’s but combat experts like Pirates…”).   Still, the framework is a fun, easy way to coach some not-so-obvious approaches to work in a fun and vibrant way.

***Disclaimer: The author of this piece is most certainly a pirate who, through a lot of mistakes, has learned to understand the robot and is infinitely indebted to the ninjas on his team.***

Pirate, Robot, Ninja is a framework for thinking about the different archetypes of engineers. It's a useful tool for software leaders to understand their teams with.

Engineering Archetypes: Pirates, Robots, and Ninjas

A quirk of my career is that I've found myself leading engineers without ever having been led. I was constantly proposing, implementing, and coaching things that I myself had never done or been part of a team that had done. In my first job, fresh from college, I was an engineer on a 3-person team that did development by executive whim. At my second job, I was part of a duo of programmers at a micro-subsidiary of a multi-billion-dollar media company. I didn't have sprints or product roadmaps or even real management. That role shifted and morphed into what would become TeePublic. The freeform approach to engineering was fine initially, but as TeePublic grew past a healthy [Conway](https://en.wikipedia.org/wiki/Conway%27s_law) size, I was tasked with implementing concepts I'd never experienced.

I knew there was a better way to work, but that perspective was heavy on faith and light on experience. We stumbled through introducing basic concepts like stories and sprints, some with mixed results. Too often, I'd read about a management or process concept that promised to solve all our problems, introduce them to the team, and fail to make a difference with them. But if you've never been part of a well-run product process and are evangelizing agile to an equally new team, how can you learn? What group can teach you how to run efficient and valuable engineering processes if you've never lived it?

## _Ghostbusters_ and the Domino Theory of Reality

_Ghostbusters_ starts with a trio of suspect academics speculating that ghosts might exist. One hundred minutes later, they're on top of a Central Park West high-rise facing off with a Sumerian god while a 100-foot-tall confectionery mascot scales the building.

That's a journey.

All fiction asks for a suspension of disbelief—the compact between the audience and artwork that, yes, none of this is real and we're all just going to go with it. If the art asks too much too fast, the audience can reject the premise.

The secret to _Ghostbusters_' narrative is that it never asks for too much suspension of disbelief too quickly. Consider how the movie builds off our base reality of “Ghosts aren't real.”

- **Ghosts aren't real.**
- **Ghosts might be real.**
- **Ghosts are real.**
- **Ghosts can be scientifically understood and studied.**
- **Ghosts can be trapped using scientific methods.**
- **There is a public need for ghost trapping services.**
- **Ghost problems are widespread and significant.**
- **The ghost problem escalates to a potential apocalypse.**
- **The Ghostbusters are essential to prevent the apocalypse and save the world.**

That's the audience journey. All the other plot elements and jargon—the proton packs, “Class 5 free roaming vapor,” a Sumerian god possessing someone via refrigerator—are embellishments on the core journey. The lore works because the film expertly guides the audience through each step of deviation from our base reality and never asks for too much suspension of disbelief at any one point.

This wasn't an accident. Director Ivan Reitman was well aware of what he was doing.

> I called it my **domino theory of reality**. If we could just play this thing realistically from the beginning, we'd believe that the Marshmallow Man could exist by the end of the film.
- Ivan Reitman to [Vanity Fair](https://www.vanityfair.com/hollywood/2014/06/ghostbusters-making-of)
> 

## Stories, Scrums, Retrospectives… Mass Hysteria!

Building processes for teams requires its own domino theory of reality. Bringing too many changes too fast overwhelms people. It fails to create the space for the team to understand and implement the component mental models and tasks needed to make the process work.

I learned firsthand how easy it was to overwhelm teams with new processes, concepts, and jargon. I would roll into meetings explaining our new plan of story writing and backlog grooming and pointing. My team looked at me like I was nuts. I tried to unload everything, about everything, all at once. This was the Ghostbusters equivalent of starting the film by breaking the fourth wall, with an unfiltered Dan Aykroyd explaining, “Ghosts are real, we have these nuclear-powered laser guns to catch them, and we're gonna go fight Marshmallow Godzilla to send a Sumerian god back to its dimension. Make sense?”

In retrospect, like Ivan Reitman did, I needed to go step by step. Domino by domino.


## Domino Theory of Reality for Teams

### 1. Start with the Base Reality

> [Back off man.  I'm a scientist.](https://www.youtube.com/watch?v=M89l7pX5gzc)
> 

Teams need a shared understanding of how the world works to collaborate. On successful teams, individuals are closely aligned in how they think about workflows, problems, communication, and team operations. Struggling teams are often the result of the collective misunderstandings of individuals on how the team operates. Introducing new ideas to an aligned team is exciting; introducing new ideas to a misaligned team is chaos.

Ensuring that all team members share the same 'base reality' provides a common starting point. The team should be, minimally, aligned on where they write documentation, solicit feedback, and commit code. What meetings already exist? More established teams might also have workflows around writing product and technical specs, testing requirements, or retrospective reporting. Some of these things are likely already explicit and obvious to the teams; others might be implicit or haphazardly implemented. In either case, make sure the team members have a shared understanding of the basics of how they'll operate.

The key is aligning individuals on the team. Establishing the base reality is getting team members to align how they expect to work through problems and collaborate with how others on the team expect to work through problems. This is not the same as aligning individuals with each other; it's more about aligning individuals to a common standard.

### 2. Embrace Incremental Progress

> [We've never had a completely successful test of this equipment](https://www.youtube.com/watch?v=ZJVgfDnjkko)
> 

Teams are held back not just by a lack of vision, but by having too much vision too soon. Overloading a team with a picture of the future can prove overwhelming or distracting. Agile development values iteration and incrementality, and we need to embrace these principles when developing our teams as well. But rather than laddering up our product, we're laddering up a team's confidence in themselves and what they believe is possible.

At each point, we need to ask, “Now that the team believes this about themselves, what do we want them to believe next?” Once a team experiences an aha moment where they see the process creating momentum instead of draining it, we want to challenge them with the next step. A team that's just realized the value of clear acceptance criteria is ready to believe in the value of testing in a way that a team whose manager dictates test-driven development, regardless of context, is not.

### 3. Successful Teams Look Different

> [If there's a steady paycheck in it, I'll believe anything you say.](https://www.youtube.com/watch?v=NFX4fmldZFs)
> 

Teams and individuals have different levels of interest in team process. Some of the best engineering leads I've worked with had to be dragged into agile practices. Some of the least productive engineers I've seen hid behind a strict adherence to rituals and record-keeping. This goes for teams as well. A small, close team might thrive with daily standups and collaborative backlog grooming. For another team, whose engineering purview is too broad or skill gaps too wide, the same rituals could be emotionally draining and counterproductive.

Our lead engineer from above, once bought in, was a pillar of his team. That team's standups and sprint plans looked a little bit different than other teams, but because the team adapted rituals to support their unique strengths and weaknesses, the team thrived, and their output rose.

Process and rituals are tools, not outcomes. Understand the broad goals and artifacts you want your team's culture to achieve, coach them on the trade-offs of workflows and tools, and empower them to adapt it to their existing people and culture.

### 4. New Process Is a Grind

> [Everything you're doing is bad.  I want you to know this.](https://www.youtube.com/watch?v=Lbyw0MVbniE)
> 

Now, the bad news:  [reboots are hard](https://www.youtube.com/watch?v=AHUV8QLpEAc), whether it's a 1980s movie franchise or an engineering team's workflow. Agile development books often promise instant turnarounds and enthusiastic teams that immediately see value. Culture is better understood as the inertia of a team, and changing that inertia requires force.

Expect the first couple of meetings to be hard. You will work through a fraction of the tickets you want to. You will ask specific questions about a project only to be met with persistent silence. Team estimates for work will be either “it's pretty easy” or “we have no idea,” with nothing in between. Team velocity will dip. Doubt might set in—within the team or even yourself.

But stick with it! Each domino gets easier and easier, with leaps of belief and capability greater with every successful iteration. I've seen teams that were completely flummoxed estimating a single ticket later effortlessly collaborating on stories and communicating context without a second thought. The only way that happens is through the hard work of a team in rebuilding their collaborative culture, step by step, domino by domino.



## Seeing it Through

> [We came, we saw, we kicked its ass!](https://www.youtube.com/watch?v=xZw9hGdW0FE)
> 

Transforming teams and processes isn't about overnight success; it's a journey, much like the Ghostbusters' gradual escalation from skepticism to saving the world. The key is to establish a shared base reality, introduce changes incrementally, and adapt processes to fit the unique dynamics of each team. It's a grind, and success doesn't come without effort or missteps. But, step by step, specter by spook, teams build the confidence and capability needed to thrive. With patience and persistence, the rewards are worth it for the team, their leaders, and the organization. It'd be great if teams worked perfectly from the start, but that's rarely the reality engineering leaders face. It's up to you to step in. Why? Because [sometimes, shit happens—someone's gotta deal with it. And when it does, who ya gonna call?](https://www.youtube.com/watch?v=mQHSXwHpKpk)

Learn how to implement engineering team change management from the best, the beautiful, the only — Ghostbusters.

leadership Posts