Common Software-Related Metrics

The best metrics will be those that are developed based on your team’s and your company’s particular situation, and no one metric will give you perfect information or insight into your team. That said, a number of different metrics have emerged over time as good ones to begin with, and can often serve as a “starting point” for further drill-down or investigation.

Metrics often fall into a variety of different categories:

• Process. Lead time, cycle time, PR-to-review, and so on.
• Reliability. Production outages/incidents, average failure rate, load testing, mean-time-to-recovery, time-to-discovery, and so on.
• Runtime performance. User transactions per minute (or second), simultaneous user sessions, stress testing, soak testing, application performance monitoring, and so on.
• Security. Number of vulnerabilities discovered, time to resolution, time to production deployment of updates, number and severity of security incidents.
• Maintainability/Code quality. Static code analysis numbers, code complexity, lines of code, and so on.
• Responsiveness. Response time to incident discovery, elapsed time to customer bug report.

One thing to keep in mind is that some metrics are measured against the team as a whole, and others are measured against individuals (and some can be applied to either or both). As we’ve discussed in the last section on relationships, psychological safety is paramount when creating a highly-functional team, and being careless here can undo all that effort. When talking about metrics with the team, make it clear which are team aggregated, and which are individual, so that everybody understands what you’re looking for and why. If you measure a given metric simultaneously at both the team level and the individual level, you run the risk of dividing your team: team members will be able to look at other teammates’ numbers and identify “who’s holding us back,” which can create that negative peer pressure. When examining metrics, keep it clear in your head whether you are looking to measure the team as a whole, or individual effort within the team. You need both.

Additionally, be wary of metrics that are focused on “output” as opposed to “outcomes.” It can be very easy to lose track of outcomes—the ultimate end result of the work being done–in the face of the easy metrics generated by your employees’ actions, such as the number of lines of code being written. An old proverb holds that “one should never mistake motion for progress”—a bird can often remain aloft for hours by riding thermal air columns without having to beat its wings once, while the same bird can be flapping its wings for all its worth and make no headway if it is flying headfirst into a hurricane. “Motion,” the number of wingbeats per minute, does not always translate directly into “progress,” or the distance the bird gets to travel. As you gain experience with your team, your company, and your industry, you will find it easier to spot those metrics which are counting wingbeats, and those which are tracking the distance covered. (Better yet, measure both, so that you can tell the bird to land during the hurricane!)