I’ve walked into a few engineering organisations now where quality had quietly gone wrong. The symptoms are always similar. Incidents that keep coming back. Features that take longer every quarter. Engineers who flinch when you suggest deploying on a Friday. And usually, somewhere in the recent past, a failed quality initiative that everyone remembers with a slight wince.

The instinct in that situation is to reach for tools. Buy a static analysis platform, mandate 80% test coverage, set up a dashboard. I understand the appeal, because tools are easy to buy and easy to point at. But quality doesn’t fail because of missing tools. It fails because of how the organisation makes decisions, hundreds of times a day, when nobody senior is watching. If you want to fix quality, you have to fix that.

Here’s how I’d go about it.

Start by agreeing what quality actually means

Most quality efforts die at the definition stage because everyone is using the same word for different things. Engineers mean clean code. Product means no bugs at launch. The exec team means customers aren’t complaining.

I anchor on the customer first. If the customer feels it, it’s a quality problem. Availability, correctness, regressions. This matters because it turns quality from an engineering aesthetic into a business concern, and you will need the business on side later.

Second, quality is how safely and quickly you can change the system. This is the DORA view of the world, and it’s the most useful reframe I know. Tech debt isn’t ugly code. Tech debt is anything that makes change slower or scarier. A gorgeous codebase nobody dares touch is low quality by this definition, and that’s correct.

Craft matters too, but only in service of the first two. In a startup, over-engineering is also a quality failure. It just burns time instead of customers.

My favourite litmus test: would you deploy this on a Friday afternoon? The distance between your answer and “yes, obviously” is your quality debt, made concrete.

Kill the idea that quality is someone else’s job

The most corrosive belief in any engineering org is that quality belongs to QA, or the platform team, or that mythical future quarter when things calm down. Responsibility that lives somewhere else always decays.

The principle is simple: you build it, you own it, you run it. The engineer owns the correctness of what they write. The team owns how it behaves in production. Managers own the team’s bar. The tech leader owns the trend.

Making that real takes a few things. Every service and critical journey needs a named owner, because unowned code is where quality goes to die. Teams should carry the pager for their own systems, because engineers who feel production pain write different code. And crucially, you have to celebrate quality work with the same energy you celebrate launches. If deleting ten thousand lines of dead code gets silence and shipping a feature gets applause, you’ve told everyone what you actually value.

Accountability means the performance system, not a poster

Ownership without accountability is a slogan. Write quality expectations into the career ladder at every level. Engineers own what they ship and what they approve in review. Senior engineers are the immune system, accountable for raising risk early. Managers are accountable for their team’s quality trend exactly as they are for delivery.

Then use it. The day a promotion case cites someone raising the team’s testing standard, and the day a fast but sloppy engineer gets a candid development conversation, is the day the organisation believes you. Until then it’s theatre.

One thing I’d caution against: never use quality metrics to rank individuals. Metrics are for finding problems in the system. The moment a number becomes a weapon, people will game it, and you’ll be worse off than when you started.

Let tooling enforce the floor and AI raise the ceiling

Tooling has a role, it’s just not the starring one. Automate the non-negotiables so no human has to argue about them: CI gates, security scanning, review requirements, coverage that isn’t allowed to decrease on critical paths. Note that’s a ratchet, not a global percentage target. Mandated coverage percentages produce junk tests.

AI is genuinely changing the economics here, and it’s worth being specific about how. AI review as a first pass on every pull request raises the floor of the whole organisation without adding headcount. AI analysis of your codebase can show you where complexity, churn and incidents cluster, which turns tech debt prioritisation from opinion into evidence. And AI generated characterisation tests make it affordable to wrap scary legacy code in a safety net before you touch it, which changes the refactoring maths completely.

One warning though. AI amplifies whatever culture you already have. In a weak quality culture, AI assisted coding just ships defects faster. That’s why I’d roll out AI review before leaning on AI generation, and why culture comes before any of it.

Pay down debt continuously, and never stop the world

Whatever you do, don’t halt feature delivery to fix the code. Big rewrites and quality freezes fail so reliably it’s nearly a law of physics, and they torch the business’s trust in engineering.

Instead, build an honest debt register, prioritise by pain rather than purity, and fund the work structurally. Something like 15 to 20 percent of every team’s capacity, every sprint, agreed with product leadership as a permanent cost of doing business. Not a quarterly quality sprint that gets cancelled the first time a deadline looms. When the pressure comes, and it will, the manager’s job is to defend that allocation, and your job is to back them.

Prioritise debt that causes customer incidents first, then debt in high churn areas, because you pay that toll on every single change. Then report the paydown like you’d report delivery. The first time you can say “we invested three sprints in the billing module and its failure rate halved,” the budget starts defending itself.

Expect resistance, and treat it as three different problems

Every quality push meets detractors, and they need different responses.

The sceptic has seen initiatives come and go, and is usually right about the history. Don’t argue. Make one team visibly better in one quarter and let the sceptics talk to them. Better yet, recruit a respected sceptic into designing the approach. Involvement converts people far better than persuasion.

The cowboy ships fast and sees quality as friction. Make their real cost visible, including the rework everyone downstream absorbs, then point their speed at the hardest problem on the debt register and give them public credit for it. Speed aimed at quality is a gift. But if someone keeps treating the bar as optional after honest coaching, it becomes a performance issue, and people need to see that it does. One tolerated cowboy costs you a hundred converts.

The burned out aren’t resisting quality, they’re resisting disappointment. Rebuild trust with small kept promises. Fix something they’ve complained about for a year, quickly and visibly.

And the biggest detractor conversation is often with the business: “can’t we do quality later?” The answer is that you’re already paying for quality, just in incidents, rework and slowdown, which is the most expensive currency there is. That 15 to 20 percent isn’t a tax on delivery. It’s the interest payment that stops the debt compounding.

What success actually looks like

Measure a small set honestly. Change failure rate, incident trends, lead time, coverage on the paths that matter, and a short quarterly survey asking engineers whether they’re proud of what they ship and whether they have time to do it properly. That last one moves six months before anything else does.

But the real finish line isn’t a metric. It’s the day quality no longer needs a programme. Engineers raise concerns unprompted. Managers defend the debt budget without you in the room. Someone asks about a Friday deploy and gets a shrug and a yes.

That takes twelve to eighteen months of boringly consistent leadership behaviour, and there’s no shortcut I’ve found. But it’s worth it, because the framing most companies get wrong is thinking quality is the tax they pay on speed. In any company planning to exist in five years, quality is where the speed comes from.