How to use improv theatre skills to develop and nurture your team

Here’s a bold statement for you: the best strategic long-term decision that any developer organization can make is to learn how to make things up on the fly. Does that sound oxymoronic? For some it might. But if you’ve read either of my earlier articles about capitalizing on techniques developed by stage improvisers to accelerate Agile teams, you may have a sense of what I mean.

Improv theater may seem like a whimsical activity a long way off from the serious business of developing production-quality code. However, nothing could be further from the truth. Improv is the only art form that requires people to act – impersonating life – with only the tools available that people actually use in life. It is life-skills with added wit, coordination, intelligence, charisma, tactical adaptation, compromise, listening, and courage. It is, in short, distilled super-life. And this is why the use of improv techniques is the most powerful training tool that exists for soft skills development, organizational culture change, personal empowerment, negotiation, leadership development, and public speaking. Which also makes it critically relevant to the software industry. (If you’re skeptical, check out the previous articles for details.)

In this post I want to focus on what organizational culture strategy looks like when it’s informed by the science of improvisation, with five key insights to help you boost your team’s effectiveness.

1. Encourage total communication

A lot of improv looks almost telepathic. Many people watching a TV show like Whose Line Is It Anyway gain the impression that improvisers are natural geniuses of wit. They assume that improv is an activity they couldn’t possibly do because they don’t already do it. What they miss is the immense amount of drilling that improv troupes do together to enable them to interact fluidly, much like members of a professional sports team.

This communication hinges on two things. A) a shared understanding of the patterns that a scene needs to function, and B) a subtext to every action or line of dialog that other players can use to infer what they need to do next. In software terms, this translates into A) a shared grasp of what good code looks like and B) code written in such a way that its intent is transparent. Whether this happens through the use of extensive comments, exhaustively clear variable names, or some other approach doesn’t matter so long as the whole team is using it. When there is both active listening and a purposeful telegraphing of intent, great work can happen.

What does this mean for a leader? You need to encourage your team to build consensus and language over the tools and patterns they use. When post-morteming a project, watch for repeat business phenomena or coding tricks that work or fail and give them names. See if you can get everyone on your team reading the same book or watching the same YouTube videos on the tech they’re using.

2. Leading and shadowing

The kind of seamless cooperation that happens in improv often makes it look as if scenes are just happening and that no one is in control. Sometimes this is true. However, a lot of the time, someone is leading in that they’re providing ideas while they feel they have something to contribute. Other players in the scene follow that lead, waiting for the moment when that person runs out of material or when the scene needs help in some way. At that point they step in and start guiding the story. The player who was formerly leading the narrative then immediately lets go of the control stick. For strong improv troupes you usually can’t tell that this is even happening unless you know what to watch for.

This habit of sharing control extends well beyond the stage. In fact, the closest thing I’ve ever seen to Utopia was an applied improv conference I attended in Amsterdam where I was fortunate enough to get to speak on improv and the brain. A lot of the time the conference seemed like a chaotic swirl of talk and laughter. However, the moment anyone needed a task done such as moving some chairs or clearing a room, everyone immediately switched focus to help. A crowd of hundreds of strangers from over a dozen different countries was able to cooperate like lightning.

When it comes to software, this means that whoever has expertise in a given tool or package is leading while that technology requires focus. As soon as that part of the project ceases to be paramount, that expert hands off control so that someone else can lead the team where it needs to go next. In the world of developers this can be hard to achieve, as those who have acquired control of a project’s direction often feel like relinquishing it will jeopardize results. When leading a team, I’d recommend recognizing and rewarding control-releasing behavior every time you see it.

3. The golden path

Over the course of my improv career, I became increasingly fascinated by what people call ‘long-form’ – the construction of a full-length improvised play, often from a one word suggestion. A good long-form play has multiple characters, a rising narrative arc, and a satisfying conclusion, all achieved without planning or collusion. It was common for audiences to my troupes’ shows to not believe that the work was improvised. They often came up with fanciful theories as to how we’d pulled the stories together.

In reality, the source of our success was far more mundane: practice. Specifically around what made stories work and what made them fail. We realized that strong stories are often underpinned by a certain pattern – the same one that Joseph Campbell identified in his masterwork The Hero with a Thousand Faces. However, we never attempted to slavishly fit our stories to that classic arc. Rather, it served as a compass. No matter where we were in a story, we had a map of where we needed to go. Furthermore, what made stories interesting was how they deviated from the ‘golden path’. When we accidentally followed the path in a play correctly, the result almost always seemed formulaic and dull.

The parallel in Agile development is that you always work toward the ‘right’ way to do a project, without ever expecting your project to be perfect. There is almost always a right way to build out an application of any given kind and it is almost never followed. Reality invariably gets in the way, and that’s okay. It’s something to be cherished, even, as it extends your knowledge of how to work effectively. The trick is to make sure that your team has a shared understanding of what perfect would look like if you could actually pull it off, that they push towards it, and that they know not to freak out if it never happens.

4. The show belongs to everyone

If you’ve been to both improv shows and stand-up comedy, you may have noticed a difference in the air. At stand-up shows the expectation is that the comedians are there to make you laugh. Whoever is on stage is working alone with polished material that we expect to be good. By contrast, an improv troupe have no idea what they’re going to do. Failure is a real option. They are vulnerable and the audience knows it.

This means that the vibe at an improv show tends to be more collaborative. That doesn’t make improv funnier, of course. Stand-up is a far more reliable medium for delivering solid laughs because of the sheer amount of tuning that goes into its preparation. However, it makes improv a warmer, more inclusive experience. It is no accident that the leads of most family comedies produced in Hollywood are improvisers by training, from Robin Williams to Mike Myers, to Jim Carey, and countless more.

The secret of that inclusive feeling is that improvisers make it clear at the start of every show that they depend on input from the audience. That’s what enables them to subsequently struggle while having that still be a fun experience for all. (By contrast, nobody likes to watch a struggling stand-up comedian. It’s just painful.) In effect, improv works because control of the show is shared between performers and audience. Everyone has an interest in making it work.

Similarly, advertising vulnerability up front and establishing a pattern of mutual cooperation with all stakeholders in a project is central to any successful Agile effort. In some sense, ‘ownership’ needs to be shared between everyone involved. Occasional failure needs to be accepted as part of the agreement, along with a collective will to resolve whatever comes along.

In the software business it of course remains true that code legally belongs to whoever is paying for it. However, a company that attends to that extrinsic reality alone and not the motivated act of teamwork that backs any effort is likely to struggle to retain staff, keep costs down, or deliver good work. The sensation of ‘a job well done’ must belong to everyone who takes part. And for that reason, there’s a principle at productOps that captures this idea: we’re not a vendor. Clients who treat us as vendors rather than collaborators don’t tend to last very long.

5. Play is serious

My final point in this series is my most significant, both in terms of import, but also in terms of how frequently it’s overlooked or misunderstood. And it is this: the act of human play, as manifested by improv troupes and sometimes by software teams, is the number one determinant of success. Let me say that another way: unless you know how to be silly and make light of what you’re doing, you are not being professional.

The fact that improv performers are silly, and that their ability to be funny matters, is easy to see and understand. But how can I level the same standard at software development? It’s not as if working code is measured in terms of how many laughs it generates.

There are two tightly related reasons why laughter and social play are vital. The first has to do with cognition. Play is the mechanism by which animals naturally learn. Behavioral experiments have shown that if you remove the opportunity for play from a young mammal’s environment while keeping all else the same, it never develops the ability to adapt to threatening stimulus or overcome fear. Humans have retained the ability to learn throughout adulthood because of the massive adaptive benefit it affords us. And it necessarily follows that we are only making effective use of this aptitude when we can play. The will to play, simply put, is the root of courage, and courage is a requirement for any business that wants to grow.
The second reason silliness is vital is because we are designed to play and learn collectively. It is a huge part of how we bond. Humans have laughter: a signalled, contagious emotional response to learning experiences that appears nowhere elsewhere in the animal kingdom. When we experience a mental reframing event that comes without downside consequences, we voice our surprise and relief as a laugh. We are saying: we encountered something that might have been scary that turned out to be educational instead.

By producing an audible reaction we invite others to join us, making the learning experience a collective one. But not only does laughter enabled shared growth, it also lowers social risks. Environments where people can laugh are ones where people can take on new behaviors or skills and feel socially safe doing so. In software development, as you might have noticed, the need to take on new skills shows up remarkably frequently.

As a leader, if you cannot create an environment in which your developers are relaxed enough to laugh and motivated to laugh together, you will usually lose staff and money, miss deadlines, and deliver mediocre work. On the other hand, if you can create a workplace that feels fun, you will not only have developers willing to take the risks necessary to succeed, you will also generate an abundance of trust and loyalty along the way.

Fostering play is not the only way to encourage excellence, of course. If your staff cannot escape, you can always motivate them to impressive acts through fear. But this approach is highly volatile and relies on your continued exercise of top-down control. Also, forget about your developers ever learning anything new or having your back.

I’m fortunate that I find myself in a company that understands these five principles and follows them. For much of my career, that has not been the case. productOps takes care to nurture talent and to create a safe space for it to thrive. But for those of you who aren’t in such a place yet, I encourage you to start building one right now, wherever you are, with whatever help you can find. And if that won’t work, maybe you should consider joining us. For the obvious reasons, productOps is growing. And who knows, we might need your skills in our troupe!