Spooked: Ghostbusters, Change Management and the Domino Theory of Reality
A quirk of my career is that I've found myself leading engineers without ever having been lead. I constantly was proposing, implementing, and coaching things that I myself had never done or been part of a team that had done. My first job, a fresh from college engineering on a 3 person team, did development by executive whim. At my second job, I was as 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 would what become TeePublic. The freeform approach to engineering was fine initially, but as TeePublic grew past a healthy Conway 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 introducing agile to an equally new team, how can you learn? What group can teach you how to run efficient and valuable engineering process 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. 100 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 Ghostbuster's 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 Babylonian god [Ed: Sumerian] 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
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 process, 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
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 collected 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 team expect to work through problems. This is not the same as aligning individuals with each other; it's more like aligning individuals to each other.
2. Embrace Incremental Progress
We've never had a completely successful test of this equipment
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 ah-ha 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.
3. Successful Teams Look Different
If there's a steady paycheck in it, I'll believe anything you say.
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 tradeoffs of workflows and tools, and empower them to adapt it to their existing people and culture.
4. New Process is a Grind
Now, the bad news: reboots are hard, 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 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 ever successful iteration. I've seen teams that were completely flummoxed estimating a single ticket will be effortless collaborating on stores and communicating context without second though. The only way that happens is the hard work of a team in rebuilding their collaborative culture, step by step, domino by domino.
Seeing it Through
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?