Are Your Teams Getting Better? The Technical Signals That Tell You Why.

Are our teams actually getting better?

It’s a simple question, and not enough technology leaders are asking it. Some assume the answer is yes. Others are too buried in day-to-day delivery to step back and check. But every leader should be asking it, and that’s more true today than it was even a few years ago.

Teams are moving faster than ever, and AI is a big reason why. AI tools can help a team produce working code at a pace that would have seemed unrealistic not long ago. That speed is an opportunity. It’s also a risk. If you’re not watching whether your teams are genuinely improving, AI just helps you move faster in whatever direction you’re already headed. Including the wrong one.

So it’s worth asking honestly. Are your teams shipping value faster, creating fewer defects, and keeping the system easy to change? Or are they slowly turning it into something nobody wants to touch?

Most of us reach for DORA metrics to answer that, and that’s the right instinct. Deployment Frequency, Lead Time for Changes, Change Failure Rate, and Mean Time to Restore are some of the best indicators we have for how well a software organization delivers.

But DORA has a blind spot. It tells you what’s happening. It doesn’t tell you why. And if you can’t see the why, it’s easy to spend real time and money fixing the wrong thing.

DORA Shows the Symptoms, Not the Cause

Picture three teams, each with a high Change Failure Rate. All three keep shipping changes that cause incidents or defects in production. On the surface, they look like they have the same problem.

They don’t.

One team might have almost no automated testing, so nothing catches a mistake before customers do. Another might have copied the same logic across dozens of files, so every change risks breaking something far away. A third might be bundling weeks of work into one big release, so when something fails, nobody can tell which change caused it.

Same symptom. Three completely different cures.

This is where a lot of organizations get stuck. They can see something is wrong, but they don’t have the signals to tell them what’s actually holding the system back. It’s worth borrowing one idea from the Theory of Constraints here: in any system, only one or two things are the real bottleneck, and effort spent improving anything else is mostly wasted. Finding the true constraint is the whole game.

Five Signals, and the Questions They Let You Ask

When I want to understand what’s really going on inside a delivery system, I look at five signals. They fall into three groups, and each group answers a different kind of question.

Delivery Signals

These tell you whether value is reaching customers, and whether it’s getting there safely.

When leaders tell me delivery feels slow, one of the first things I ask is: are teams finishing work, or just starting more of it? It comes back to a simple principle: start finishing, stop starting. Deployment Frequency is often less about speed and more about flow. The question for you as a leader: are we shipping in a steady rhythm, or is everything perpetually “almost done”?

Change Failure Rate tells me how safely teams are moving. One of my favorite sayings is “be quick, but don’t hurry.” The best teams move fast, but they stay in control while they do it. The question for you: when we move fast, do we stay in control?

Code-Health Signals

These are the signals DORA doesn’t give you, and they’re usually where the why lives.

When engineers start saying, “I’m afraid to touch that file,” cognitive complexity has usually already won. When cognitive complexity climbs, teams are usually patching around problems instead of simplifying the design. The question for you: is the system getting easier or harder to change?

Churn and Hotspots show you which parts of the system change the most. Churn is how often a file gets edited. A hotspot is a file that’s both changed often and complex. Sometimes a hotspot is the beating heart of the business. Sometimes it’s just a constant source of pain. Either way, it tells you where engineering attention will pay off most. The question for you: where is our risk concentrated?

Flow Signal

This one tells you how work actually moves.

Average Commits to Main per Day tells me whether teams are integrating work in small, safe steps. Higher commit frequency usually points to trunk-based development, which means small, frequent merges instead of long-lived branches. That gives you faster feedback and lower release risk. The question for you: are we working in small steps, or big risky ones?

Back to Our Three Teams

Here’s the payoff. These five signals do something DORA on its own couldn’t. They tell our three teams apart.

The team with no automated testing shows up in Change Failure Rate, paired with near-zero test coverage. The team with duplicated logic shows up in rising Cognitive Complexity and a cluster of hotspots. The team bundling big releases shows up in a low Commits to Main number.

Three teams, one shared symptom, three completely different stories. And now you can make three well-aimed investments instead of one expensive guess.

Signals, Not Targets

One of the biggest mistakes I see leaders make is turning a metric into a goal.

The moment a metric becomes a target, teams start optimizing the number instead of the behavior behind it. You get gaming, heavier process, and a lot of noise. People spend more time explaining the metric than improving the system. In the worst cases, you create an unsustainable pace where engineers are rewarded for chasing numbers instead of building good software.

Metrics should help you ask better questions. They should create understanding. They shouldn’t become a scoreboard.

A Real Example

I recently worked with a team supporting a legacy application that was three to five years old. When we started, it had no automated tests at all. Code coverage was effectively 0%.

Change Failure Rate was high, and so was Mean Time to Restore. Every production issue was stressful because nobody had much confidence that a fix wouldn’t make things worse.

Over time, the team adopted automated testing, trunk-based development, and feature flags. Coverage went from 0% to about 15%. That’s not a high number, but it was the first real safety net the team had ever had. Commits to main went up as work started moving in smaller, safer steps.

The results were significant. Defects dropped 63% quarter over quarter. Mean Time to Restore fell from days to hours, because the team could finally deploy a fix whenever they needed to. That meant customers spent hours, not days, living with a problem.

The DORA numbers improved too. But not because anyone was chasing them. They improved because the engineering system improved.

Why This Matters Even More with AI

AI coding tools can be incredibly effective. They can also produce insecure code, duplicate logic, and changes that are hard to understand and maintain. And they can do all of that faster than any human team ever could.

That’s exactly why these signals matter more in an AI-enabled organization, not less. They’re how you see the side effects. AI-generated code tends to push up Cognitive Complexity, create new hotspots, and raise Change Failure Rate when it ships without strong review and tests. Those three signals become your early-warning system.

Watch them, and AI accelerates good delivery. Ignore them, and AI just helps you create bad software faster.

Here’s the one idea I hope you remember: AI amplifies the engineering system you already have. If your teams work in small increments, keep the code clean, and have meaningful tests, AI speeds them up. If your systems are fragile and hard to change, AI amplifies that fragility too.

What These Signals Don’t Tell You

One honest caveat. Everything above tells you whether your teams are building software well. Safely, sustainably, and in a way that stays easy to change.

None of it tells you whether they’re building the right software. The features and outcomes that actually matter to customers. That’s a separate question, and it’s just as important. I’ll take it on in the next article in this series.

A Practical Next Step

You don’t need a new dashboard. You need a better conversation.

At your next engineering review, ask your leaders to bring these five signals, and ask them to bring the story behind the signals too. Pick the one or two that map to your biggest current pain, and keep asking why until you reach a root cause you can actually invest in.

Because the goal was never to collect more numbers. The goal is to understand the engineering system that produces your software, well enough to improve the right part of it.

This post comes from our software engineering practice, which specializes in refactoring application architecture and optimizing delivery to support modular teams, faster feedback, and continuous value delivery.