"Waterfall?”

"Nah, we’re Agile."

"Scrum or Kanban?”

"It’s kind of a blend.”

"How so?”

"We do the worst of each and have a retro about it every 2 weeks.”

Agile engineering has won the software development methodology war.  Outside of government contractors, big banks, and whatever the hell Valve does, "Agile” has come to dominate as the accepted best way to run a software project.  This is not altogether bad:  just as "nobody got fired for buying IBM” in the 70s and 80s, no engineering team will get much of a challenge from directors and executives by announcing that they "do a form of agile.”  And for good reason:  software development is hard because coordination in unbounded knowledge problems is hard.  [The Mythical Man Month](https://www.amazon.com/Mythical-Man-Month-Software-Engineering-Anniversary/dp/0201835959/ref=pd_lpo_sccl_1/139-1897067-8374206?pd_rd_w=kt1vu&content-id=amzn1.sym.116f529c-aa4d-4763-b2b6-4d614ec7dc00&pf_rd_p=116f529c-aa4d-4763-b2b6-4d614ec7dc00&pf_rd_r=P9NH7K2C9KG3GTFWMFC2&pd_rd_wg=I3FMC&pd_rd_r=2eaa01e3-eca0-47df-a736-cd18bb75243c&pd_rd_i=0201835959&psc=1) was rejecting the idea that development systems and technology would solve programming back in the 1960s.  Picking a methodology, any methodology, and doing it well is superior to attempting to pick the right methodology.  Some system is better than no system.

A poorly run system is worse than no system, however, and it’s this state that team members feel most acutely as chaos.  When there is no system, teams will adapt to a functional minimum and find a way to get stuff done.  When a system is running poorly, there’s an awkward powerlessness through the team and in it’s rituals.  Like a first date where both parties have identified that *this ain’t it*, team members go through the meeting and fulfill the form of the ritual without worrying about the function, content to let the timer run out and they can get back to what they’d rather be doing (be that coding or right swiping to find the next one).

Fixing these rituals is tough, but worth it.  Belonging to a team struggling with its process is torture, but when it works the balance of freedom and structure is empowering and a delight to participate in.  To begin to breathe life back into a failed process, teams need to consider 2 competing ideas:  first, that their rituals don’t do anything, and second, that abandoning their rituals will only make things worse.

## Rituals as Cargo Cults

"[Cargo Cults](https://en.wikipedia.org/wiki/Cargo_cult)” sprung up in the South Pacific in the 1880s through World War 2 as previously isolated island tribes made contact with modern cultures.  These contacts brought unthinkable wonders: food in abundance, modern medicine, mass manufactured clothes, and incredible feats of engineering in their ships and planes.  Quite logically a religious element emerged in many cultures:  new rituals and beliefs to bring more fortune to the island from these strange visitors.  

Some of these religious elements were wholesale inventions; others merged existing tribal beliefs into these new encounters.  Some tribes began to worship US service members as minor deities.  Others emerged from deliberate manipulation by foreign visitors to obtain compliance and labor from the locals.  There are apocryphal stories about tribes constructing stone runways and mock airbases to attract the planes of the strange and wealthy visitors.  In any case very real rituals formed and attached itself to very fake beliefs.

Too many teams find themselves members of the Agile Cargo Cult.  Failing to grasp the original problems and spirit of agile development, teams perform the agile rituals that have no effect on their work.  Yet from within the cargo cult, there’s no understanding of the very mundane reality of what’s actually happening in the world around them.  There is no feedback loop to realign the team to their goals and deconstruct their operations.  The very mechanism agile proposes to prevent against this, the retro, has been fully converted into the cargo cult.  The team goes about its business, day after day, week after week, month after month, burning themselves out on meetings, check in, touch bases, stand ups, retros, reviews, endless waves of email and mountains of documents that do not do a single real thing to get a project built and shipped.

## Rituals as Chesterton’s Fence

G.K Chesterton was an English writer, philosopher, and literary critic from the turn of the 20th Century.  He wrote across political, social, and religious issues.  A small-c conservative, Chesterton thought deeply about man, tradition, institutions, and obligations.  One of his more famous insights was about, of all things, a fence.  I’ll let ChatGPT explain it:

> "Chesterton's Fence" is a principle that comes from British writer G.K. Chesterton. It's essentially a metaphor used to illustrate the idea that one should fully understand a system before making changes to it.
> 
> 
> The principle gets its name from an analogy Chesterton wrote in his 1929 book "The Thing". He suggested imagining a fence in the middle of a road. The modern reformer comes by and says, "I don't see the use of this; let's clear it away." To this Chesterton responds that if you don't see the use of it, you are the one person who should leave it alone. However, if you can fully explain why the fence was put up in the first place, and why it's no longer needed, then you may be the right person to remove it.
> 
> This idea has been used to argue that reform should not be made without understanding why the current system was established, what its purpose is, and what the consequences might be if it is altered. This concept applies to many different areas, including law, culture, and technology, and it encourages thoughtful and informed decision-making.
> 

Chesterton’s Fence is sometimes considered a paradox: you cannot remove the fence until you understand why you cannot remove the fence.

At its heart, Chesterton’s Fence is about respect for practices and institutions even if you do not immediately understand their benefit.  Human institutions and practices exist for a reason, and the unseen consequences of change dwarf the assumed benefits.  It is a deeply small-c conservative argument:  assume things exist for a reason, and must be judged for what it prevents as well as what it creates.

Teams should consider that the ‘fences’ that frustrate them so much are there very good reason.  A backlog grooming ritual that decides to skip pointing, to remove timeboxing, or to jettison cumbersome acceptance criteria writing might in fact have been keeping real procedural demons at bay.  Instead of viewing a struggling process as an impediment to success, teams should consider the idea that without those painful meetings their productivity and happiness would be worse.

(As an addendum: Tom Wolfe has a meditation on this same effect about diseases in 1960s called [The Great Relearning](https://matiane.wordpress.com/2021/11/30/great-relearning-20th-century-is-over-by-tom-wolfe/) that also demonstrates this point, although about dirty hippies living in communes instead of Agile development practices.)

## Team Cargo Fencing

Cargo Fencing (a term I just made up) is the active choice of a team to examine their process using both viewpoints.  A team should catalogue their operations and frankly discuss both scenarios.  "What if our process is completely out of sync with reality?  What meetings are theatre?  What ‘stone runways’ are we building?”  This will identify time sucks and calendar black holes that are crushing morale and productivity.  Next, though, the team should look at their same processes as a fence they don’t appreciate the benefits of.  "Why would this meeting exist in the first place?  What could go wrong if we removed it?  What aren’t we aware of because our process protects us from?”  

A team stretching to understand two perspectives at once will develop a deeper understanding of what they are doing and why it matters. By embracing both the Cargo Cult and Chesterton’s Fence mindsets, teams can identify and eliminate ineffective rituals, while preserving the ones that are truly beneficial. The result is a more efficient and effective process that empowers and inspires team members to do their best work.  

In the end, it’s not about tossing every inherited ritual overboard, declaring it a cargo cult, nor is it about clinging onto every established practice like a Chesterton's Fence that's off-limits for change. It’s about empowering teams to not just go through the motions but to truly understand their rituals, to critique their own methods, and to figure out if they’re creating value with their actions, or just going through the motions.

Through the lens of cargo cults and Chesterton's Fence, this article provides a practical framework for understanding and refining your software team's rituals and processes.

Fixing Bad Engineering Rituals: Cargo Cults and Chesterton’s Fence

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.

engineering Posts