A Checklist for Modern, High-Performance Engineering and Product Orgs

You see this in many industries, from banking (like Q2 Banking) to office space (like WeWork). The writing is on the wall, and companies everywhere continue to rebrand as SaaS or technology organizations. 

Based on this, you might assume that leading software companies equally modernize engineering organizations and processes to actually build products—but that isn't always the case. Despite using innovative software delivery tools or the latest coding language, most engineering teams still rely on 20+ years-old processes and reporting (or no reporting at all) to do primarily manual and ceremonial jobs. Furthermore, like stand-ups, these tasks usually mean very little to anyone outside the engineering organization. 

True high-performance engineering requires operating and communicating differently—in a way that provides visibility, ownership, continuous improvement, and collaboration across all business functions. 

The 7 Traits of a Modern Engineering Organization

In building Allstacks, we’ve observed thousands of dev teams and talked through just as many processes. From that experience, I’ve noticed seven things that the most successful of them all have in common. What follows are the best practices for defining a modern, high-performance engineering and product org.

1. Be interrupt-driven, not polling-driven.

Traditionally, engineering teams rely on ceremonies like stand-ups and retrospectives to get a pulse on how work progresses, unblock work, keep things on track, and improve processes. However, since they look backward, point-in-time meetings don’t prioritize action or create a sense of urgency. As a result, it’s easy to miss the forest for the trees.

With the advancement in collaboration tools, we can operate and unblock work in real-time to increase productivity and reduce potential risks to delivery. One critical step in this direction is automatically getting key updates pushed to you, rather than through tons of status meetings. This allows you to have more ad hoc conversations about specific issues with specific outcomes and fewer “standing” meetings that draw issues out inefficiently. 

2. Don’t repeat yourself.

Building the right thing well and delivering it to market in a successful, coordinated effort requires all that all business units be informed, aligned, and swimming in the same direction.

Somewhat counterintuitively, each of these teams has its own discrete set of tools, processes, and reports, making it difficult for everyone to remain on the same page. It’s better to provide updates in a single system on the same set of data than in multiple systems.

Stringing together a complete picture of project status (never mind forecasting) between Slack, Jira, Basecamp, and other tools is at best inefficient and downright inaccurate at worst. Rather than manually reading and rewriting reports, which can lead to data loss, businesses should work toward alignment within and across their organization by syncing data automatically.

3. Stay aligned to engineering targets and KPIs.

I can feel you start to itch at the mere mention of "KPIs," so I’ll get straight to the point: KPIs can be critical drivers of high performance when set up carefully, with purpose, and mapped to more significant initiatives.

We know that a single metric can lack enough context to be meaningful and that chasing KPIs can sometimes devolve into urgent but ultimately unimportant tasks. To avoid this, engineers should develop engineering KPIs considering broader organizational and company KPIs.

For instance, it should be clear that measuring “mean time to recovery (MTTR)” at the engineering level will help meet your SLA target at the company level. While company KPIs may not always be quantifiable, they should be at the engineering level. If you want to communicate new features and their delivery date for marketing to plan promotions, then the KPIs below should have measurable metrics. Engineering could then document releases in Jira, outline the information in the Epic, and create a Confluence page with feature screenshots and full descriptions.

For more tips on developing KPIs and aligning work to them (without making your team’s head explode), read this article on creating KPIs for engineering. 

4. Cross-check for safety. 

We’ve all heard the “cross-check complete” announcement on a flight, but perhaps we haven't thought very deeply about it. Cross-Check is one of the most essential safety measures in air travel; it exists because even the most well-intentioned and trained people can sometimes make mistakes. However, the odds of two people making the same mistake are much lower.

Having two indicators for the same engineering outcome serves much the same purpose. (Cycle time and ticket size are one of those pairs.) Optimizing for a single metric may lead to significant deficiencies in other places, while tracking two or more metrics can help catch and prevent this type of error. 

5. Be transparent.

As anyone who’s experienced it knows, there’s nothing worse than “surprise failure." It's the moment when business stakeholders unexpectedly learn a delivery is at risk. Recovery mode kicks in to salvage the go-to-market efforts—as well as the relationship between engineering and the rest of the organization.

We’re often afraid of true transparency in engineering for fear of signals being misinterpreted or taken out of context. But smooth releases (and positive relations between departments) start with sharing information so that everyone can set their sights on the same destination and arrive simultaneously.

One key thing to understand is that mistakes will happen, and timelines will be delayed. What matters is how you react and move forward. In other words, support a culture of positive failure. It’s okay for things not to go exactly according to plan, but you should talk about it and adjust. Make data, status, growth, and blockers visible to all. Make progress on goals and target outcomes visible to all.

Allstacks isn’t the only one embracing transparency in the tech industry. Check out the 100 most transparent tech companies of 2021. 

6. Develop contracts with customers and other parts of the business.

As engineers, we set out to build, maintain, and ship great software. Within that process, we have two key commitments. First, we set our own goals and attempt to meet them, as discussed in #3 above.

Our second commitment is external—SLAs for customers ticket response times, product delivery dates, and more. To follow through on this, we need to attach interdependencies with other departments to KPIs. It’s crucial to work with other leaders to develop a sense of shared commitments so you can prioritize the right things and surface any issues that may impact everyone else—before it’s too late.

Making those into KPIs and tracking them as primary engineering outcomes will help you build an engineering organization that focuses on what matters, prioritizes the right things, and ultimately fosters trust and camaraderie instead of conflict and blame.

7. Give teams space to grow.

Remember that deciding on a goal is not the end of the journey. Making changes to your team and its works takes a period of adjustment and ongoing evolution. You should expect teams to take some time to reorient, learn, adapt, and provide feedback on any metric or goal you set together.

Just as waterfall development struggles with incorporating feedback, waterfall KPIs do too. That’s why targets should be evaluated regularly, and groups (or individuals) should set their own targets that align with business strategy. 

When you think about modern, high-performance engineering and product orgs, who comes to mind? Read up about how developers at Spotify stick to the “Golden Path” in order to keep performance high.

What other traits should make it on this list? I would love to connect and hear what's working for your teams. 

- Jeremy

Does your organization score 7/7? Allstacks can help you get to that perfect score. Check out this post for more tips on evolving your team into a modern, high-performance organization.