I come from a musical background, with degrees in piano performance and piano accompanying and chamber music, and I think a lot about how that’s shaped who I’ve become in web and software development. I’ve even gotten to give a talk relating musicianship skills to programming and open source management in a concert hall in Vienna that included a piano performance. For this blog post I want to talk about another particular aspect of the classical music world: masterclasses.

Masterclasses are not unique to classical music, but they do form a central and critical component of music study. A masterclass is a format in which musicians perform a work for an established artist and the artist then gives them feedback rather like a lesson, except that all of this happens in front of an audience. You might also hear about “studio class” in music school settings, which are similar except that it is not an open audience but instead one made up of your peers who share the same primary professor. For big artists coming to a school or a region, you might have to audition (compete) for a spot to be criticized publicly on your performance. Put that way, it might not sound very appealing, but it is foundational in how to function and succeed as a musician and really in any profession, including as a part of a software team, which is what I do today.

Managing feedback in group settings

The first experience in managing professional feedback is typically how you receive it. Sometimes you might not immediately agree with what you’re being asked to do, and that’s okay. What’s important is to respect the time and effort of the person giving you the feedback and show them that you understand it, even if after synthesizing that information you decide it’s not the direction you want to go. In music, that means acknowledging what you’ve heard by demonstrating the requested change on the spot. This might be a specific request, like “play this section softer”, or something that requires more interpretation, like “don’t lose momentum by getting stuck before the high point of this phrase”. This kind of flexibility is itself a skill, and one that is of high value.

In software, your feedback sessions might not involve direct and immediate action in the same way, but it can be very helpful to show that you understand a concept. For instance, you might say “I hear you, and I need to think about it some more; I’ll start by trying out a different way of structuring this file”. Do be careful not to just repeat back verbatim all the time or come across as explaining back in a condescending way.

As you progress through your career, you will likely find yourself in the position of also giving feedback in a group setting. For many people who are just beginning this part of the journey, this can be quite intimidating because you have not previously had experience in doing this. You also may have had bad experiences in the past with feedback that was not delivered in a constructive way. This is where an early culture of group feedback comes in so handy, notably in the studio class setting: professors are asking your peers to also learn how to process, structure, and deliver feedback in real time. You hear from your professor every week; this is an opportunity for students to deliver a polished performance, receive feedback, and give feedback all at once.

That said, peer groups can also be intimidating. This is not unlike having to give a talk or demo some code in front of your coworkers – it can feel like more pressure than a large room of strangers because these are people whose opinions you are exposed to on a near-daily basis and hopefully care about. Remember that we are all learning all the time, and your peers may also need to work on their delivery! Some strategies you may have encountered are to use “yes, and” instead of “but”, or to begin feedback with related praise.

I highly recommend that teams actively solicit peer feedback at various stages throughout a project and also workshop methods of requesting and giving feedback, something that can be facilitated by an engineering manager. An EM might even want to structure some team meetings much like a studio class, where people present on something they’re working on so that not only do they have a chance to share about something they might not otherwise get to talk about, but the team also has a mechanism built-in for giving and receiving feedback. Soliciting feedback is also a skill in its own right – a culture of regular and expected feedback goes a long way toward building that in all levels of team members.

Arriving prepared

Another major difference between masterclasses and lessons is that you are expected to present a polished product at a masterclass, whereas lessons are to workshop that polish. In a masterclass setting, you and any collaborators enter the stage, bow, and perform to applause before proceeding with the feedback from the masterclass artist. Some professors, especially at the conservatory level, also require performance attire when performing in studio class (though perhaps not black tie).

Working on a software team typically does not involve building something in a vacuum until you’re ready to release it to the world – you hopefully have team checkpoints that are more equivalent to music lessons. But there is a lot to be said for knowing that even though you’re ready to share your work publicly and have met your deadline, there’s still more that can be done, rather like a software beta. And even for something you’ve been performing for a long time, a fresh perspective can change not only how you’re approaching that piece, but how you think about your craft in general. Always be prepared to show your best and recognize that true mastery is in knowing that there’s always another level to reach for.

Cross-discipline knowledge

While masterclasses are typically with an individual artist who specializes in an instrument, many works involve other musicians, such as a string quartet or a piano trio. These are things that are worth bringing to masterclasses too! Related, it’s also valuable to have lessons from people who might normally be considered outside of your discipline – one of the best lessons I’ve ever had was with a jazz professor who spent 2 hours pushing me to express myself more and more.

Not only do your collaborators need to be equally prepared, you need to work together to really achieve artistry. All too often you will see lower-level instrumental masterclasses where the pianist is an afterthought, plunking their way dutifully through concerto reductions, and it shows. Sometimes the masterclass artist will also dutifully ignore them, but more often they have to involve all collaborators in their feedback. No amount of telling a vocalist to evoke the dreamy sparkling of Debussy’s Nuit d’Etoiles is going to work if the pianist is heavy-handed on those rolled chords, or vice versa. (This is also why collaborative pianists have to study lyric diction and multiple languages and can specialize in vocal coaching, but I digress.)

Not only does feedback need to be inclusive of a group while also targeted to each individual, it needs to be clearly contextualized. In music, that means including music history and theory as well – the performance practices of the era, specific notational quirks of the composer, what harmonies are and how do they drive the piece, and limitations of instruments and how they interact together. So when giving feedback to a software team, be sure to continually frame things within broader feature or product goals, and tie the various disciplines together to create that cohesive whole.

In both giving and receiving that style of feedback, you will find that you need to have some amount of understanding of disciplines outside of your own. That doesn’t mean that you need to be an expert; in fact, you will probably be received poorly if you try to instruct somebody on how specifically to accomplish something you don’t normally work on. Instead, much like framing within broader goals, think about how you might inspire somebody to look at something a different way, or contextualize within your own discipline so that they can understand you better as well.

Bonus: watch a masterclass!

Here’s a 45 minute masterclass session with Benjamin Zander, the music director/conductor of the Boston Philharmonic Orchestra and the Boston Philharmonic Youth Orchestra, and Amanda Chi, the cello section lead of the youth orchestra. I promise you don’t need to be a musician to get something out of this – at one point, Maestro Zander acknowledges non-musicians in the audience and gives them a brief explanation of what he means by the direction and pull of harmonies. But even outside of that, you’ll see some real mastery of not only the musical material from both parties, but also how to address both audience and performer, contextualize the feedback, and deliver that feedback in a constructive and suggestive way rather than making it into a personal demand. I also really enjoy what he talks about at the end, differentiating between what you need to do as a performer of this solo piece versus what you need to do as the leader of your group.