Two KPIs.

Just a decorative image for the page.

TL;DR

Consider using two basic metrics for your tech teams: “Cycle Time” and “Team Happiness”. It is crucial to ensure they are correctly defined and understood by all team members. Once these metrics are embedded, allow your teams the freedom to experiment with new ones as needed, fostering an environment of constant learning and innovation.

The Problem

In my experience with various teams, I’ve observed a wide-ranging issue: many teams don’t utilize any Key Performance Indicators (KPIs) at all. This absence leaves a void in their ability to track, assess, and improve performance. On the other hand, some teams use an overwhelming number of metrics, which can become a burdensome, complicated web that doesn’t necessarily lead to the desired results or guide the right behaviors.

Here’s a straightforward, practical approach that offers a good starting point and can serve as a springboard for further development.

The Solution

When a team lacks any form of metrics, I recommend commencing with two foundational ones:

  • Cycle Time
  • Team Happiness

Cycle Time

Cycle time is one of the DORA (DevOps Research and Assessment) metrics, brought to prominence by Nicole Forsgren and her colleagues in their insightful book, Accelerate. Interestingly, the original authors have since evolved their approach and are now employing more of a survey-based methodology to assess development teams. It’s thought-provoking that they chose not to establish a company around their four DORA metrics, but instead pursued a different path. This raises a question: Are DORA metrics not as practical as they initially seem?

There may be some merit to this line of thinking. DORA metrics, though seemingly simplistic, can foster a false sense of security. I’ve witnessed this phenomenon multiple times: Teams have impressive DORA metrics, but beneath the surface, dissatisfaction reigns and performance suffers.

To avoid this pitfall, I advocate for beginning not with the complete set of DORA metrics, but with a single, powerful one: Cycle time.

The initial step involves clearly defining what cycle time means within your team’s context. For my teams, I define it as the duration from the start of a story (when a developer begins working on it) until the story is delivered to the clients. As a general rule, this process should not exceed an average of 5 days.

A common misstep is to define the end of the cycle as “when the Pull Request (PR) is merged”. Many automated tools measure cycle time in this way, but it’s fundamentally misleading. The ultimate goal is to deliver value to your clients; the act of merging a PR is merely a step in that process and not the end goal.

Emphasizing the cycle time metric motivates the team to pursue faster delivery times, thereby driving value delivery at a quicker pace.

Team Happiness

Another metric that holds immense importance in my view is Team Happiness. We conduct retrospectives, hold 1:1 meetings, and execute various HR initiatives, all aimed at maintaining a positive team environment. However, there are instances where team members wish to voice their thoughts but lack the appropriate channels to do so.

That’s where the Team Happiness metric can be instrumental.

Ask your team members these two questions, ensuring their responses remain anonymous to promote honesty:

  • How happy are you right now at our company? (rated on a scale of 1-10)
  • What else can we improve? (free text field for open-ended responses)

This approach allows you to track overall happiness levels over time, providing a valuable temperature check on team morale. I typically discuss the outcomes of this metric at team lead meetings and address each issue raised in the free text field. It’s a leader’s responsibility to respond promptly and appropriately if morale begins to decline.

Adjustments and More Metrics

Consider Cycle Time and Team Happiness as a springboard, a starting point in your journey towards a more data-driven performance culture. Once these metrics are ingrained, allow room for experimentation with other measures. Better yet, empower your team leads to undertake this experimentation themselves. Perhaps the remaining DORA metrics will be beneficial, or maybe Objectives and Key Results (OKRs) will evolve into trackable KPIs. Even business KPIs might assist your engineering teams in aligning their work more closely with business outcomes. Adopt an open-minded approach, and ensure that your teams are always focused on the right objectives.

More Information