jessingrassellino

Category: Music

  • Jazz Leadership: A Flexible Framework for Engineering Leadership

    June 9, 2025 engineering, management by 54752785

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

    Travis Jackson, Ethnomusicologist

    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.

  • From Coding to Coaching: The Shift that Powers Engineering Growth

    The Untaught Transition

    When I became an engineering manager, I expected the hardest part would be learning to coach adults who were experienced engineers. I was wrong. The hardest part was realizing that most of my peers had not been taught how to do this. Many didn’t think of coaching as part of their job.

    The Common Path: Promotion Without Preparation

    In tech, I’ve observed a common path to leadership: a senior engineer performs well and becomes a tech lead, taking on technical and soft-leadership responsibilities. If there’s no principal engineer or architect track, the next step in career development is typically engineering management.

    But people management isn’t just a continuation of engineering skills. That would be like expecting a brilliant violinist to conduct an orchestra without ever learning about how different instruments work together, or how to guide musicians through complex emotional and technical passages. We would never, so why do it to engineers?

    “In many cases, organizations lack clear training or support for new managers, which results in technical leaders who default to the skills that earned them promotion—usually not people management.”

    Will Larsen, The Engineering Executive’s Primer

    Coding and Coaching: Two Distinct Skillsets

    Software engineering work can be solitary, logic-driven, and quantifiable. Code runs on a developer’s machine, the pull request passes or fails the tests in the pipeline, and is either rejected or deployed. Then, the next development task can start. In contrast, coaching work is relational, emotionally attuned, and often ambiguous, based on the ever-changing nature of the human experience. It is work that’s never “done”. This makes coaching one of the more difficult leadership skills to pick up without preparation.

    Teaching taught me that coaching is an intentional practice, not (fully) an instinctual one. At minimum, coaching requires listening with curiosity, giving specific feedback focused on somebody’s behavior (not their character), and knowing when to push someone, and when to step back to let someone learn on their own.

    “Effective coaching must be intentional, structured, and rooted in curiosity—not command. It’s not a personality trait; it’s a practice that leaders can and must develop.”

    Jean Dahl, Leading Lean

    What Happens When Coaching Is Missing

    Maybe engineering organizations don’t see the need to teach coaching skills to managers. After all, these skills don’t always map directly to solving business problems. But ignoring them has real costs—costs that do impact the business:

    • Micromanagement masked as mentorship
      When managers micromanage, it creates a sense of distrust. I once worked with another engineering manager who reviewed every pull request from their team of (mostly) senior engineers. They believed this was mentorship—sharing their expertise. Instead, it created a bottleneck where those engineers stopped taking technical risks and began second-guessing their decisions.
    • Team members staying stuck because no one’s helping them grow
      Engineers can experience stagnation when they don’t receive meaningful growth opportunities tailored to both their goals and the business’s. Without performance feedback, they can’t see how their decisions impact business outcomes, and they can’t make positive, incremental changes to improve.
    • Glue work going unseen and unrewarded
      Especially for women, neurodivergent folks, and underrepresented engineers, glue work (code-adjacent tasks like documentation, mentoring, or cross-team coordination) often goes unrecognized. Managers can use coaching strategies to ensure that glue work is shared, visible, and valued.
    • Burnout in high-potential engineers who don’t feel supported
      Strong, motivated engineers want to know how they can improve their performance, and are typically very committed to business success. Without coaching and growth opportunities, they may burn out or leave for companies that promise more support.

    I’ve seen all of the above management-related problems at companies where I’ve worked—large SaaS orgs and lean startups alike. I made some of these mistakes myself when I first became a manager, and that was with preparation and experience in people growth. No company of any size is immune to the productivity and morale issues caused by ineffective management.

    “When engineering managers neglect coaching and career development, teams experience disengagement and talent attrition—even among top performers.”

    Robert Santer, Navigating the Engineering Organization

    How I Practice Coaching In Engineering Management

    As a teacher, I was trained to evaluate performance holistically and adapt strategies based on how each individual learned best. As a self-taught software test engineer, I learned to anticipate risk, observe behavior, and communicate clearly. Both skill sets translated directly into the coaching I’ve done over the past eight years as an engineering leader. I have refined many of these skills and learned some valuable lessons over time. Here’s how I’ve translated my teaching background into practical engineering leadership:

    • Using 1:1s to focus on performance and professional goals
      Face-to-face time is precious. I typically use group chat (slack, etc) to give group updates and retrieve work status information, while using 1:1s to discuss personal goals, performance concerns, and give tailored feedback. 1:1s are a lot like music lessons in this way.
    • Adapting feedback models from education, like SBI (Situation–Behavior–Impact)
      SBI is my go-to model for actionable, respectful feedback. I use it for coaching both team members and leadership (managing up), and it’s been consistently effective because it removes the guesswork and defensiveness that often derail feedback conversations. Instead of saying “you’re not communicating well,” I might say: “In yesterday’s standup (situation), when you said the feature was ‘almost done’ (behavior), the product manager scheduled the demo assuming we’d ship tomorrow, creating last-minute pressure for the whole team (impact). Can you tell me more about what happened here?” The SBI approach keeps everyone focused on solutions rather than taking things personally.
    • Creating micro-goals and reflection practices
      Small, meaningful goals keep people motivated. It’s a bit like practicing scales. They seem kind of meaningless in the day-to-day, but achieving wins there magnifies what I’m able to do in the future. I pair micro-goals with short (verbal or written) opportunities for reflection so individuals can track their own growth and see the connection between their daily work and larger achievements. The key to making this work is that I am not giving a grade or a rating. My team member measures their progress against the rubric, and gives their own assessment, which drives discussion and growth.
    • Coaching high-performers to become multipliers
      One of the most important questions I get from senior engineers is: “How can I grow when I’m already at the top of the ladder?” My answer: learn to multiply. High-performers can drive impact by coaching others and raising the overall skill level of the team. This is a lot like the job of the concertmaster or first chair in my orchestras – she assists the entire section with how to play better, lifting up the sound of the entire section and orchestra.

    Coaching Is Core

    Coaching isn’t a soft skill—it’s a core leadership capability that transforms not just individual performance, but entire team dynamics. When engineering leaders learn to coach with the same intentionality they bring to designing systems, they create multiplier effects that ripple throughout the organization.

    And just like writing great code or designing scalable systems, coaching can be learned and practiced. The question isn’t whether you have time to develop these skills—it’s whether you can afford not to.

  • The 2 Octave Schradieck Project

    Starting in January, I was accepted to participate in Nathan Cole’s Virtuoso Master Course (VMC). To say it’s a major commitment to, and investment in, my violin and viola playing is an understatement. To see the progress I’ve made in 8 weeks is a shock, to me. But not to Nathan’s students.

    The thing is, I’m not going into this playing a lot of repertoire. In fact, I’m going backward to go forward. I was fortunate to learn violin in school, with good orchestra teachers. But I did not have the opportunity to seriously study technique until I was in college, and by that time, there were a lot of bad habits I had ingrained, especially in my left hand.

    Fast forward twenty years. I nearly lost my ability to play violin and viola after getting Covid in March 2020, which kicked my Spondyloarthritis (undiagnosed until November 2020) into high gear. I did not know what the hell was happening in my body, but it was bad. After getting diagnosed, the first thing I needed to do was get back to violin. I spent months working with my doctors to figure out a treatment plan that would allow me to play. It paid off. Last August, I worked to audition for several orchestras, and I now play frequently in the Hudson Valley and NYC. It’s not without pain, but it is with SO MUCH JOY!!!!

    Now, I have something rare. I have the gift of time to slow down, and go back and work on my basics. In the past 8 weeks, I have not focused on hard repertoire (except my orchestra music). The bulk of my practice time is spent in the basics I never experienced – one and two octave scales, played slowly, with beautiful tone, in different positions.

    Attention to the placement of the third and fourth fingers of my left hand.

    Alignment and hand frame.

    Speed, intonation.

    After the first four weeks in VMC, I decided the bulk of my practice time will be dedicated to the ugly, unglamorous work of the two octave scale, in all keys. Of Schradieck, played mindfully, attending to the placement of each finger, the way it lifts and returns to the string. The requirement of finger independence AND fingers that will work together as a team.

    This is the stuff of violin nerds. The stuff of technicians that, when mastered, seems effortless, and allows the music to shine through because there is control.

    Yeah, it’s tempting to go back to survival playing and bad habits. But it’s infinitely more rewarding to go on this journey of building mastery of my technique, of getting the experience I couldn’t get as a kid. And now, I appreciate it more. I have the time and the wisdom to know that slowing down, taking my time, and working intentionally on these basics is the thing that will allow me deep freedom and control over my musical expression. I have been keeping a private practice journal, but the little instagram videos I post show surprising progress in the short time I’ve been in the VMC.

    I’m bursting with excitement – I’m so ready to level up my technique and my ability to play violin in the way that reflects how I hear the music in my head! More to come…