“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 are going to 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, or 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 have 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 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, EM’s 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 3 best process metrics engineering managers should not miss.
1. Cycle Time
Cycle time needs no new introduction. The metrics is already a sub-part of Google’s DORA metrics, and is 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 time taken to move from first commit to 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 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 with 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 metrics 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 resources 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 less bugs you have to deal with. On top of it, smaller pull requests limited to 200-300 LoC, are easier to review and much 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 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 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 a 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 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 in attending standups, discussing sprint work, meetings, and operational maintenance. Maker time ensures an unfragmented, continuous flow state of atleast 120 minutes to 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 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 helps 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 since 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.
“We are deploying 2x faster than last quarter without any additional cost to the organization. Our last release was a high velocity, zero downtime release. We are still working and excelling on the same budget as last year.”
Extracting actionable insights from metrics becomes a child’s play when EMs are equipped with an engineering analytics tool. Hatica helps engineering managers realize the bigger picture of their development process: higher productivity, greater engineering effectiveness, and continuous collaboration.
💡 Engineering managers use Hatica to drive engineering success, and boost productivity. Learn how we can help you build a data-driven culture for your teams.
Subscribe to the Hatica blog today to read more about unblocking developers, and boosting productivity with engineering analytics.
Top comments (0)