jessingrassellino

Month: June 2025

  • Know Your Standards – Building the Foundation for Engineering Excellence

    The second article in the Jazz Leadership series

    Frameworks and Standards in Engineering

    When I think about the most effective teams I’ve worked with, there are some foundational practices that those teams share, even if they focused on different standards:

    • The entire team was involved in discussing the standards;
    • the team agreed to disagree and commit to the standards, and agreed to have retrospectives to discuss how things were going and make changes (flexible frameworks, improvising);
    • the team and overall organization were as committed to improving engineering quality, efficiency, and impact as they were to improving product quality and customer experience;
    • team members were skilled in giving and receiving feedback using shared feedback mechanisms in the organization;
    • the team worked toward shared understanding of the architecture;
    • the team had a vested interest in ongoing engineering learning through onboarding, courses, lunch-and-learn, and taking advantage of organizational learning stipends.

    I can also think of teams I worked with that did not have clear standards or did not have the time or drive to develop clearer standards. Those teams faced these problems more frequently:

    • The lack of quality standards and testing led to multiple patches immediately following each release;
    • the lack of agreement at a few organizations about product direction and position in the portfolio led to paralysis on what to build and release, slowing product development;
    • the lack of documentation about the customer support ownership framework led to confusion about the responsibilities of support team members, causing support backlogs to grow large and issues to go unaddressed due to confusion;
    • the lack of cooperation between engineering and support caused customer irritation and dissatisfaction.

    Three Types of Engineering Standards Frameworks

    There are many potential frameworks that engineering teams can choose as standards. Below are three common standards that can serve as the basis of building shared understanding in your engineering team.

    Coding Standards: Your Technical Language

    Coding standards sound and seem obvious, but it can be tough to enforce coding standards without team agreement. Coding standards need to be consistent to provide value, but not so rigid that they interrupt workflow and become a bureaucratic nightmare to follow and enforce.

    What’s the difference between a style guide that feels restrictive versus one that feels enabling? Restrictive guidelines may include rules about line length, where conditional braces need to be placed, or requiring docstrings for all functions, including helpers. These restrictions can serve a purpose in highly-regulated environments, but can be overly constraining depending on the context. It’s important to work with your team to build a style guide that has enough structure to enforce coding standards that impact your product and meet regulatory standards that may be required, but flexible enough that developers are not spending precious time ensuring that line lengths are exact, when they might instead be thinking about and implementing more innovative work.

    Once I managed a team (Team A) that received a merge request (MR) from another engineering team (Team B) that was over 1000 lines long, with a request to review it and accept it into our code base within twenty-four hours. This situation was problematic in so many ways, and the lack of standards on Team B did not help. In this case, business and political considerations beat process. This meant we had to work through a single, thousand-line MR that was written without adhering to Team A code standards, even though it was going into the Team A codebase.

    The senior developer who reviewed this work ended up needing two days to work with the developer on the other team, refactoring a substantial portion of the code in order to merge with some degree of confidence. The merge happened within seventy-two hours, but it was a difficult and stressful process, one that could have been alleviated had the requesting team adhered to norms about the size of a merge request, as well as coding standards of the more established team to whose codebase they contributed.

    Communication Standards: How Teams Stay in Sync

    Communication standards can be easy to ignore, especially when they are based on implicit norms rather than clearly defined, explicit expectations. Communication standards built around respectful listening and working toward trust enable strong engineers to work with their peers and cross-functional colleagues.

    Conway’s Law states that structures that an organization’s designs (i.e. software and technical structures) reflect the communication structures of those organizations. Given the benefits of positive communication as well as research on Conway’s Law, it’s valuable for everyone to understand and improve their explicit communication standards, not only for the internal and personal clarity they offer, but for the betterment of the systems that they design.

    When I have worked with teams skilled in communications, solving problems was generally easier. People who may not have been natural communicators still had a framework to reference so that they could practice communicating with clarity, sharing their concerns in ways that address problems without attacking people. These teams were solution-focused, and communicated with empathy. They often set the tone for effective cross-team communication.

    Design Standards: Architectural Harmony

    It may seem strange to discuss when software architecture or design patterns when talking about team standards. On the one hand, software architectures may already be in place, and norms already established in a team, for quite a long time (sometimes decades). Less often, you’ll get to manage a greenfield project and never have to think about what happened before, nor what will happen after you’re done with the project and have moved on.

    Usually though, we are somewhere in the middle. It is important for teams to decide upon software architecture and design norms, and then document those norms so that when people leave the team, it doesn’t have an outsized impact on the productivity and progress of the team or project (the bus factor).

    For design and UX teams, shared design libraries that have interchangeable components or styles for specific parts of the product can help designers to work independently and creatively, while maintaining brand identity and familiarity across the UI. For development teams, documenting and sharing about the architecture through lunch-and-learns given by different team members can help spread knowledge about, and an understanding of, these critical shared frameworks. These are just a few of the ways teams can establish communication standards that improve product quality and developer skills.

    Creating Standards Collaboratively

    Collaborative development of new or adjusted processes and moving toward flexible frameworks requires collaboration, reflection, and agreeing to disagree and commit (even if temporarily) to try new ideas.

    Back when I taught high school, we developed classroom rules and norms together. Our process involved free-brainstorming, active discussion, and ranked choice voting for the top 3 – 5 standards. Those top choices became our rules for the year. Because students were part of the process of creating our shared norms, they were more invested in upholding them. Co-creation is essential in the performance of Jazz music, as musicians improvise within the framework to produce unique performances of the same piece.

    It turns out that co-creation is also effective in business contexts. Businesses have successfully included stakeholders and used their experiences to design lasting changes. By including everyone in the design and development process, the team develops greater depth and understanding of the business and personal context of the desired feature or application.

    But a premise of co-creation is that by sharing experiences, all the parties involved will acquire a deeper understanding of what is happening on the other side of an interaction, enabling them to devise a new, better experience for both sides. — Venkat Ramaswamy and Francis Gouillart, Harvard Business Review

    Standards: Are you enabled or constricted?

    Standards and frameworks are constraints, by definition. Sometimes, the standards become so much a part of the process that they go from enabling to dogmatic and constricting. As you develop or establish the standard frameworks for your team, it’s important to pay attention to how people are understanding and interacting with frameworks so they don’t become bureaucratic overhead or a scripted checklist that prevents innovation. The concept of enabling constraints is helpful to understand as you work with teams to develop standards. I love this definition by Erin Manning and Brian Massumi:

    Erin Manning & Brian Massumi coined [the term co-creation] for rules that limit actions to enable novelty.

    I have implemented work management processes using different tools (internal management tools, Jira, Aha) for teams with inconsistent tools and processes (i.e. github issues for “sprint” planning, inconsistent planning practices). Having worked in small startups with lean processes and multiple production deploys a day, the idea of meetings and planning very far ahead felt constraining to me. Getting used to a million dashboards and tabs for multiple teams was a pain! But by working with my teams, doing retros, and implementing suggestions to try, I’ve co-created standards with my teams, transforming them from disorganized to delivering value within constraints that they helped establish.

    Getting Started: Establishing Your First Standards

    The most difficult part of establishing team standards is getting started! Thinking about all of the possibilities can be really overwhelming. However, there are some steps you can take to make the process collaborative while moving forward and trying new things:

    • Brainstorm, with your team, the areas of weakness that you see in the organization, teams, processes, and products. Start by asking “What do you think we could be doing better?” Responses will be open and potentially scattered, but that’s okay.
    • Discuss: Ask the team, “If you could only establish three standards to mitigate or remedy these problems, on which areas would you want to have the biggest impact?”
    • Agree: Come to an agreement, and allow for “Disagree and Commit” as a strategy here. The idea is to be flexible, try something out for one or two sprints (or whatever your work cycle happens to be). then report back.
    • Implement and Reflect: after practicing and implementing the change, come back together, and discuss what happened, both what worked and what went poorly. It’s important to do this without judgement or defensiveness, which can alienate team members and prevent them from sharing.

    Using this format and feedback loop to identify problem areas and implement possible solutions helps to decrease resistance to change, because the team is involved in creating the change together.

    Flexible Frameworks: Evolving Standards as Teams Grow

    Just like jazz, standards should (and inevitably will) evolve as the team becomes more mature, and as business needs change. That’s a good thing. The words “we’ve always done it this way” are an enemy of innovation. Anticipating evolution allows you to make necessary changes naturally, as a part of your working process. You might experience the need to change your existing standards (even if they are working for you now!) in some of the following circumstances:

    • Changes in the size of the team, especially if they are rapid (either the team being cut or the team having hyper-growth). Either of these changes the way that teams work.
    • Changes in business priority or release schedules may necessitate changes to team standards.

    Conclusion

    Building effective engineering standards requires both structure and flexibility, individual skill and collective improvisation, a lot like Jazz ensembles. The most successful teams understand that standards are enabling frameworks that emerge from collaborative effort and evolve with experience and time. By involving your entire team in creating coding, communication, and design standards, you build shared ownership and understanding that will carry your team through the inevitable changes and challenges of software development. Using flexible frameworks, your team commits to continuous improvement through reflection, feedback, and the willingness to adapt. Jazz musicians know when to follow the lead sheet (their framework!), and when to veer off of the path and make necessary adjustments. Great engineering organizations work in the same way.

    This is the second post in my Jazz Leadership series. In upcoming posts, I’ll dive deeper into other pillars: practical techniques for building trust, creating the right constraints for innovation, and developing the listening and collaborative skills that help great engineering teams thrive.

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