Last Sunday, my husband finished the Antwerp Half Marathon, something he was really looking forward to.

He was so determined! He stuck to a special diet, followed his training plan like clockwork, and made sure to get plenty of rest. All that dedication really paid off when he finally crossed that finish line.

His unwavering dedication was genuinely inspiring, and it got me thinking about what kept him going.

So I asked him, “Do you think you’ll finish under 2 hours? I know that’s a good time for a half-marathon.” I was surprised by his response. He said, “You know, Sunny, my main goal isn’t about the finish time. What I really want is to boost my speed by 1 km/h compared to my last performance.”

Okay, that’s really smart! His final rank in the race wasn’t what pushed him. It was all about self-improvement for him. And here’s something cool: he finished the marathon in only 1 hour and 52 minutes, beating his own expectations, even though he hadn’t set that as a goal!

Rethinking Industry Standards for Software Development Teams

Fast forward two days ago, a client of mine, VP of Engineering in a fintech company overseeing more than 60 teams, approached me with a peculiar “request.”

So, he asked me if I could help him out with some “industry standards” for his software development teams to use as a reference point. To explain his basis, he sent me this study chock-full of benchmark figures. He thought that if his teams could match up to these standards, it would mean they were doing a stellar job.

I have to admit, at first, I was a little taken aback by his request. Not because I thought his intentions were questionable. It was just, my husband’s words kept coming back to me, “the main goal isn’t about the finish time”.

And then it struck me. What made me uneasy about the whole thing was that he appeared dead-set on putting these unrealistic expectations on himself and his teams. He was absolutely convinced that they had to meet someone else’s benchmark, thinking that falling short would be a failure.

But here’s the thing, this mindset is just fundamentally flawed.

Let’s talk about the main flow metricscycle time, throughput, and work in progress for a moment. The idea of an industry standard in these areas is a myth, and I’ll explain why.

Your business is unique.

The clients you work with, the way your teams operate, the nitty-gritty of your processes, your strengths, your weaknesses – all of these aspects are unique to your organization and can differ significantly from one company to another.

So, why compare your outcomes to those of others?

It’s irrelevant. The context is just entirely different. It’s like trying to compare your lifestyle to that of a friend simply because you happen to be the same age.

And here’s the thing: it’s not just inconsequential; it’s disruptive. Setting unrealistic, one-size-fits-all benchmarks is a recipe for disaster. It leads to guilt, frustration, a drop in confidence, and all of this happens even when your team hasn’t really done anything wrong.

So, let’s get rid of the idea that there’s some industry standard for your software development teams. The truth is, nobody out there shares your specific business context. That’s the bottom line.

Why Industry Benchmarks Fall Short in Software Development

The thing about flow metrics is that they are relative.

For instance, suppose your team’s cycle time at the 85th percentile is 23 days.

How to set personal industry standards for your software development teams using the Executive Dashboard by Nave

Use the Executive Dashboard by Nave to define specific standards for your software development teams. Start a new trial! →

Now, is this a good or a bad thing?

Well, your cycle time for the previous month points to about 41 days which means that your team reduced your delivery time by 44%!

That sounds pretty good to me.

Is there still an opportunity for improvement? Comparing your cycle time with the team’s performance in the past 3 months and the past 6 months certainly starts the conversation.

How to evaluate performance trends for your software development teams using the Executive Dashboard by Nave

With the visual indicators on the Executive Dashboard, you’ll see at a glance where you need to put your focus and which teams need your attention (yes, you can add ALL of your teams here!) Start your free trial now

As long as you understand why your cycle time varies over time, you’re in a good spot. The real concern only kicks in when your metrics are all over the place, and you have no clue why.

Having the right perspective is crucial when you’re looking at your flow analytics. Without it, all that data is just a jumble of numbers.

When it comes to evaluating how well your improvement efforts are working, the most sensible approach is to dig into your own historical data.

Don’t waste time comparing your teams to industry benchmarks.

Don’t measure yourself against someone else’s yardstick.

Make sure it’s your own past performance you’re measuring up against, not someone else’s. That’s the way to go.

Here’s your action item: Take a good look at your historical data – go back a month, three months, even six months, and compare it to where you’re at now. Dive deep into the numbers. What’s the story your flow metrics are telling? Are they going up, down, or staying steady?

These numbers, my friend, hold the answers you’re after. They’ll tell you whether you’re headed in the right direction.

The path to reaching your teams’ full potential is all about consistent, step-by-step improvements, with your own data as your guiding light.

I hope this message has lightened your load a bit and clarified that success is simply about progress. If you’re making progress, kudos to you! And if you’re not, don’t worry, learn from the experience, and keep moving forward.

If you know someone who could benefit from this perspective, please pass it along. Your support in spreading the word means a lot.

I hope you enjoyed this week’s piece of managerial insight. Wishing you a fantastic day, and I’ll be back next week, same time, same place. Bye for now!

Do you find this article valuable?
Rating: 5 stars (4 readers voted)