Jazz Leadership: A Flexible Framework for Engineeering Leadership
When I nearly walked off stage in the Spring 2007 Spirit Ensemble Jazz show, it wasn’t because I didn’t know my music. I had practiced the tunes all semester, and improvised during several rehearsals. But in the critical performance moment, under stage lights with an actual audience, my body froze. I was gripped by a full-blown panic attack.
Then I looked up. Our bandleader, trombone in-hand, had a calm, steady expression. His look told me I wasn’t alone. And when he gave me my cue, I stood up, and started to solo. For the first time, I experienced jazz leadership in action.
Jazz “is music that includes qualities such as swing, improvising, group interaction, developing an ‘individual voice’, and being open to different musical possibilities”.
The Jazz Leadership Framework
Only in 2018, when I was asked about my thoughts on Python (and STEM education) for an article in Linux Format magazine, did it occur to me just how much my experiences with music performance (jazz practices, in particular) informed my ways of thinking about software testing, teaching engineering, and leading teams. Jazz music, with its flexible frameworks made of chord charts and its room for iteration and experimentation within those frameworks seemed to me an obvious analogy for software development and leadership. In a 2019 Keynote at StarCanada, I introduced this concept of flexible frameworks for software quality, but the concept extends to software development (and much further – but I’ll focus on software development and management here).
The jazz leadership approach I’ve developed over years of managing software quality and engineering teams rests on four key ideas, each borrowed from the stage and applied to software engineering teams.
Know Your Standards
Every jazz musician learns “standards”, the timeless songs in the jazz repertoire. Those standards are composed of melodies and rhythms, with their underlying chord progressions and forms. Just like their jazz musician counterparts, engineers learn and apply design patterns, system architectures, development workflows, and team norms. Test engineers build automated test frameworks and use manual testing frameworks to find bugs and ensure better quality. These standards provide the shared contexts needed to collaborate to build software as a team and to grow and mature as an engineering organization.
Trust the Ensemble
Everyone in a jazz combo knows their standards, but each person brings their own expertise: the bassist lays the groove, the trumpet performs melodies or counter-melodies. The keys add overall harmonic color, and the vocalist delivers the lyrics and engaging melodic vocalizations. Everyone gets to improvise, if they choose. Even the bassist. 😉
Jazz combos are also about balance. Yes, the band leader makes the final decisions, but does so in deep consultation with other musicians. Sometimes, the consultation is so ingrained in the framework that it’s not visible. But it’s happening.
Likewise, engineers bring their own tools and experience to a team. Frontend, backend, testing, security, DevOps, IT Ops—whatever is happening, it’s about balancing skills to arrive at technical solutions that serve people. Engineering leadership, done well, means creating space for each person to contribute fully while respecting the standards and allowing other team members their space to shine.
Of these four pillars, trusting the ensemble was the hardest for me to do. As an experienced musician, I work with knowledge, experience, and a lot more confidence. When I pivoted into quality engineering and then again into engineering leadership, I stepped into less familiar domains. I had to rely on my team’s deep technical expertise and ask a lot more questions to get grounded in daily work. But the more I trusted my team, the more I could contribute to all the ways the team flourished.
Improvise Within Bounds
Creativity thrives within constraints. Jazz musicians’ constraints are the song structures, chord progressions, and time signatures of their standard repertoire. From those constraints, creative ingenuity emerges, daring the music to keep pushing boundaries.
This kind of creative ingenuity is a hallmark of the best software teams I’ve worked with. Software engineers in sufficiently established products are usually solving unique problems, often extending pre-existing architectural patterns and frameworks. They bring their own intellect, education, and prior experience into the mix, pushing the existing boundaries of the current software. In both contexts, improvisation doesn’t mean chaos, nor “do whatever you feel like.” The constraints in both jazz and engineering invite intentional contributions to innovation.
Listen and Respond
Great ensembles listen in real time. They have to. Most jazz ensembles don’t play with sheet music. Instead, they memorize the structure of the standard tunes (experienced musicians know hundreds!), then play their part in response to the musicians around them. They make adjustments for other players and treat the musical ideas of others as new information to inform their own solos.
High-functioning engineering teams and organizations work in the same way. No 10x engineer can build, grow, and sustain a software product on their own. Engineers who listen to information from their teammates and other players across the organization are better equipped to build software that addresses user and business needs while staying focused on the problems at hand, increasing team momentum and avoiding discord. Engineers doing code reviews, providing feedback in feature design discussions, and working in cross-functional collaborative planning sessions are better equipped to listen to what is being presented, respond thoughtfully, and ask critical questions about the (present and future) problems they are trying to solve with software.
Why Traditional Management Falls Flat
Too many teams suffer under what I call the orchestral leadership model. My experience in string orchestras (30 years and counting) has been the same: strict processes and adherence to the sheet music, with the innovation coming from the conductor who has studied the score and has a highly opinionated viewpoint about what needs to happen to make art. The musicians are the means for the conductor to shape their ideas. There is a time and a place for this kind of thinking and work, but I’m not certain it is in software innovation.
Software engineering organizations with orchestral mindsets often operate under the assumption that every variable can be controlled. Waterfall methodologies at their most strict are a close analog, requiring immense amounts of scripted planning, using the developers to shape the software ideas. There’s little room for nuance, creativity, or risk-taking, and critical questions are viewed as defiance to the accepted ways of working. It is much harder to create a shared vision in the orchestral organization.
Then there’s the “solo artist” problem: the managers, staff engineers, or 10x developers who try to control every detail of the architecture and implementation of their own features, and others’. In the short term, these solo artists can seem like a gift. You know that you can rely on your 10x engineer to get code out the door, fast. That engineer might go around all the established rules, but they get the job done. But if the 10x engineer leaves, there isn’t anyone else who can work on or maintain that code in the same way (not even AI, at least not yet).
In a jazz ensemble, balance and shared responsibilities are crucial. Everyone gets a turn to solo (trading fours), and others take a back seat, doing important work to keep the groove going. Think of it like the glue-work of jazz. If there were only one soloist, the jazz ensemble would likely become very bored and leave for more exciting jazz groups with opportunities to use and expand their musical vocabulary. Similarly, engineering teams operating with rogue rockstar types become disengaged, losing the energy or desire to work with the 10x coder who doesn’t care about their opinions. They stop playing off each other, and the expertise of the soloist no longer has the possibility of raising up the entire team.
Impacts of Jazz Leadership
I once worked with a team that was stuck with chaotic, unstructured code delivery and two talented senior engineers who were more accustomed to working alone than with one another. At the beginning, there were few processes in place, the senior engineers did not communicate, and the company was reluctant to expand the team because they understood the dynamic was flawed. I was hired to help the team grow and shift toward more collaboration and predictability.
First, I worked with other directors and the team members to decide on processes that included our user community in decision-making and open-sourced software changes. Then, I assisted in hiring junior engineers to the team. As a small team that needed to review both our own code changes as well as community-submitted changes, we did paired code reviews at least once a week, and pairs changed every week, so junior team members had the opportunity to work with and learn from the different approaches and knowledge specialties of senior team members. I included myself in reviewing sessions so I could learn more about the product and codebase. We included regular planning meetings as well, since the team grew from two to seven members within a few months, and worked to address needs and concerns with an agenda to which all team members were invited to contribute.
By implementing these processes, we tripled open-source contributions to the product within each minor release, we reduced the time it took to release the software from an entire day to a few hours, and we leveled up junior engineers, one of whom is now a manager at the same company just a few years later.
Getting Started with a Jazz Mindset
How, exactly, do you begin thinking and leading with a Jazz Leadership mindset? Here are a few options based on this flexible framework.
Clarify your standards: Where do you need structure in your team process, your code, or your cross-functional work? It is important to clarify the places where structure is necessary to achieve your goals. For example, software for regulated industries requires more structure to document and release, since it must comply with audit requirements. It is necessary to understand and support the structures your software requires.
Create freedom to solo: Where can your team explore? There are more places to allow team flexibility than you might think, even in highly regulated software products. Examine teamwork/meeting norms and practices. Work with product and customer-facing teams to determine flexible approaches to meeting business needs while hitting delivery deadlines. Question the way that “things have always been done” and see if you can work to find improvements, even if they are small. Give others the opportunity to multiply their skills with opportunities to mentor, share, or lead, even if they are informal.
Invite musical conversation: Call and response and phrases are part of the language of jazz. A single soloist doesn’t solo over an entire set. Even within the same piece of music, musicians take turns soloing, sometimes “trading fours.” To trade fours is a kind of conversation where you listen intently to your fellow band mate and respond to their musical idea in the moment, incorporating their ideas into your response.
Invite this kind of constructive conversation into your team dialogue. Listen intently, especially when you disagree (this one is quite hard for me, and I still require practice).
Handling resistance: With flexibility comes questions, and sometimes resistance. This isn’t necessarily bad. However, watch for people who become stuck in a particular role. You’ll have your soloists, who ask “Why does every MR need two reviewers? It works on my machine.” And you may have your highly trained classical-musician types, who insist on following a score note by note, because “We’ve always done it this way.”
To work with those team members: Listen. Respond. Be patient. Change is hard, and flexibility can be uncomfortable, even while freeing. Building trust takes practice. But once your team starts playing together with purpose and creativity, the sound is unforgettable.
This is the first post in my Jazz Leadership series. In upcoming posts, I’ll dive deeper into each pillar: how to establish standards that enable collaboration and organizational maturity, practical techniques for building trust, creating the right constraints for innovation, and developing the listening and collaborative skills that help great engineering teams thrive.