6 Must-Have Software Metrics for Engineering Managers

"How is the release pipeline going?" is a common CTO-EM conversation today. However, whether the two tech leaders find a common language to answer this question- that's what we will talk about. 

A common pattern across engineering managers is their struggle in quantifying 'real' metrics on engineering work. Mostly, it is about the difference in priorities for EM vs. C-suite; the other times, it is about disagreements over 'what' needs to be measured- the product, process, or both.  

Understanding, acknowledging, and even tracking engineering performance is a complex task, especially when the company's tech has an overwhelmingly high pace. This is crazy and unsustainable in real-world scenarios. That's where diversifying your metric basket becomes vital. In this post, let's see the top software metrics that every engineering manager should focus on, along with why they really matter.

Software Metrics From an Engineering Manager's POV 

Tracking software metrics has a compounding effect on overall engineering performance. And that's why engineering managers today are looking to find robust metrics to support their delivery flows and work towards creating superior quality products. 

Traditionally, software development has been seen as a mechanical process. Even the waterfall approach is a testament to the linear nature of yesteryear SDLCs. However, as tech becomes more specialized, the development approach too has to shift towards quality metrics and not just insisting too much on velocity and dated deliveries.  

The software economy is already filled with too-many engineering metrics. So how to find the ones matching your requirements? 

Usually, EMs use a three-point approach- a combination of developer well-being, SDLC health, and final product, to find their needle-like metrics from the enormous software haystack. Using a holistic mix of product, process, and people metrics can bring true workability to engineering teams.

Process Metrics

Here is the list of the three best process metrics engineering managers should not miss.

1. Cycle Time 

Cycle time needs no new introduction. The metrics are already a sub-part of Google's DORA metrics and are a constant reminder for teams to double down on both release quality and velocity. 

Cycle time is an indicator of a team's delivery velocity and tracks the time taken to move from first commit to the final deployment. A high cycle time should ring warning bells to engineering managers as it is the most fundamental indicator of a healthy SDLC.

Moreover, cycle time as a metric is a goldmine of data and other process indicators when tracked right. A high cycle time is an opportunity for engineering managers to break down their traditional process silos and move towards efficient workflows. 

If a high developer workload is causing spikes in cycle time, engineering managers can delegate work and even deprioritize non-core tasks from the developer worklist. 

In another scenario, developers have optimized their coding and pickup times, yet the deployment time is higher than the team's benchmarks, causing an inflated cycle time. It might be due to slow tests, flaky builds, or long wait hours. Engineering managers can keep iterating and niching down till they can fully rationalize cycle time. Pairing the cycle time data with PR size, average LoC, and coding time can help team leads in reducing deep-rooted development bottlenecks.   

2. Dev Throughput 

In an engineering pipeline, throughput is the bridge between speed and quantity. Usually, throughput is tracked in terms of features released or tasks completed within a time frame. Most teams collate 'tickets' to determine the final team throughput for a month/quarter and compare them with a benchmark to determine engineering efficiency. 

However, throughput is much more than just the number of issues completed. Trying to decode throughput with issues only is like building a product without talking to a consumer- A total disaster, in a nutshell. 

Throughput becomes an important engineering metric as it helps EMs to identify the work type proportion among teams. The metric filters teamwork based on features, bugs, and tasks. With visibility in throughput trends, teams can plan their next sprints effectively and even remove instances of any unplanned work.   

However, EMs should only benchmark throughput as a team metric after realizing the work complexity and resource constraints. Else, monolithically tracking throughput might backfire on teams.  

3. PR Size

The metric is an unconventional one and is usually underestimated for what value it brings to code quality. Developers, by habit, create large pull requests. It is easier and doesn't take much time. Plus, writing smaller PRs requires extra discipline, and most devs would want to trade it at any cost.  

A smaller PR size is a true hygiene indicator of your development process. The smaller the PR size, the fewer bugs you have to deal with. On top of it, smaller pull requests, limited to 200-300 LoC, are easier to review and much more legible than the usual 1000 LoCs. 

Engineering managers should keep focusing on PR size to inculcate a culture of discipline, improve code readability, and reduce collaboration silos in teams. 

4. Sprint Velocity  

A successful sprint planning is 1/3rd of the actual work done. It puts teams into perspective, sets project milestones, and creates space for teams to collaborate with available resources. The next step in realizing sprint goals is through an optimum sprint velocity. 

Sprint velocity is the ratio of tasks achieved by teams in each sprint without compromising on quality. A high sprint velocity potentially translates into high delivery velocity and even a reduced time to market, making it a vital metric for EMs. 

However, sprint velocity, too, is spread across variables and should incorporate issue distribution (bug vs. new feature vs. epics), issue against story points, and planning accuracy to get a true picture of your sprint health. 

Well-Being Metrics 

Most of the metrics listed above are tangible in the sense that they can be easily measured and follow a long trail of objective numbers. However, when it comes to subjective indicators, like developer productivity, or team happiness, engineering managers often lack a documented process to measure or even define these metrics. 

Despite the willingness to contribute more to developer lives, engineering managers struggle to materialize morale metrics. With time and greater workload, these critical litmus tests vanish somewhere between conversations of delivery and throughput. Well-being metrics are vulnerable metrics and, if acted upon, can deliver exponential value to the overall developer experience. 

5. Maker Time

The Maker Time metrics track the 'deep work' hours of developers. A large chunk of a dev's day goes into attending standups, discussing sprint work, meetings, and operational maintenance. Maker time ensures an unfragmented, continuous flow state of at least 120 minutes for developers so they can focus back on core tasks.  

With maker time, EMs get granular visibility into a dev's typical workday- how much time a developer spent without context switching. The perfect case scenario is 70% maker time/day. With the metrics data, managers can even ensure sustainable work distribution in the next sprints.   

6. Work Hour Breakdown 

Maker time helps managers to ensure a fixed time zone for core developer tasks. However, it is easier said than done. Even in their key tasks, developers spent a lot of time sitting blocked or doing unproductive work. Waiting for code reviews across time zones, 24*7 lights on, and high incident alerts can lead to overworked developers. 

With the work hour breakdown metrics, EMs can easily trace a developer's work hours against the officially sanctioned ones. If the breakdown metrics breach the regular limit, managers can reshuffle their IC's work hours or limit external noise so their devs can go back to productive flow states.  

Leveraging Software Metrics for Engineering Success 

Now that we are clear about what metrics engineering teams should track, it finally becomes easier for engineering managers to answer: How is the release pipeline going?

These engineering metrics, when armed with data, help facilitate continuous improvement in teams. Looking at these metrics in consonance is more or less similar to finding the missing pieces of your SDLC equation- blockers that have plagued your team for ages or unproductive work that hampered team workflow.

With enough context, engineering managers can translate these technical metrics into a common business language so all leaders across the hierarchy feel involved in the engineering processes. 

Extracting actionable insights from metrics becomes child's play when EMs are equipped with an Engineering Management Platform. An Engineering Management Platform helps engineering managers realize the bigger picture of their development process: higher productivity, greater engineering effectiveness, and continuous collaboration.