Lessons from the Stage
As a software engineer, it's been my privilege to have spent time working as a volunteer at various theaters in the Greater Boston area. In doing so, I've noticed numerous parallels between the work I do on the stage, and the work I do in the office. Although I do sing considerably less at the office, I think there are several lessons in team dynamics we can learn from the processes of the theatre arts.
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 our 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 the likes of which we make in the theater or in 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. Perhaps you’re directing a comedy; if 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. Before, we saw the similarities between a theatrical production and a piece of software. Here, we see the potential pitfalls they also share.
If something is released as a buggy mess, we know the bugs didn’t get there by accident, and I believe 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. In summary; if a show had issues during the rehearsal phase, you better believe the audience will notice.
Therein lies the difference between a good show and a failure. The feedback we get throughout the iterative process and upon release must be listened to by each team member, whether that feedback is from your director, a fellow cast member, or the audience themselves. An excellent case study in the topic is the bug-ridden twenty-nineteen release of Bioware’s Anthem. 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.
[Source - How Bioware's Anthem Went Wrong]
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. Now, let us evaluate how to build strong relationships to avoid these pitfalls, again comparing relationships we find in the theater to those we find in our work. 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 product. It could cause the product 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 time, 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 upheave the entire production cycle for the sake of your pride. This is true in the theater, and it is true in whatever 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 theatre, an uncommon practice is 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 other various 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, we certainly cannot provide the quality, care, and support that comes 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 said 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", we ignore 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 a piece of art, 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.