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 more clear 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 organization 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 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 organizations design 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

Software architecture and design patterns seem strange, but also strangely obvious, to discuss when talking about team standards. On the one hand, software architectures may already be in place, and norms 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 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 people leaving the team (the bus factor) don’t have an outsized impact on the productivity and progress of the team or project.

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 and understanding about 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 the definition provided on the website:

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 dashboard 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, which area 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.