The business pressures of today’s software-driven world require engineering teams to operate at peak performance. But how can you measure performance? Is it the number of weeks in a sprint? Is it time to resolve the issue? Or is it something more qualitative such as collaboration?
There are so many possible ways to measure the performance of your engineering teams it can be difficult to settle on the right metrics. Fortunately, there's a handul of tools out there to help with this.
Why Engineering Teams Need Metrics & Key Performance Indicators (KPIs)
An engineering KPI or metric is a clearly defined quantifiable measure a business can use to gauge the success of software engineering teams over time. With engineering being a very broad field, KPIs are employed in a variety of ways, ranging from company-wide analysis to project-specific performance metrics. Company-wide KPIs can be used to compare against industry benchmarks, while project-specific KPIs can be used internally to evaluate project performance.
Regardless of what you measure, measuring the performance of software engineering teams can have a lot of benefits to the business. It can not only make goals and objectives clearer for individual employees, but metrics and KPIs across teams can help align everyone to common goals as well as provide more focus to your teams and avoid wasteful or duplicative work.
5 things I've learned in 10 years as a developer:— Nader Dabit (@dabit3) April 22, 2021
1. No one knows exactly what they are doing
2. Anything can be learned with enough dedication
3. Perception > reality
4. Taking on the toughest problems pays dividends
5. People like to make things sound complicated for their ego
The Engineering Metrics and KPIs to Track
Typical engineering metrics have focused on individual developer performance. Of course, companies have been measuring employee performance for decades using all sorts of metrics.
But with software engineers, those metrics need to be tailored to the nature of the work, especially as these employees are playing a more critical role in the overall success of the business.
So what are some common software engineering metrics?
- Commit-to-deploy (CDT). This metric measures how long it takes from an engineering committing code to it being deployed. This is especially relevant for DevOps.
- Time-to-code Review. This metric looks at how quickly engineering code can be reviewed and is often employed at the manager level.
- Time-to-merge. This metric examines the time it takes for code to be merged into the larger base and is especially relevant in organizations employing agile methodologies and sprints.
- Rework rate. This metric, represented as a percentage, can help understand the amount of code developed by an engineer that needs to be reworked by more senior software developers.
- Weekly pull request throughput.
I've been reflecting on the status quo of engineering effectiveness metrics. Existing best practices come up short — they hyper-focus on measuring the output of the system instead of the input.— Sam Saccone (@samccone) December 20, 2020
I'm making the case for a new metric: Time to debughttps://t.co/3eN2HQTqpf
There are a number of tools out there to help with capturing and measuring individual developer performance against established KPIs. Some of these tools include:
- PluralSight Flow aggregates historical git data into easy-to-understand insights and reports to help make your engineering teams more successful.
- LinearB analyzes hundreds of signals every minute from your Git and project systems to highlight where you can do the most good for your team.
- SourceLevel provides metrics and automated code reviews for software engineering teams.
- CodeClimate synthesizes the data from your repos to give you full visibility and empowers your team for continuous delivery.
- Athenian shows metrics and insights to software engineering teams who want to continuously improve.
Technology Metrics: the Missing KPI?
A lot of the people-focused metrics are time-related. So what’s causing the time issues? What’s causing engineers to spend more time on deploying and developing? The answer to that may be fundamental to the nature of software development.
A solid 10% of being an engineering manager is asking two people if they've talked to each other yet— Adrienne Porter Felt (@__apf__) February 4, 2020
Contrary to popular belief, software development isn’t just coding. It’s also about selection and planning. On the planning side, it’s simple: spend 80% of development time planning and only 20% coding. In fact, a recent Tidelift survey showed that more than 20% of a developers’ day is spent on non-coding activities, including meetings, management and other operational tasks.
The whole agile and scrum methodologies grew up out of this IBM mindset. The selection side, though, is where things can go sideways. Developers will often look for open-source code, frameworks, and commercial software to form the basis of project functionality or fill in gaps within a larger project. For example, it’s much easier to license a C library than it is to build it from scratch.
But what happens when there is more than one option? What happens when one developer selects option A and another selects option B? Understanding and measuring the metrics for technology selection can help the performance indicators for individual engineers as well as provide more alignment between teams throughout the organization.
Private StackShare for Teams helps you track those very metrics by providing a single record-of-truth for the technologies used throughout your organization’s software development. For example, by tracking the entire technology stack and all the tools, packages, libraries, etc. being used, technology selection for a specific project can be significantly reduced.
What’s more, Private StackShare for Teams can keep track of tool adoption stages, open source utilization, and even version controls. Rather than spending countless hours looking at options for a specific development need, an engineer can just refer to the Private StackShare for Teams portal and select from an already agreed-upon list. When combined with Architectural Decision Records (ADRs), developers have a clear understanding of why a specific technology was chosen.
Want to learn more about ADRs? Watch our CEO Yonas Beshawred take a deep dive in the video below.
When additional features are needed, such as with a new version, again, the selection process is radically reduced as the engineer doesn’t need to waste time finding a commercial or open-source package to meet a certain need. That’s already been done. They just need to request that a new version be approved.
Capture What’s Need to Make Your Engineering Teams Successful
Just measuring people-based metrics won’t make your software development teams as effective as they need to be. To have high-performing teams with the agility needed to meet customer and partner needs quickly and efficiently, you also need to capture metrics about the technology underlying all of your organization’s development efforts.
With Private StackShare for Teams, you can do just that: capture the critical data necessary about your software technology so your individual developers can be more successful.
Check out Private StackShare for Teams for free here. You can also find Private StackShare on the GitHub Marketplace.