How to Improve Software Development Velocity Without Breaking Everything

A friend called me a while back. He runs a software company, and he has 16 developers. Any problem he has, he can call them up, and they fix it fast, and they do good work. I’m not knocking the developers at all.

Here’s the catch.

His application breaks all the time. Something is on fire almost every day, and his team spends most of its energy putting those fires out. From the outside it can look like a strong, responsive team. It isn’t.

It’s a team stuck running in place.

When he described it to me, the problem was obvious, and it had nothing to do with how good his developers are. I’ve seen this exact pattern more than once.

He didn’t have the engineering leadership or the process to turn 16 capable people into a team that ships safely.

Nobody was doing real quality assurance (QA). There were no unit tests, no automated testing, and no shared sense that quality was part of the job. There was no culture of quality at all.

That’s what this article is about: the balance between going fast and not breaking everything. And I’ll tell you up front where I land. Software development velocity isn’t about how fast your developers type. It’s about whether leadership has built a system where moving fast doesn’t blow things up.

What software development velocity actually means

Most people think velocity is about how much code you write, or how many features you ship. The standard definition runs right along those lines: how much working software a team delivers in a given stretch of time. If you want that textbook version, Wikipedia has a fine one.

I think that framing is wrong, and it’s the root of the whole problem.

Velocity isn’t how much you ship. It’s how much value you actually deliver to your customers. A pile of new features means nothing if customers don’t get something better out of it, and software that breaks delivers no value at all. So quality isn’t the thing standing in the way of your velocity. An app that’s on fire every day has negative velocity, no matter how many commits the team pushed this week.

Quality is part of velocity.

This is the difference between feeling busy and being productive. My friend’s team felt incredibly busy. Everyone was slammed, all day, every day. But they weren’t productive, because almost none of that effort turned into something better for a customer.

In my book Product Driven, I put it simply: “done” isn’t when the code ships, it’s when the customer gets value. A feature that ships and then breaks didn’t get anyone closer to done. It just added a fire to fight tomorrow.

I’ve written more about this in the engineering productivity paradox, where being busy and being productive turn out to be completely different things, and about why sprint velocity drops on remote teams if you want the measurement side. This post is about the cause underneath all of it.

Why fast teams break things

Go back to my friend’s 16 developers. They’re good engineers. The problem isn’t them, it’s the system around them, and that’s true in most teams I see stuck this way.

When there’s no automated testing and no real QA, every change is a gamble. A developer fixes one thing and quietly breaks another, and nobody finds out until a customer does. So the team fixes that, and breaks something else. Round and round it goes. Each fix sits on top of a growing pile of technical debt, and the pile makes the next change riskier than the last.

Now look at where the time goes. Every hour spent firefighting is an hour not spent building the thing customers actually asked for. The team is maxed out, and almost nothing new is getting delivered. My friend could add four more developers and all he’d get is four more people fighting the same fires.

That’s the firefighting trap, and you can’t hire your way out of it.

This is the part leaders miss. A capable team will firefight forever if nobody changes the system they’re working in.

Skill was never the bottleneck.

Software development velocity is a leadership problem, not a coding problem

Once you see it that way, the fix stops being about the developers and starts being about you, the leader. In my experience there are three leadership failures that put a team in firefighting mode, and they almost always show up together.

The first is that the team has no permission to invest in quality. The second is that leadership says yes to everything and changes direction constantly. The third is that quality gets treated as somebody else’s job, usually a QA person at the end of the line, instead of something the whole team owns.

All three are leadership decisions, not coding decisions.

They map directly onto two of the pillars from Product Driven: focus and ownership. The good news is that things you decide are things you can change.

I’m not the only one who sees it this way. Adam Horner, a chief technology officer (CTO) coach I talked to on the Product Driven podcast, describes the hard shift every technical leader has to make, from being the hero who fixes everything to being the leader who builds a team that doesn’t need a hero. When the app is always on fire, the bottleneck usually isn’t the engineers. It’s the leader who never built the system that would stop the fires.

Give your team permission to slow down for quality

Your team watches what you reward. If the only thing that gets praised is shipping fast, then writing tests, refactoring messy code, and fixing root causes will feel like the slow, unrewarded work nobody has time for. So it won’t happen.

Quality dies quietly, and not because anyone ever decided it should.

One of my favorite lines from the book is about focus: there will be bugs, surprises, and fires, so make space for them. Planning for quality work isn’t admitting defeat. It’s just being honest about how software actually goes.

A leader who never makes room for that work is the reason the fires never stop.

Let me give you a real example of what changes when people own quality. At Stackify, the developer-tools company I founded, we put engineers on a regular on-call rotation. If something broke, the person who built it heard about it and fixed it. If a customer was angry, that engineer felt it directly. It changed how they worked, because they had to live with what they shipped. Quality went up, and it went up on its own, because the people writing the code were now the people feeling the consequences of bad code.

That’s ownership of quality, and leadership creates it. John Durrant, who I had on the podcast to talk about engineering culture, frames healthy teams around mastery, autonomy, and purpose, and that’s exactly what an on-call rotation taps into. People care about the work when the work is genuinely theirs.

So what does giving permission look like in practice? A few things I’d start with:

• Protect real capacity for automated testing and paying down technical debt. Put it in the plan, don’t leave it as the thing people do “if there’s time,” because there’s never time.
• Make your definition of done include quality. If it isn’t tested, it isn’t done, and the team should know you mean it.
• Reward the engineer who fixes the root cause, not just the one who heroically stays up until 2 a.m. patching production. The hero culture feels good and keeps you broken.

Stop changing direction

Here’s the velocity killer almost nobody names: constant changes in direction. Saying yes to every new idea, reshuffling priorities every week, chasing whatever feels urgent today. You don’t have to rebuild the thing you should never have built in the first place, and half of velocity is just not creating that waste.

I’ve fallen for this myself. At one company an engineer pitched me a quick, harmless little feature. It took a month, and it pushed back work that actually mattered. That’s the real cost of saying yes to small, misaligned things.

They’re never as small as they look.

In the book I argue that focus isn’t defined by what you say yes to. It’s defined by what you’re willing to say no to. That includes saying no to your own shiny ideas, which is the hardest no of all.

There’s a trust cost too. When decisions keep getting overridden and the direction keeps shifting, your team stops believing their work is safe. Why would they invest in doing something well if it might get scrapped on Friday?

Whipsawing the direction wrecks morale and velocity at the same time.

This is why getting the priorities right is part of going fast. If you struggle with that, a simple scoring approach like the RICE prioritization framework helps, and being honest about your team’s real capacity keeps you from cramming ten things into a sprint that holds six.

Build a quality system so speed doesn’t depend on heroes

Permission and focus set the culture. Now you need the machinery, so quality is built into how work flows instead of riding on one careful person’s shoulders. The practical stuff here is well understood.

The point is that leadership has to actually install it.

Start with automated testing and a solid CI/CD pipeline, continuous integration and continuous delivery, with quality checks built in so bad code gets caught before it reaches a customer. Part of that is knowing when to automate a test and when to test it by hand. When the tests run themselves, quality stops depending on whether someone remembered to check. Frequent, small merges to the main branch, an approach often called trunk-based development, keep changes small enough to reason about and reduce the painful merge messes that eat days.

Keep code reviews light and fast so they catch problems without becoming a bottleneck. Size the work small, because a giant pull request is impossible to review well and dangerous to ship. And stop bolting QA on at the very end. Embed it in the team, the way good cross-functional teams do, so quality is everyone’s concern from the start instead of a gate at the finish.

Finally, measure both speed and quality together, or you’ll optimize one by quietly wrecking the other. The DevOps Research and Assessment (DORA) program gives you four metrics that do exactly that:

Speed	Quality
Deployment frequency (how often you ship)	Change failure rate (how often a change breaks something)
Lead time for changes (commit to production)	Mean time to recovery (how fast you fix a failure)

Watch all four at once. If deployments speed up while your change failure rate climbs, you don’t have more velocity.

You have more fires coming.

How AI changes the velocity-quality equation

You can’t write about software development velocity in 2026 without talking about AI. So here’s my honest take.

AI makes writing code cheap, which means it amplifies whatever system you already have. If you’ve built a real quality culture, AI is a gift. Your team ships more, and the tests and reviews catch what the AI gets wrong. If you haven’t built that culture, AI just lets you break things faster, because now your team generates more code, ships more of it untested, and lights more fires doing it.

My friend with the 16 developers doesn’t need AI. He’d just generate his next outage quicker.

This is why I tell the engineers at Full Scale that the job is moving away from typing and toward judgment. The skills that matter most now are what I call the three C’s: communication, curiosity, and courage. Engineers need the courage to push back when something’s being rushed, and the curiosity to really understand a problem before they generate a solution to it. AI raises the value of all that human, product-thinking work. It doesn’t replace it, and it definitely doesn’t replace the leadership job of building a system that catches mistakes.

What a team set up the right way looks like

Picture the difference. On one side you’ve got 16 talented developers who can fix anything but break something new every day. On the other you’ve got a team that shows up with leadership, process, and a quality culture already in place, so the speed is real and it holds.

That gap is the whole difference between activity and real software development velocity.

This is the thing we obsess over when we build development teams at Full Scale. Our engineers are trained on the Product Driven approach, so quality and ownership aren’t an afterthought, they’re how the team works from day one. It’s a big part of why we hold a developer retention rate above 93 percent and were named Great Place to Work Certified in the Philippines. Stable, engaged teams that own their work don’t live in firefighting mode.

The technical practices in this article are real and they help. But they only stick when leadership decides quality matters, protects the time to do it, and stops changing the plan every week. Get that right, and you can move fast without the wreckage.

Stop firefighting and start shipping

If your team can fix anything but breaks everything, the gap usually isn’t your developers. It’s the leadership and process around them. That’s exactly what we help companies build. Schedule a call with Full Scale and let’s look at where your team is losing velocity, and how to get it back without breaking more along the way.