6 traps when choosing operational metrics for software or digital teams

Because it’s highly conceptual, software development is notoriously difficult to manage with data:

  • On one hand, it’s very clear when something that’s been built–works. And when it doesn’t. And even though it’s digital, it follows a logic almost as objective as those of physics: gravity, thermodynamics, etc. It will be painstakingly obvious to pretty much anyone with a pulse that something’s off.
  • On the other hand, building software is a creative process. There are many ways to approach building a piece of code. At a high level, it’s about solving a business problem or addressing a user need. But when you get into the details, there can be big variations based on what’s easy to make, what’s possible, and what’s attractive to the user.

In an effort to get a bit more quantitative, I started peering into our source code control system. For each person on the team, I noted down the number of commits, or changes to the code, they made over a monthly period.

Working with both larger companies and entrepreneurs, I suspect founders and startups get this intuitively. But beyond a certain size, the bigger companies get so obsessed with efficiency, that they end up spending very little time talking about effectiveness and strategy. So everyone just focuses on efficiency.

Independent of customer needs

This is one of the common traps I tried to address with the Hero Canvas. For established companies, there is an increasing internal focus over time. A lot happens, but customers don’t see it. And to be fair, they might not want to see it all anyway. 🙂 Any work which doesn’t contribute directly to what a customer or prospect might want is “waste”. Some of this waste is necessary, to produce the intended outcome. But at least it’s deliberately added.