Quick Navigation
- Start here — the technical debt trap
- The wrong model: debt separated from delivery
- The feature refactoring principle
- Practice 1 — Refactor the area you touch
- Practice 2 — Expand the change boundary slightly
- Practice 3 — Capture improvements explicitly
- Why this model works
- Institutionalising it in 60 days
- Putting it all together
- Cheat sheet
Before we start — the one thing to hold onto
Every engineering organisation recognises technical debt. Teams say: we should refactor this, this module needs redesign, we need to clean up the architecture.
Then deadlines arrive. Product features take priority. Refactoring is postponed. Months later, systems are harder to change, velocity slows, incident risk rises, and engineers grow frustrated. Eventually leadership proposes a large modernisation initiative — expensive, disruptive, and in many cases unsuccessful.
The problem is not that organisations ignore technical debt. The problem is how they try to fix it.
Every feature should leave the system better than it was before.
Keep it in mind. This module is about the funding mechanism — where the hours for structural work actually come from. The discipline of what kind of structural work to do is covered separately in Execution Stability & Structured Refactoring.
1. The technical debt trap
The trap is not a lack of awareness. Every organisation in this trap can name its worst modules. The trap is a sequencing problem that never resolves in debt's favour.
The sequence runs like this. Debt is acknowledged. Debt is scheduled — for later. Later never arrives, because there is always a feature with a name, an owner and a date. Debt accumulates. Systems become harder to change and each new feature costs more than the last. Eventually the cost is high enough that leadership authorises a large modernisation initiative — which is expensive, disrupts delivery, and often fails.
Note what happened. The organisation waited until the only remaining option was the most expensive and least reliable one.
flowchart TD
A["Debt acknowledged\n'We should refactor this'"] --> B["Debt scheduled for later\nDeadlines arrive"]
B --> C["Debt accumulates\nSystems harder to change"]
C --> D["Velocity slows\nIncident risk rises"]
D --> E["Large modernisation initiative\nExpensive · Disruptive · Often fails"]
E --> A
Try it yourself — The three questions
Answer these before reading on.
| Question | Your answer |
|---|---|
| How much technical debt exists in your backlog right now? | |
| How often do teams fix debt while implementing features? | |
| Do architecture reviews reward structural improvement? |
If feature delivery always increases complexity, technical debt will eventually dominate development. That is not a risk — it is arithmetic.
2. The wrong model — debt separated from delivery
Many organisations treat technical debt as a separate activity, with two backlogs:
- Feature development → the product backlog
- Technical debt → the refactoring backlog
This separation looks like organisation. It is actually a structural guarantee of failure, because the two backlogs do not compete on equal terms.
Product features always win. They have a business sponsor, a customer-visible outcome, and a date. Debt items have an engineer's conviction. In any prioritisation meeting where those two compete, the result is decided before the meeting begins.
So debt accumulates faster than it is removed. Eventually the system reaches a point where small changes become expensive. At that stage the organisation is forced into major rewrites, migration programmes or platform rebuilds — all because technical debt was isolated instead of integrated into development.
The problem is not that the refactoring backlog is under-prioritised. It is that a separate backlog was the wrong shape for the work in the first place.
3. The feature refactoring principle
The sustainable approach is different: address technical debt while building new features.
Every feature touches the system. Every change is an opportunity to improve architecture. Instead of separating the two, combine them — feature development becomes a vehicle for continuous architectural improvement.
Whenever a team modifies a component, they should ask one question:
Can we leave this part of the system better than we found it?
This idea is sometimes called the Boy Scout Rule in software engineering. At an individual level it is a good habit. At organisational scale, a habit is not enough — it needs structure, or it becomes a thing conscientious engineers do on their own time and nobody else does at all.
Three practices give it that structure.
flowchart TD
F["Feature work\ntouches the system every day"] --> P1["1. Refactor the area you touch\nImprove the module\nyou are already changing"]
F --> P2["2. Expand the change boundary\nslightly\nFix what the feature revealed"]
F --> P3["3. Capture improvements explicitly\nPR descriptions · Architecture notes · ADRs"]
P1 --> R["Architecture improves\nas a by-product of delivery"]
P2 --> R
P3 --> R
4. Practice 1 — Refactor the area you touch
When implementing a feature: improve the module being modified, simplify complexity in that component, remove obsolete code paths, introduce better patterns.
The constraint matters as much as the instruction. Do not attempt to fix the entire system. Focus only on the area already being changed.
That constraint is what keeps improvements incremental and safe. It bounds the blast radius to code the team is already testing, already reviewing, and already reasoning about. It also bounds the estimate — which is what makes the practice survivable in a delivery organisation. A refactor of unbounded scope attached to a dated feature will be cut. A refactor bounded to the feature's own area usually is not.
5. Practice 2 — Expand the change boundary slightly
Feature delivery reveals structural weakness that nothing else does. Building the feature is the diagnostic. Teams discover tightly coupled modules, missing service boundaries, duplicated logic, and fragile integrations — not from a code audit, but from trying to change something.
Teams should be encouraged to extend the change slightly beyond the immediate feature to fix those structural problems.
The word doing the work is slightly. Practice 1 bounds you to the area you touch; practice 2 permits a deliberate step past that boundary when the feature has exposed a specific weakness. It does not permit reopening the architecture. Small architectural corrections compound over time — that compounding is the entire return, and it only happens if the steps stay small enough that they keep being taken.
6. Practice 3 — Capture improvements explicitly
Architecture improvements should not be invisible.
When a team improves structure, document it through pull request descriptions, architecture notes, and Architectural Decision Records (ADRs). This turns improvements into organisational knowledge rather than isolated refactoring that one team remembers and nobody else benefits from.
There is a second reason this practice is not optional. Invisible work cannot be valued, and work that cannot be valued cannot be defended when the schedule tightens. If structural improvement leaves no trace, then from the outside the feature simply took longer — and the obvious efficiency is to stop doing the part nobody can see.
Making the improvement visible converts it from a cost that looks like slippage into a deliverable that looks like progress.
Try it yourself — The feature audit
Take the last three features your team shipped.
| Feature | Did it simplify or increase complexity? | Was any structural improvement made? | Was that improvement recorded anywhere? |
|---|---|---|---|
If the third column is often "yes" but the fourth is always "no", you do not have a prioritisation problem. You have a visibility problem, and practice 3 is where to start.
7. Why this model works
Three reasons, and the first is the one that matters most.
It aligns with product incentives. Feature development always receives priority — that is not a flaw to be corrected, it is a fact to be used. By embedding debt reduction within feature work, architecture improvement becomes part of delivery rather than competition with it. The work stops losing prioritisation arguments because it stops entering them.
It prevents massive refactoring projects. Instead of periodic big cleanup initiatives, the system evolves continuously. That avoids the risky, large-scale modernisation programmes that the debt trap eventually forces.
It keeps architecture evolution continuous. Architecture is not static. It must evolve alongside product capabilities, and incremental improvement is what keeps the system adaptable.
What it looks like concretely
Imagine a team implementing a new order management feature.
Traditional approach. The team adds the feature and leaves existing complexity untouched. Result: the feature works, and the system becomes more complex.
Feature-driven debt reduction. The team adds the feature, extracts a shared service, removes duplicate logic, and clarifies module boundaries. Result: the feature works, and the architecture improves.
Delivery and improvement happen simultaneously. Same feature, same sprint, opposite direction of travel for the system underneath.
8. Institutionalising it in 60 days
Introducing this practice requires cultural alignment more than technical change. Three phases.
Phase 1 — Policy alignment (weeks 1–2). Establish a simple rule and communicate it across engineering:
Any feature touching complex or fragile code should include structural improvement.
Success metric: refactoring becomes an expected part of feature delivery, not an exception someone has to justify.
Phase 2 — Architecture visibility (weeks 3–6). Encourage teams to document improvements — ADRs for architectural changes, clear commit descriptions, architecture review for larger improvements. Success metric: architecture evolution becomes visible and traceable.
Phase 3 — Governance integration (weeks 7–8). Align architecture review with feature delivery. Review should ask two questions about every feature: Did this feature simplify or increase complexity? Were structural improvements identified? Success metric: architecture quality becomes part of delivery evaluation.
Those two review questions are the whole governance change. They are cheap to add and they redirect what teams optimise for, because people build toward the question they know they will be asked.
Over 3–6 months, extend the integration: technical debt reduction becomes part of architecture reviews, engineering performance metrics, and design discussions. Over time, feature delivery becomes the engine of architecture evolution.
If your governance is moving toward automated enforcement, the same two questions can be backed by continuously evaluated checks rather than asked in a meeting — see Fitness Functions Instead of Review Boards.
Evidence from practice
An e-commerce company I worked with had a checkout system that had been modified by twelve different engineers over three years. Each feature added code. Nobody removed any. It was a textbook case of architectural entropy — it worked, but every new feature required touching five unrelated components, and the regression test suite took a full day to run.
We introduced the Structured Refactoring Model, but with a twist: every feature ticket had a "structural improvement" requirement attached. Before a team could add a new payment method, they had to extract the payment processing logic into a bounded context. Each feature delivery automatically improved the architecture. Within six months, the checkout system had gone from a monolith of intertwined logic to three clear bounded contexts. Regression testing dropped from a full day to two hours. Feature velocity increased by 30%.
The mechanism worth noticing is the ticket. The requirement was attached to the unit of work the organisation already tracked and already funded — not to a parallel backlog asking for its own budget.
Putting it all together
flowchart TD
ROADMAP["Product roadmap\nFunded · Dated · Sponsored"] --> TICKET["Feature ticket\nwith a structural improvement requirement"]
TICKET --> W1["Refactor the area you touch"]
TICKET --> W2["Expand the boundary slightly"]
TICKET --> W3["Capture the improvement\nADR · PR · architecture note"]
W1 --> SHIP["Feature ships"]
W2 --> SHIP
W3 --> SHIP
SHIP --> REVIEW["Review asks:\nDid this simplify or complicate?\nWere improvements identified?"]
REVIEW --> ROADMAP
Technical debt is not removed through occasional cleanup projects. It is removed through continuous architectural improvement. Feature delivery touches the system every day — that is where architecture evolves.
Organisations that wait for dedicated refactoring initiatives accumulate debt. Organisations that improve structure during feature work evolve continuously.
Cheat Sheet — All the key terms
| Term | What it means | Failure it prevents |
|---|---|---|
| The separate-backlog trap | Debt tracked apart from features, competing for the same capacity | Product features winning every prioritisation, permanently |
| Feature refactoring principle | Leave the part of the system you touched better than you found it | Every feature increasing net complexity |
| Refactor the area you touch | Improve only the module already being modified | Unbounded refactors that get cut under deadline |
| Expand the boundary slightly | A deliberate small step past the feature to fix a revealed weakness | Structural weaknesses observed and then ignored |
| Capture explicitly | ADRs, PR descriptions, architecture notes | Improvement that is invisible, so it looks like slippage |
| The policy rule | Any feature touching complex or fragile code includes structural improvement | Improvement depending on individual conscientiousness |
| The two review questions | Did this simplify or complicate? Were improvements identified? | Architecture quality staying outside delivery evaluation |
| Forced modernisation | The rewrite the debt trap eventually makes unavoidable | The most expensive option becoming the only option |
How to know if this landed
You will know this landed when a feature ticket arrives with a structural improvement attached and nobody treats it as scope creep. Teams can state the boundary rule in their own words — improve what you touch, expand slightly, record it — and can explain why the "slightly" is load-bearing.
The clearest tell is at the leadership level. When someone proposes a large modernisation initiative and the first question is "what would this cost if we routed it through the next four quarters of roadmap instead?", the model has taken hold. And when a review meeting asks whether a shipped feature simplified or complicated the system — and the team has an answer ready — architecture quality has become part of delivery rather than a separate initiative.
Where this comes from
This module develops the argument in Solving Technical Debt Through Feature Development: Turning Product Delivery into Architecture Improvement, and runs alongside the Delivery Enablement & Quality Workshop session, where the technical debt management process is built into your own SDLC and review practice.
Book a Workshop
Ready to turn feature delivery into continuous architecture improvement?
or
1-day workshop includes an audit of how debt accumulates in your systems, a feature-driven debt reduction policy for your teams, a visibility mechanism for structural improvements, and the governance questions that make architecture quality part of delivery evaluation.