jessingrassellino

Tag: management

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

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