One of the things I miss most in quarantine is going to see live improv comedy. As often as I could, I used to go see shows at New York City’s Upright Citizen’s Brigade theater and lose my mind laughing at the incredibly talented improvisers there. I even took a few improv classes to try it out myself. On top of being painfully funny, improv has taught me lessons about communication, teamwork, and creativity that I’ve found extremely helpful to apply to my work in software engineering.
Improv isn’t easy, but its principles are simple. The only rules are:
- Listen
- Say yes
- Advance the scene
Active listening is an underrated and undervalued skill. We all know we should do it, but oftentimes we’re merely waiting for our turn to speak or rushing to assert our own ideas. Improvisation emphasizes paying attention, staying present, and interpreting intent.
Listening to your teammates is perhaps the most important part of improv. Stephen Colbert, who got his start in improv, said:
“There are very few rules to improvisation, but one of the things I was taught early on is that you are not the most important person in the scene. Everybody else is. And if they are the most important people in the scene, you will naturally pay attention to them and serve them.”
Serving your fellow improvisers—or, in this case, your colleagues—requires setting aside ego, embracing humility, and placing trust in others.
In improv, neglecting to listen to a fellow performer means the scene won’t make sense. In programming, neglecting to listen to a coworker leads to missing valuable context or information, which often leads to making incorrect assumptions and even taking unnecessary risks.
Improvisers avoid choices that hinder progress such as discouraging their teammates, shooting down ideas, or being contrarian. Instead, they make a habit of accepting the reality with which they are presented.
The Agile method of software engineering is a world-building exercise that is, in some ways, uncannily similar to improv. It advocates for responding to change rather than following a plan and it values individuals and interactions over processes and tools. Its reaction-and-response approach generates solutions that likely could not have been predicted at the beginning of the process.
Many of the skills valued by both improv and Agile come into play during the brainstorming process. A brainstorming session among colleagues requires a back-and-forth exchange of ideas and feedback. Programming is only possible when engineers are open to hearing new ideas—coding cannot progress if proposals are always struck down.
Saying yes to an idea does not necessarily mean endorsing it as a great idea; it only means accepting the idea as valid and following it to see where it may lead. No idea is great in and of itself—rather, a collection or evolution of ideas and the changes that result from them can lead to something great. Great results can emerge even from poor suggestions. Even if suggestions don’t end up working out, making a habit of exploring them encourages collaborative sharing of ideas.
At its core, improv is not actually about making jokes or being funny—it’s about cooperative creation. When people step outside their comfort zones and let go of their limiting assumptions, rather than being critical or analytical, it enables a connection between them that leads to building, development, and invention.
There is a concept in improv called finding the game, which means finding the crux, the pattern, the thing that is interesting or funny about a scene. The UCB Theatre’s motto is Si haec insolita res vera est, quid exinde verum est?: “If this unusual thing is true, what else is true?” An improviser finds the game of the scene by identifying what is weird/remarkable/funny, then taking action to follow the implications to their natural, and often comical, results.
In software engineering, finding the game is analogous to problem-solving. When solving a technical issue, you have to identify a bug or roadblock before you can resolve it. This requires tackling challenges with creativity, flexibility, and open-mindedness.
Veteran improviser Colin Mochrie said:
“Embracing failure is one of the beautiful things about improv. If the scene is going well, great. But if something goes wrong, sometimes it can be even better. So, it’s just basically relaxing and dealing with whatever is going wrong at that point.”
In coding, like in improv (and everything else in life), mistakes are inevitable. Judging those who fail, including (and especially) yourself, is neither kind nor productive. Pushing past the discomfort of failure is essential for growth, and mistakes can often lead to revelatory discoveries.
A supportive, encouraging workplace environment is one in which the whole team is thought to have collective ownership over the project—that means the successes as well as the failures. This is why a blameless culture is ideal, especially in postmortems. Blame is a variation of saying, "No": we cannot say what someone did was not supposed to happen because there is no such thing in reality as 'supposed to happen'. Blame is a wasted effort, like regret. In a culture where mistakes are forgiven, these experiences become lessons learned. Embracing a challenge turns an obstacle into an opportunity.
Improv host Aisha Tyler also attested to the valuable lessons taught by failure:
“Killing doesn’t make you funny. It’s only bombing that makes you funny. […] When you bomb, you really have to reexamine every creative choice you’ve made and think about if it was the right one.”
A tendency to overthink or overanalyze can cause work to feel chronically stressful. While there is a time and place for intense critical thought, improv provides a framework for avoiding analysis paralysis.
Experience allows for handling the unexpected with grace and competency. Just as improv scenes need to build gradually with solid development of characters and relationships, coding solutions should not be rushed in sacrifice of a good foundation. They both require patience and frustration tolerance.
Remaining playful and loose allows for quick reactions and prevents you from being left behind the action. If an improviser is in their head, they aren’t paying attention to what is happening. If an engineer is too busy planning, they aren’t responding appropriately to changes in real time.
While thoughtful, deliberate action is ideal, environments and situations are always changing in the chaotic real world. Improv thrives on making sense of what is happening at the speed of thought. Likewise, there is no perfect or static software; it changes incessantly in response to continuously changing circumstances. An engineer in Agile is quickly iterating on making sense of a changing landscape.
An improviser steps out on stage with only a few seconds’ worth of an idea in mind, never a whole scene. Similarly, no engineer begins with a flawless start-to-finish plan fully mapped out in their head. It takes the whole team to make a show.
This is the human element shared by improv, programming, and any other collaborative team endeavor. Humans are not machines: we thrive on connection, interaction, and relationships. We work best when we embrace playfulness and fun.
Fun is fun because it is in-the-moment, free from domination of the over-analytical brain. Being in the moment feels liberating. It can be freeing to accept that you do not know what will happen next, to let go of expectations for how things are “supposed to” go.