Lessons from the Stage
Software Development isn’t all drama, but I learned a lot from my time volunteering with various theaters groups around the Greater Boston area. Although I do sing considerably less at the office (company policy), there are several valuable lessons the stage has taught me about team dynamics and processes that I would like to share with you.
Setting the Scene
To make the following ideas more tangible, allow me to draw two parallels between the life-cycle of a play and the life-cycle of a piece of software.
Firstly, both processes make use of an iterative cycle. We write a piece of code or we stage a scene and we improve it with feedback from stakeholders until it is ready to be released. Feedback from the director and the rest of the creative team will improve and refine your product over and over again. The feedback could be positive or negative. Sometimes, having rotten tomatoes thrown at you is the most important feedback you could receive, which leads me to the next point.
Second, we are always working towards the release of a product. This is the ultimate goal of a long term project, whether we work on it in the theater or the office. We’re making something for an audience to consume in one way or another. They could cheer at the sight of your product, or they could bemoan the issues symptomatic of a bad cast or poor directing. They could also hate the concept of your product, but we aren’t here to talk about [the Spiderman musical].
The decisions and changes you make along the way and the feedback from your audience when you release a product are equally important. You can have a talented actor, but the director must be able to focus their talent. You could have a great director, but the actors don’t take feedback well. If you’re directing a comedy and the audience doesn’t laugh, you’re doing something wrong. Each voice or source of feedback matters and listening to these voices can make or break a product.
Relationships are Embedded in our Products
Have you ever seen a live performance or perhaps a movie where things just didn’t work? When you see a show, the team dynamics that went into the creative process are tangible. If there’s bad directing or bad chemistry between two actors, you can feel it. I argue that the same is true for a piece of software. Here are some of the pitfalls both theatrical productions and software products must avoid.
If something is released as a buggy mess, we know the bugs didn’t get there by accident. I believe that most issues are the result of poor teamwork rather than a lack of skill on the part of an individual developer. If there’s an unhealthy work environment or distrust between management and developers, the customer will feel that. If something is rushed by the production staff or team members are unable to communicate with one another, the customer will feel that too. In other words, if a show had issues during the rehearsal phase, you better believe that the audience will notice.
That’s the difference between a good show and a failure. Every team member has to listen to the feedback they get throughout the iterative process and upon release, whether it comes from your director, a fellow cast member or the audience themselves. The topic is the bug-ridden 2019 release of Bioware’s Anthem is an excellent example of what happens when this process breaks down. Jason Schreier, a former journalist for Kotaku, wrote an excellent article on the topic:
“This account of Anthem’s development, based on interviews with 19 people who either worked on the game or adjacent to it (all of whom were granted anonymity because they were not authorized to talk about Anthem’s development), is a story of indecision and mismanagement. It’s a story of technical failings, as EA’s Frostbite engine continued to make life miserable for many of BioWare’s developers, and understaffed departments struggled to serve their team’s needs. It’s a story of two studios, one in Edmonton, Alberta, Canada and another in Austin, Texas, that grew resentful toward one another thanks to a tense, lopsided relationship. It’s a story of a video game that was in development for nearly seven years but didn’t enter production until the final 18 months, thanks to big narrative reboots, major design overhauls, and a leadership team said to be unable to provide a consistent vision and unwilling to listen to feedback.”
A Change in Perspective
The issues that Bioware faced can easily be attributed to a lack of communication, respect and trust between teams. We’ve seen the similarities between the two fields of software engineering and performance art, and the issues that can arise during the process. Just like theater and software development share some of the same pitfalls, those pitfalls share some of the same solutions. As the great Bill Shakespeare said, all the worlds a stage, and we its players. By looking at things through the lens of a performer, we can apply actionable methods to improving our day-to-day communications.
Trust Your Director
As in the case of Bioware, you need a strong vision for your product or your direction will waver. However, plenty of articles have been written that can describe what makes a strong vision. We’re more concerned about how that vision is expressed and how the team receives it. The core idea that is required for a successful relationship between the director and the rest of the team is trust.
In the arts, the director has one purpose: to serve the play. The expression of this is through their vision. Perhaps their vision is to set Romeo and Juliet in space. As an actor, it’s not my place to criticize that idea for being unoriginal. Since my goal is also to serve the play, I do that is through trusting and serving the vision of the director. A lack of trust in the director, and ultimately their vision, is a selfish act that can subvert the goal of the play. It could cause the play to express an idea or feeling that the director did not intend, which then creates an overall lack of cohesion among the team. As always, the audience will feel this and the impact can cascade.
The director has a hefty burden to carry, and even if their vision falters at times, it is the responsibility of the actors, the crew and the designers to execute that vision to the best of their ability. It is measurably more important to respect and trust your director, and receive their trust in return, than to cause upheaval for the entire theatrical production for the sake of your pride. This is true in the theater, and it is true in whatever other project you may be working on.
Since trust is a two sided coin, the director also carries the responsibility of maintaining a trust relationship with their team. In the theater, it’s uncommon for a director to give an actor a line-reading. This is when the director performs a line or piece themselves to show the actor how they wants it done. Occasionally, this can be a useful tool if an actor isn’t understanding some feedback. However, if done without consent, it can betray the trust of your actors. While the vision may lie in your head, you must ultimately trust the actor to do their job as well.
This ties in to the relationship you share with your development team, manager or product team. The person who holds the vision for the product must trust their team to execute that vision. Those who execute the vision must place their trust in it. This allows communication and empathy to thrive, rather than forming conflict and secrecy. You and your manager are both there to serve the product and you can do that through trusting one another.
React to Your Scene Partner
As my professor in college, Norm Jones, would always say: “The only thing you need to put on a show is an actor.” And while one-person shows are not uncommon, I would not take Norm’s advice to mean: “You should put on a show by yourself.” While that is technically true, that’s not the sentiment of his advice. Norm is referring to the fact that you will always need someone to actually create the product. While the director, lighting designers and various other crew members are important, no one would watch an empty stage for two hours. In the same way, I would say this: “The only thing you need to create a piece of software is an engineer”.
If all we need is an engineer, why are “heroics” and “lone wolf” pursuits so discouraged? Because while we may not be able to make the product without a single engineer, that engineer cannot provide the same level of quality, care and support that you get from having multiple engineers working together. Indeed, your work can thrive when you embrace the benefits of working with your team. In the same way, the decision to treat your fellow engineers with a lack of respect can be damaging to your work, your product and your relationships with your fellow engineers.
When two actors stand across from one another performing a scene, we can judge the quality of their interactions. When these actors react to one another generously, offering new ideas and emotions, they make their scene partner look good while learning new things themselves. In the same way, we build our team and ourselves up through our interactions with our fellow engineers. The feedback, encouragement and shared knowledge from one engineer to another is critical to our own professional development, and the success of a project.
Yes, we couldn’t have created this product without you, the engineer. However, we cannot create a good product without a team. We don’t need to settle for a product that merely exists, we should strive to create a product that tells a story. We should strive to create something people enjoy using. When we take to heart the ideas and feedback given to us by our fellow engineers, and take action in turn, we better ourselves and improve the work we can do.
Listen to Your Audience
Several years ago, I found myself in a team retrospective for a comedy show we had performed the previous weekend. This show was comprised of live sketches and segments ran by a host, and at one point during the show, one of our segments had fallen flat. There was a noticeable lull in the audience during that time, where seldom a laugh was heard. For a comedy show, that’s a difficult pill to swallow. As such, at one point during our retrospective, one team member said this: “Why do we care so much about what the audience thinks?”
For a comedy show, the audience’s response is all we care about. If they don’t laugh, it’s not because they’re wrong; it’s because our writing wasn’t funny. We care what the audience thinks because their opinion is the only thing that matters. While we like to convince ourselves that, if an audience doesn’t like our work, it’s because “they just don’t get it,” that ignores the fact that we could have written in such a way that they did “get it”.
I cannot emphasize this point enough. Do not forget who you are creating you product for.
When you create perform a play, the outcome is often tangible immediately. In software, we rarely see an immediate outcome for whatever our task may be. It’s much easier to write off a critique or negative review and say “they just don’t get it.” However, we should care about what the audience thinks because, to them, the outcome is immediately tangible. The code we write isn’t written for computers, but for humans. Every product we make, whether front end or back end, will be used by someone. They are your audience. How your code will be perceived, interacted with and built upon is entirely up to you and your willingness to prioritize this audience.
Not every show can be a success, nor can every product. However, we can still find success in our day to day interactions and relationships. By looking to the arts, where the intangible is made tangible, we can be reminded that our decisions will always have an impact. The tools required to make a good show are the same that are required to build healthy team dynamics and drive your outcomes towards success. By maintaining a pursuit of trust, respect and healthy communication with our team, we can make something truly special, be it on the stage or behind a computer screen.