All companies are – or should be – software companies. Regardless of industry, businesses everywhere are innovating and modernizing product offerings to include software to stay competitive. You see this in many industries, from banking (like Q2 Banking) to office space (like WeWork). Companies everywhere are rebranding themselves as a SaaS or technology company.
You might expect that leading software companies have equally modernized engineering organizations and processes to actually build products, but that’s not 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, these tasks, like stand-ups, 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 their processes. From that experience, I’ve seen some common best practices that help define what it means to be a modern high-performance engineering organization.
Be interrupt-driven, not polling-driven.
Traditionally, engineering teams rely on ceremonies like stand-ups and retrospectives to get a pulse on how work is progressing, unblock work, keep things on track, and improve processes. However, point-in-time meetings don’t prioritize action or create a sense of urgency since they look backward. 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 be more productive and reduce potential risks to delivery. One critical step in this direction is automatically getting key updates pushed to you, not 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 try to draw those out and prevent work from happening.
Don’t repeat yourself.
Building the right thing well and delivering it to market in a successful coordinated effort requires all business units must 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 far better to provide updates in a single system on the same set of data, not in multiple places. String 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. Businesses should work toward alignment within and across teams by automatically syncing data rather than manually reading and rewriting into reports, which leads to data loss.
Stay aligned to engineering targets and KPIs.
I can feel you getting uncomfortable at the mere mention of ‘KPI,’ so I’ll get to the point quickly: 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. So, engineering KPIs must be developed in consideration of 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. For example, if a goal is to communicate information about new features and their delivery date for marketing to plan promotions, the KPIs below should have measurable metrics. The associated trackable activities for engineering would be to document releases in Jira, outline what was included 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.
Cross-check for safety.
We’ve all heard the “cross-check complete” announcement when we fly but perhaps 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.
As our founder describes in this article, 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 – and 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, timelines will be delayed, and what matters is how you react and rally to move forward. In other words, support a culture of positive failure. It’s okay for things to not 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.
Develop contracts with customers and other parts of the business.
As engineers, we all set out to build, maintain, and ship great software. In 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 important 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.
Give teams space to grow.
Keep in mind that deciding on a goal is not the end of the journey. Making changes to your team and how it 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 as a team. Just as waterfall development struggles with incorporating feedback, waterfall KPIs suffer from the same illness. That’s why targets should be evaluated regularly, and groups (or individuals) should set their own targets that align with business strategy.
What other traits should make it on this list? I would love to connect and hear what's working for your teams.
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.