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:
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.