Ward Cunningham’s Technical Debt: The Quadrant Model CTOs Can Actually Run

Ward Cunningham technical debt and the quadrant model

In 2024, I reviewed three portfolios where “tech debt” consumed 20 to 40 percent of sprint capacity, every sprint. Teams still missed reliability targets, and product still felt slow. The issue wasn’t effort. It was that nobody agreed on what debt meant, which debt mattered, and which debt was a conscious choice. Ward Cunningham gave us a metaphor that clears this up, and the quadrant model makes it usable in planning.

What Ward Cunningham meant by “technical debt”

Ward Cunningham coined the technical debt metaphor in the early 1990s while building financial software. His point wasn’t “bad code.” It was that shipping a simpler version now can be a smart trade, like taking a loan, as long as you understand the interest and you plan repayment. You borrow time to get feedback, then you pay it back by refactoring once you’ve proven what you learned is real. Martin Fowler later captured the same idea and pushed it into mainstream engineering management language in his essay on technical debt.

Here’s the definition I use with boards and exec teams.

Quotable definition: Technical debt is a deliberate or accidental design shortcut that increases the cost of future change, and charges “interest” every time you touch the area.

Debt has three parts you can actually measure.

• Principal: the one time cost to remove the shortcut.
• Interest: the ongoing cost you pay while it stays.
• Interest rate: how fast the interest grows as the system changes.

One CTO mistake I see all the time is treating debt like a moral failure. It’s not. Debt is a portfolio of decisions. Some were smart at the time. Some were sloppy. Some were forced by deadlines. The job is to classify them, price them, and manage them.

A quick timeline helps anchor the conversation.

• 1992 to 1993: Cunningham uses the metaphor while working on object oriented financial systems and patterns work.
• 2000s: the term spreads through agile and refactoring communities.
• 2009: Fowler formalizes the quadrant model and gives leaders a shared language.
• 2010s to now: the term gets abused to mean “anything I dislike,” which breaks prioritization.

Technical debt isn’t the same thing as defects, and it isn’t the same thing as legacy.

• A defect breaks expected behavior.
• Legacy is code that still runs the business.
• Debt is the extra cost of change caused by earlier choices.

If you want a clean mental model, use this framing statement.

Technical debt is a business liability that shows up as slower delivery, higher incident rates, and higher change risk.

The technical debt quadrant model, and what each quadrant means

Most CTOs I talk to struggle with one thing. They can list 50 debt items, but they can’t explain which ones are acceptable. The quadrant model fixes that by splitting debt along two axes.

• Deliberate vs inadvertent: did we choose it?
• Prudent vs reckless: did we understand the trade?

Martin Fowler’s write up of the technical debt quadrant is the best reference. I use a slightly more operational version in exec reviews.

Prudent and deliberate debt: the only quadrant that feels like a loan

This is the quadrant Cunningham meant. You borrow time to learn. You write it down. You set a payoff trigger.

Example.

A team ships a new onboarding flow in two weeks by:

• Storing state in a single Postgres table.
• Skipping eventing.
• Using a single feature flag.

They do it to validate a funnel change, and they set a payoff plan.

• If activation lifts by 5 percent for 30 days, they rebuild the state model.
• If it fails, they delete the code.

That’s debt used as a product experiment tool.

Reckless and deliberate debt: debt as a culture problem

This quadrant isn’t a trade. It’s a habit.

You see it when teams:

• Skip code review to hit a date.
• Disable flaky tests instead of fixing them.
• Merge “temporary” hacks with no owner.

The interest shows up fast.

• Lead time grows from 2 days to 10 days.
• Change failure rate climbs from 10 percent to 30 percent.
• On call pages double.

Those are DORA style signals, and Google’s DORA research ties them to delivery and stability outcomes. Use the DORA metrics reference as a shared language with leadership.

Prudent and inadvertent debt: debt created by learning

This is the most common quadrant in high growth systems.

You made a reasonable design choice. Then the world changed.

• Traffic goes from 50 RPS to 800 RPS.
• A single tenant product becomes multi tenant.
• A “simple” integration becomes a core revenue channel.

The fix isn’t blame. The fix is to treat architecture like a living asset. This is where a lightweight architecture practice pays off.

If you want a concrete tool, model the current and target state in our ArchiMate modeling guide. It forces you to name dependencies and ownership.

Reckless and inadvertent debt: debt created by missing feedback loops

This quadrant grows in the dark.

• No service ownership.
• No SLOs.
• No dependency map.
• No incident learning.

Then one day, a “small change” takes down checkout.

The fix is boring and powerful.

• Add SLOs for the top user journeys.
• Add error budgets.
• Add a real incident review practice.

Use our incident postmortem template to turn outages into a debt register with owners.

How to measure technical debt without turning it into a spreadsheet war

CTOs want a number. CFOs want a number. Engineers want the number to be fair.

You won’t get a single perfect metric, so use a small set that triangulates.

A practical debt scorecard for exec reviews

I use four signals, and I review them monthly.

• Delivery drag: lead time for change, and deploy frequency.
• Stability tax: change failure rate, and MTTR.
• Cost of change: story cycle time for “simple” work in core systems.
• Operational noise: pages per engineer per week, and ticket volume.

Track them in one place. Our Engineering Metrics Dashboard is built for this kind of review.

Now connect the signals to specific debt items.

Example.

• Checkout service lead time rose from 3 days to 9 days in two quarters.
• The team reports 25 percent of time goes to “figuring out the code.”
• Incidents tied to checkout rose from 2 per month to 7 per month.

That’s not “tech debt is bad.” That’s a priced liability.

A simple way to estimate principal and interest

You don’t need perfect estimates. You need consistent ones.

For each debt item, capture:

• Principal: engineer weeks to remove it.
• Interest: hours per week wasted, or incidents per month caused.
• Interest rate: is it rising, flat, or falling?

Then compute a rough payback.

• If principal is 6 engineer weeks.
• If interest is 12 engineer hours per week.
• Then payoff is about 20 to 24 weeks, depending on team size.

Is that precise? No. Is it good enough to rank items? Yes.

The catch: debt is often a dependency problem

A lot of “debt” is really coupling.

• A shared database blocks service ownership.
• A shared library blocks upgrades.
• A vendor integration blocks release cadence.

This is where portfolio visibility matters. I like to keep a dependency map and a risk register next to the debt register.

Our Command Center is the right place to run that as an operating rhythm, not a one off audit.

Why Ward Cunningham’s technical debt matters to enterprise CTOs

This isn’t a code quality debate. It’s strategy and risk.

1. It changes how you fund engineering work. If you treat debt as “engineering hygiene,” it loses every budget fight. If you treat it as interest on a liability, you can fund payoff like any other risk reduction.

2. It changes incident risk and business continuity. Reckless debt clusters in the same systems that carry revenue. Those systems also have the worst blast radius. Tie debt payoff to SLOs and incident history, not to taste.

3. It changes hiring and retention. Senior engineers leave when they spend 60 percent of time on glue work. They also leave when leadership calls every refactor “gold plating.” The quadrant model gives you a fair language for trade offs.

4. It changes vendor and platform decisions. Some debt is self inflicted by building what you should buy. Use a consistent decision tool like our Build vs Buy Matrix before you create a new internal platform that nobody can staff.

What CTOs can do: a quadrant driven operating system for debt

I’ve seen debt programs fail when they live as a backlog label. They work when they show up in planning, incentives, and architecture.

Immediate actions for the next 30 days

1. Define debt in one sentence. Use the definition above. Put it in your engineering handbook. Repeat it in planning.

2. Create a debt register with 20 items max. Start with the top 5 revenue systems. Limit the list so it stays real.

3. Tag each item with a quadrant. If the team can’t tag it, the item isn’t understood.

4. Add principal and interest estimates. Use engineer weeks and hours per week. Keep it rough.

5. Pick two payoff epics and finish them. Don’t start ten. Finish two and show the before and after metrics.

Policy framework: rules that prevent reckless debt

1. Definition of done: Require tests, review, and observability hooks for production paths. Make exceptions rare and written.

2. Time boxed exceptions: If you take deliberate debt, set an expiry date. Put it on a calendar, not in a backlog.

3. Error budget policy: If a service burns its budget, feature work pauses. Google’s SRE book explains the model well in the chapter on error budgets.

4. Incident to debt pipeline: Every sev 1 creates at least one debt item with an owner. Use our guide to blameless incident postmortems as the standard.

Architecture principles: how to keep debt payable

1. Own the seams: Assign owners to APIs, schemas, and queues. Unowned seams create reckless inadvertent debt.

2. Prefer replaceable components: If a component can’t be swapped in a quarter, it needs stronger contracts and tests.

3. Limit shared state: Shared databases and shared runtime clusters create hidden interest. Split them when teams hit 150 engineers or 20 services.

4. Make cost visible: Tie debt items to cloud spend when you can. A slow query that adds $18,000 per month in read replicas gets attention fast. Use our Cloud Cost Estimator to price the impact.

A link worthy checklist: the Debt Payoff Trigger List

Use this list to decide when prudent deliberate debt must be paid.

• Revenue trigger: the feature crosses $100,000 MRR, and the shortcut sits in the path.
• Scale trigger: traffic grows 5x from the original design assumption.
• Reliability trigger: the service causes 2 sev 1 incidents in 90 days.
• Team trigger: more than 3 teams change the area each quarter.
• Compliance trigger: the shortcut touches PII, payments, or audit logs.

If a debt item hits any trigger, it moves from “acceptable” to “scheduled.”

Bigger picture: debt is a leadership signal, not just a code smell

Cunningham’s metaphor keeps working because it connects engineering work to finance language. That matters more now, since capital got more expensive after 2022 and boards ask harder questions about burn and risk. Debt payoff competes with growth bets, and you need a shared model to make the trade.

I also think the quadrant model is a culture test. Prudent deliberate debt means your teams can make bets and clean up after themselves. Reckless debt means your system rewards heroics and punishes honesty.

So here’s the question I ask CTO peers: if you froze feature work for two weeks, would your teams know exactly which debt to pay first, and why? If the answer is no, your debt problem isn’t in the code. It’s in the operating system you run as a leadership team.

Sources

1. Martin Fowler, Technical Debt
2. Martin Fowler, Technical Debt Quadrant
3. Google Cloud, DORA and DevOps Research
4. Site Reliability Engineering book, Embracing Risk and error budgets