How do you, and other companies, handle tech debt?
I was asked the question a while ago, How do I handle tech debt? and I am not sure I ever put it down in a form that makes sense; so this is an attempt at trying to convey several tools I use. ## Pay back early
The initial thinking on handling tech debt is not my idea, but stolen from Steve McConnell’s wonderful Code Complete. Steve shows in his book that if you can tackle tech debt earlier in the lifecycle of a project, the cost of tech debt is a lot less. Basically, the quicker you get back to repaying that debt, the cheaper it will be.
One aspect to keep in mind is that while the early part of a project may refer to greenfields/new projects, it is not limited to that idea. The early part could also mean epic-level-sized pieces of work that are started on an existing project, thus the "catch it early and it is cheaper" principle applies to existing teams just as much as it does to teams starting a new project.
Organisation
When I think of what to do specifically to handle tech debt, the first—and only—solution that won’t fit easily into an existing team is team organisation. I’ve seen this at Equal Experts, and previously when I worked at both AWS and Microsoft.
The simple answer is: teams above 10 people fail. Why is 10 the magic number? There are two key reasons:
Psychology of collaboration – Dunbar’s number suggests 15 is the upper limit for meaningful close relationships. However, since teams need to foster relationships across an organisation—not just within their own team—the optimal size is capped at ~10.
Cognitive load – As systems grow increasingly complex, holding all necessary information in one’s mind becomes harder. Keeping teams small (~10 people) naturally limits the volume and complexity of work they can handle, resulting in many focused, self-contained teams.
When I say team, I mean the entire team: POs, QAs, BAs, and any other two-letter-acronym roles. The whole unit should stay at or below 10—so you might have just 4 engineers per team.
Cross-skilled teams
There’s value in teams of 8–10 people who collectively hold most of the skills needed to deliver end-to-end results. Specialised teams—like dedicated front-end or back-end groups—should be rare. Most teams should own features from start to finish, fostering collaboration and shared accountability.
This approach forces teams to:
- Work together toward deadlines and deliverables
- Push back on new work if their existing debt risks overwhelming them
- Become experts in their technology stack (reducing generalist trade-offs and lowering tech debt over time)
DevOps
I always encourage clients to adopt the DevOps mindset. The cross-skilled, end-to-end ownership model hints at this, but one of DevOps’ earliest pillars—"You build it, you run it"—is critical.
This philosophy means a team owns a feature’s full lifecycle: writing, deploying, monitoring, and supporting it. At first glance, this might seem impossible—how can a small team handle everything? But more on that later.
DevOps’ impact on tech debt: While tech debt rarely causes outages, recovery time often worsens due to it. A major outage’s fallout includes post-incident reviews, client impact assessments, and root-cause analysis. Nothing motivates a product owner or team to reduce debt faster than the risk of being woken at 2 AM for incidents—and spending hours fixing them.
Happy to share a client video on this very topic from my latest project.
Reign in tech
In large organisations, limiting technology choices reduces tech debt. Outdated or obscure systems create more debt than stable, well-supported tools.
Avoid bleeding-edge tech
Bleeding-edge solutions build debt faster and hurt more when maintenance becomes necessary.
Horizontal scaling teams
The cost of starting and frustration with monolithic systems can deter investment—another debt risk. A solution? Build horizontally focused teams that own single features or platforms other teams rely on.
Examples:
- IDPs (Identity Providers)
- Teams handling web routing, bot detection, caching, etc.
These teams set standards (e.g., "We support React ESIs for caching"), letting business teams adopt them for speed/support. If they choose alternatives, they must justify trade-offs (e.g., lost speed).
Equal Experts’ Digital Platforms playbook covers this well.
Trickle-down updates
Horizontally scaled teams naturally force dependencies to update. For example, when the deployment-pipeline runners team upgraded, we had to migrate—cleaning old systems in the process. The short-term pain led to a more robust setup.
Bar raisers
At AWS, bar raisers were a standout tool. Unlike gatekeepers, they provided guidance without blocking progress. For high-risk deployments, you’d submit a form outlining risks, tests, and recovery plans. Bar raisers reviewed it, offering feedback—not vetoes.
Why it worked:
- No micromanagement
- Encouraged knowledge sharing
- Prevented teams from repeating past mistakes
They operated on set schedules, preventing overload.
Tech debt is normal work
The first easy fix? Treat tech debt like regular work—log it in your backlog. Neglecting it drags down average ticket times and frustrates teams. Product owners prioritise better when they see its impact.
Teams practicing "you build it, you run it" naturally face ebbs and flows (e.g., quiet periods during holidays). Quiet time? Perfect for debt reduction.
Finally: you can’t fix what you can’t see. Document debt explicitly—even if it’s worse than expected—and act on it.
Tech debt sprints
The last idea comes from Microsoft: add a tech-debt sprint at the end of every feature. Ship MVPs fast, gather feedback, and pile up debt—then fix it. Teams know it’ll be addressed, boosting morale.
I spoke about this at Agile Africa if you’re curious.