jessingrassellino

Category: essay

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

  • Great Engineers Aren’t Always Great Managers – Here’s How We Can Change That

    Most engineering managers were never trained to lead people, only to ship code. And often, it shows.

    In tech, management roles are frequently given to high-performing engineers who receive little to no leadership training. Sometimes, this happens because an engineer actively wants to move into management. This post isn’t about those engineers — they’re doing great! More often, however, senior engineers are pushed into management because it’s the next (or sometimes the only) step available for career advancement.

    Unfortunately, this sets these senior engineers—and their teams—up for frustration, burnout, and underperformance. I first noticed this gap between engineering skill and people-management skill when I transitioned from leading quality teams to leading engineering teams. I reached the final interview rounds with several companies, only to be passed over for more technical candidates who performed better on code reviews. At one company, the senior engineer who interviewed me for the coding round even reached out to say I was her preferred candidate — but the hiring manager wanted someone more technically advanced.

    Myth: Great Engineers Make Great Managers

    Over the past fifteen years, I’ve worked with many engineering managers—from first-line managers to VPs of Engineering to CTOs. The least effective of them were often exceptional engineers who prioritized technical expertise over communication, business acumen, and building high-trust environments.

    In those environments, engineering teams were poorly represented in cross-functional spaces. I saw former engineers micromanage their reports, insisting they use the exact technical solutions they would have chosen. Eventually, many of those direct reports left in search of greater autonomy and opportunities for growth.

    Why is it that organizations assume a great engineer will automatically make a great manager? There seems to be a persistent belief in tech that technical excellence translates into leadership excellence—as if an engineer’s brilliance will magically “rub off” on their team. Perhaps it’s because management is sometimes seen as less valuable or less skill-intensive than engineering.

    But those of us who have worked under ineffective managers know how harmful these environments can be. MIT knows it too. Their Engineering Leadership Program for Emerging Engineering Leaders emphasizes that engineering management is a fundamentally different kind of leadership—one that centers on trust, team-building, and aligning smart, capable people toward a shared vision, even when they disagree.

    Getting people to disagree and commit is its own skill. And it’s not easy to learn.

    Fact: Ignoring Management Skills is a Problem for Everyone

    Focusing only on technical skills when promoting into management roles can hurt everyone—especially the new manager. I once worked with a director-level manager who was still deeply involved in coding. While many engineering organizations admire this model, it can be problematic. This manager overlooked and even dismissed team members who used different approaches than their own.

    Worse still, the director failed to build relationships outside of engineering. Collaboration with other departments was contentious, when it existed at all.

    This isn’t surprising. Educational research shows that leaders who lack people-development skills tend to have more disengaged staff and lower-performing teams. In my experience in education and leadership development, I’ve seen how learning different leadership styles can help grow individuals, resolve performance challenges, and align teams around shared goals. Personally, I use a situational leadership style and aspire to a transformational one.

    “At the most basic level, transformational leadership is used to inspire employees to look ahead with a focus on the greater good and to function as a single unit with a common goal in mind. It is not until a leader accomplishes these steps that a successful transformation can begin.”Shayna Joubert, 2024

    What Great Engineering Managers Do

    The best engineering managers I’ve worked with came from a variety of backgrounds. One was a top-tier engineer who became a respected industry leader. Another grew a company from two employees to nearly two hundred. The best I ever worked with had previously worked in engineering-adjacent roles and became a highly effective director.

    Despite their different paths, they shared three key capabilities: strong communication, a focus on people development, and a clear sense of purpose. Here’s what they did well:

    1. Build trust through open communication

    Each of these leaders communicated with transparency, telling their teams as much as possible, as early as possible, about business decisions that could affect them. This built trust and made space for meaningful conversations.

    When something wasn’t going well, they addressed it immediately and clearly, then offered guidance and support—without prescribing solutions—so that team members could analyze and solve problems themselves.

    They encouraged opposing views, invited tough questions, and created environments where healthy disagreement improved outcomes. When team members felt heard, they were more committed to solutions.

    2. Let go of your old job and trust others

    These leaders had fully stepped out of their previous engineering roles. They trusted their reports to understand the vision, execute the plan, and learn from both successes and setbacks.

    When someone succeeded, they celebrated the win. When someone struggled, they approached it with curiosity and support, not blame.

    3. Redefine your purpose: grow the people who grow the product

    These leaders understood that their role was no longer to be the best individual contributor. Instead, they were multipliers—amplifying impact by developing others. Each person they mentored became a force for greater outcomes across the organization.

    Management Is a Learnable Skill

    The good news? Just like engineering, management skills can be learned and improved.

    If we want to set senior engineers up for successful leadership, we need to teach and reinforce key management competencies. Even experienced managers benefit from refreshing and expanding their skillsets.

    Here are three areas to focus on:

    Giving and receiving feedback

    Structured mentorship and regular feedback are key to improving performance and retention. Using models like SBI (Situation–Behavior–Impact) can make feedback more actionable and trustworthy.

    Leaders also need to ask for and receive feedback to grow trust, model vulnerability, and stay aware of their blind spots.

    Developing emotional intelligence

    Emotional intelligence is critical to effective leadership—but it’s also one of the hardest skills to build. It requires honest self-reflection, empathy, and a willingness to grow.

    Practices like journaling, daily reflection, and leadership coaching have helped me immensely. Many strong leaders use similar tools.

    Becoming a lifelong learner

    Great leaders are constant learners. Staying curious and informed boosts confidence, cognition, and work-life balance. (And learning doesn’t have to stay in your field—I’m a violinist, and I draw leadership lessons from music all the time.)

    Some companies invest heavily in management training, while others offer little or none. I once worked for a deeply technical company that also provided the best management training I’ve ever attended—it was required annually.

    Even without formal programs, resources are widely available. Many companies offer education stipends. High-quality research and training are available online. And interactive formats—virtual or in person—can offer real-time coaching and feedback.

    The key is recognizing that management is a skillset, as complex and valuable as any technical one.

    A New Definition of Great Engineering Management

    It’s time to broaden our definition of leadership in engineering.

    Great engineering managers don’t just ship code. They lead with emotional intelligence, invest in the growth of others, and build resilient, collaborative, high-performing teams.

    They don’t just grow products—they grow people. And people make all the difference.

  • Ms. Jessica

    jess ingrassellino, October 2020

    I was the headmaster at my school for orphans. “No, no, NO! You have to

    stand right here. Princess wouldn’t go over there,” I’d command my younger sister, who played every supporting actor role with passion and vigor. We played this game where we pretended to be orphans every day after school. I was probably ten or eleven before we fully quit the game because we got too old for imaginary sanctuaries.

    It’s kind of funny to me now, to think back on what I thought teaching and helping were. Mostly, I thought it meant being in-control, and getting to have control. Both equally appealing to my child-mind. It was strange when I realized that teaching, the art, the act, had nothing to do with power or control.

    “Miss Jessica. Miss Jessica, will you help me with my card?” This little boy was a first-grader in the classroom where I volunteered after school a few days a week. In a rare moment of clarity, my mom had recommended that I volunteer in classrooms since I was interested in teaching, so I did. I met with the elementary school principal, and the next week, I was volunteering in a first-grade classroom – actually, my first-grade classroom, with my first-grade teacher, who was now in her forties.

    “Oh, that’s a beautiful card. Your mom will love it.”

    “This card isn’t for my mom,” he replied, “it’s for my Grandma. My mom’s dead.”

    As a sixteen year old, that was pretty much peak awkward. I tried my best to recover: “Well, I know your grandmother is just going to love that card.”  For weeks after,  I felt like a fool for assuming that he had a mother because he was making a card.

    Over and over again, my students have called me out — usually inadvertently — highlighting the gaps in my knowledge and limits in my experience. I’ve started to think that teachers are just people who like learning things the hard way. Within my first four months of teaching high school, I was certain I’d lose my job.

    “You know what lady, I don’t give a shit!” Eddie shouted.  Eddie, the 19-year-old senior. The genuinely nice kid who put on the tough-guy armor to make the world safer for himself.

    “Yeah, well, you know what?”

    I, all twenty-three years of me, yelled, “I don’t give a shit either. Now go to the principal’s office!”

    Yeah. I did it. I lost my entire temper in fifteen seconds. Couldn’t sleep for a week. Kept waiting for my whole career to get upended. You know what they don’t teach you when you study to become a teacher? They don’t teach you that all of the shit you’re struggling to leave behind is the shit that’s going to bite you every day until you deal with it. That illusion of control I had when I was five? It went out the door with Eddie.

  • The Call

    jess ingrassellino, july 2019

    Brushed off again. She’ll always be his second best, silver medal. First loser. “First loser” she chuckles out loud, in spite of herself. Pulls the Egyptian cotton sheet around her naked body. Soft, smooth, crisp fall air rushes in waves over her skin. Relief, for a moment, but she keeps turning over details of the last time she saw him.

    “I’ll call him tomorrow.”

    She’s lecturing herself now, head in hand. Bites her lower lip and considers her options. She doesn’t like the idea of telling anybody anything. Never did. Her jaw hurts. She’s grinding her teeth – front teeth when she’s awake, molars when she’s asleep – she stops herself and takes a deep breath, but can’t escape the anxiety.

    They’ve been planning, halfheartedly, to be more serious. She wants it, he’s not sure. “Commitment-phobe,” she grumbles, tossing over again. Bright moon, muted by sheer pink curtains. Curtains flapping open, intermittently, with the breeze. She wants to be his only. Married. Before she was twenty-nine, it never felt important to consider a serious partner, much less marriage, family, or children. But tonight? Tonight, twenty-nine is ancient and life is horribly unpredictable. Unfair. Tonight, everything that’s never mattered matters, and everything that’s ever mattered feels like a waste.

    On her dresser, her violin sits in its stand, untouched since she found out. Normally she practices daily, several hours a day. Lately, she wipes it gently with a soft cloth, leaves it out to try and coax herself out of her anxiety. Six months ago, he watched her prepare for auditions, and four months ago she’d learn she’d made the symphony. Now, she’s not sure about the trajectory. “If this is my time, how will I spend it? And what will make it matter?” She stares at ceiling, glancing back and forth between the shadows from tree limbs dancing and the moon creating them.

    She will call him tomorrow. After work. She’ll call him, and tell him, because she’s already delayed too long. Now, though, the call weighs on her mind, creeping steadily into her body. Her legs twitch – the left leg, really. The rough patch of skin on her left heel hits her right shin bone as she tosses again, to face away from the moon and closing her eyes.