The meeting had been going for ninety minutes when the finance director slid an index card across the table. Three words: start with what?
The team had worked through the Organisational Debt Diagnostic, rating each of the eight types. Cultural Debt2: a founder-led business where decisions still ran through one person, seven years in. Operational Debt3: three processes undocumented, two of them held entirely by someone who'd been there since the beginning and had never written anything down. Data Debt8: reporting built on spreadsheets that nobody fully trusted but everyone used. Capability Debt4: a finance manager who was the only person in the building who understood the payroll system. Each debt had a name and each argument for addressing it was sound.
The list reached fourteen items. Someone suggested prioritising by impact. Someone else suggested grouping by type. By the end, the team had agreed to look at all of it over the next quarter, which felt like a decision, but wasn't.
The question that rarely gets asked in those meetings is: for each debt on that list, did anyone in the organisation decide to own it?
More often than not, the answer is no. The founder-led decision-making persisted because the founder was faster than a committee, and speed mattered more than structure in year two. The undocumented processes stayed undocumented because the people who held the knowledge were also the people with no time to write it down. The spreadsheets survived because a proper reporting set-up needed a budget conversation that never made the agenda. Each debt began as a reasonable trade-off that nobody went back to check.
That distinction changes how the list looks. A debt that's owned, with a reason, a limit and a date for review, is a business decision; the same debt carried by omission is an unexamined risk. The damage in each of the debts this series has described came from nobody owning the trade-off.
This is the closing piece in a series on organisational debt1. It sets out how to tell a debt someone chose from one that accumulated unnoticed, why it helps to think of the difference as insurance, and a practical way to decide which risks to own on purpose.
Chosen Debt and Default Debt
The difference between healthy debt and dangerous debt is whether someone took it on for a reason and is still watching it.
Martin Fowler's "Technical Debt Quadrant"10, published in 2009, separates debt along two lines: deliberate or inadvertent, and prudent or reckless. The quadrant that matters here is deliberate and prudent: a known shortcut, taken for a reason, with the understanding that it will need paying back.
Lean Enterprise11, by Jez Humble, Joanne Molesky and Barry O'Reilly, turns this into practice. When exploring new ideas, teams will "deliberately and prudently accumulate technical debt in order to run experiments", shipping fast to test an assumption. The debt is the price of that speed, and the condition for paying it is set at the same time: once the experiment is validated, the debt gets paid down aggressively. The decision and the exit are joined from the start.
Rian van der Merwe puts it more bluntly in Making It Right12. Technical debt "isn't necessarily bad at the moment it occurs"; the problem is age: "new debt is OK, old debt is bad". What starts as a considered call hardens in the background, still shaping the system and no longer attached to anyone who remembers why.
That pattern holds across every type of debt in this series. Shipping before the data model is right can be a sound call; it becomes an inherited problem when the reason is forgotten while the consequence remains. Hiring before a role is documented, or launching before a compliance review is finished, can each be the right move at the right moment. Each becomes a liability by omission.
Paul Fjelrad, writing about what he calls "Architectural Archaeology"13 for Watchmen Consulting, describes pragmatic decisions made under pressure, after which "the team moves on and the reason becomes separated from the change", until systems end up "serving decisions the organisation no longer consciously holds". He's writing about technology estates, but it's as useful a description of default debt as any.
The Technical Debt6 piece in this series made the same point: "zero debt isn't the goal", and what matters is "the proportion of debt that's known, tracked, and chosen versus debt that's accumulated because nobody was watching". The ratio of examined to unexamined debt says more about an organisation's health than the total.
The test is simple to state and harder to pass. For any debt on the list, can someone name who decided to own it, why, and when it will be looked at again? If they can, it's a decision the business owns. If nobody can, it's default debt, whatever the original intent.
Once debt is seen as a set of decisions rather than a catalogue of failures, the question changes: what is the business getting for carrying this, and what would it cost to stop?
Organisational Debt as Uninsured Risk
Carrying an unexamined debt is self-insuring by default. If the risk lands, the business pays the full cost at the worst moment: the key person leaves during a busy quarter; the audit finds the gap the team knew about but hadn't addressed; the data turns out to be wrong, and the decision made on it can't be unmade. The exposure was always there. The only difference is whether anyone was managing it or hoping it wouldn't happen.
Addressing a debt is paying a premium: a known cost now to reduce a larger, less certain cost later. Regulatory Debt7 came closest to making this literal. A periodic compliance review is small and predictable; a failed audit, a remediation programme or an enforcement action is neither. The premium is the review; the unfavourable audit is what it guards against.
Any debt offers three deliberate positions.
The first is to pay it down. This is the most expensive premium in the short term, and the right one for the debts that matter most: those where the exposure is large, the probability isn't negligible, and the cost of dealing with it now is smaller than the cost of dealing with it later under pressure.
The second is to cap it and watch it. Instead of removing the debt, the organisation agrees in advance the limit at which it gets addressed. Henrik Kniberg's "debt ceiling", cited in Making It Right, works this way: the threshold is set before it's needed, so the decision doesn't have to be made at the moment it's urgent. The Site Reliability Workbook14 describes a more formal version in Google's error budgets, where product, development and operations agree in advance how much unreliability is acceptable and what happens when that budget runs out.
For an SME, the principle holds without the engineering: a pre-agreed limit turns an open-ended risk into a bounded one. The limit might be an event (the one person who understands payroll hands in their notice), a threshold (more than a set number of manual fixes a month), or a date. What matters is that it exists before it's needed. This is the cheapest form of cover, and the most under-used.
The third is to own it knowingly: accept the debt for a stated reason, with a date to look at it again. This is legitimate, often right for a lower-priority debt, and it only works if it's written down. A spoken agreement to revisit something is the first step towards carrying it by default.
The fourth position, the one this series has described across eight debt types, is carrying it by default: the same exposure as owning it knowingly, with no awareness, no trigger and nobody accountable. Most of the fourteen items on that team's list sat here, because the original decisions were implicit, and implicit decisions don't age well.
The metaphor has limits. Insurance transfers risk to a third party; almost no organisational debt can be transferred, only reduced, capped or accepted. The premium doesn't buy a payout; it buys a smaller problem.
Because a business with finite time and budget can't pay down or cap everything, trying to address all of it ends the same way as the meeting that agreed to look at all of it. The question is which debts get cover, and how to decide that in a way that holds up when the next urgent request arrives.
Competing Constraints: The Mechanism for Choosing
Software delivery has wrestled with this problem for a long time. Every system has to balance non-functional requirements, the quality attributes and constraints that don't sit comfortably together: performance against maintainability, security against usability, cost against deadline, accessibility against time to market. In Software Requirements15, Karl Wiegers and Joy Beatty are direct about it: "certain attribute combinations have inescapable trade-offs", so stakeholders "must decide which attributes are more important than others, and they must respect those priorities when they make decisions".
Their method for settling it is a single question, asked of each pair: "If I could have only one of these attributes, which would I take?" They also warn that "if you don't specify quality goals, no one should be surprised if the product doesn't exhibit the expected characteristics". That's default debt, described in requirements language.
The idea transfers well beyond code. Mantage's delivery practice uses a "competing constraints" session for this. The constraints stakeholders bring are documented, then as many of those stakeholders as possible rank them against each other in the same room, and the ranking is revisited regularly, because priorities change. Two things follow. The delivery team can make trade-off decisions without going back to the client each time, which removes a source of delay and escalation. And the ranking feeds into what counts as "done": a live priority order shapes acceptance criteria more reliably than requirements written in the abstract.
Consider a twenty-person digital agency building a new website for a client. At the start of the project, the client's stakeholders ranked accessibility compliance above the launch date, and the launch date above the full feature list. Halfway through, the client's product owner asks to bring the launch forward by two weeks, which would mean skipping accessibility testing. The delivery team can push back without escalating, because the answer comes from the client's own priorities: accessibility debt is a risk the client has already decided it won't accept. The same ranking lets the team accept a different debt knowingly. To protect the original date, a lower-priority feature, such as saved searches, ships in a simpler form, with a note of why and a date to revisit it. One ranking settled both decisions in advance, and nobody had to argue either from scratch.
At leadership level, the exercise covers broader ground. Most founders are already handling pairings: speed of delivery against long-term growth, regulatory strictness against margin, customer responsiveness against process consistency, cost control against capability building. Every pairing left unranked produces a characteristic debt. Favour speed over structure for long enough and Operational and Technical Debt build up together. Let margin edge out compliance and Regulatory Debt accumulates unexamined. Put responsiveness before documentation and knowledge ends up in a few people's heads, which is Capability Debt. Prioritise today's delivery over tomorrow's options and Innovation Debt9 follows. Each is the predictable result of two legitimate priorities being settled by default.
An explicit ranking is where a business's stated values stop being decorative and start making decisions. Most organisations have a values statement somewhere; fewer have tested whether those values produce consistent choices under pressure. A ranking converts the abstract ("we care about quality") into something a project lead can act on at three o'clock on a Thursday, when a client is pressing for a shortcut. That's a more demanding test of values than a poster, and a more useful one.
The ranking only holds if the right people agreed to it. Google's error budgets work because product, development and operations all agree the threshold before it's tested. A ranking set by one leader alone gets overridden the first time it's inconvenient. A business that finds this exercise hard may be meeting its own Strategy Debt5: without an agreed sense of what the business is optimising for, there's nothing to rank constraints against. That's a useful finding, because it points to the conversation that needs to happen first, and reaching it through this exercise is better than stumbling across it later under pressure.
With a ranking in place, any debt the business owns is there because it decided something else mattered more, and it can say what.
Choosing Which Debts to Own: Where to Start
Moving from inherited debt to decided debt takes four things any leadership team can do.
Tool 1: Take the Inventory, Then Mark Each Debt Chosen or Default
Start with the eight types: Cultural, Operational, Capability, Strategy, Technical, Regulatory, Data and Innovation. The Organisational Debt Diagnostic and the primer's1 diagnostic questions each give a ready-made prompt for every type. Against every debt you find, apply one test: did anyone decide to own this, and can they say why? Write the answer next to each item.
Most businesses find that almost everything they're carrying is unexamined: it accumulated rather than being accepted. That finding is the point of the exercise. You can't own a risk you haven't named, and naming it is the first step in taking responsibility for it.
Tool 2: Run a Competing Constraints Session at Leadership Level
Name the five to eight things that pull against each other in your business: speed, margin, compliance, growth, customer responsiveness, consistency. Then rank them pairwise using Wiegers and Beatty's question: if we could only have one of these two, which would we take? Work through every pair until there's a clear order. Include everyone whose decisions the ranking will govern; a ranking built without the people who live by it won't survive contact with a real decision.
Write down the order and the reasoning behind the pairs that were hardest to call. That reasoning is what lets the rest of the business make consistent trade-offs without escalating each one. Trade-offs settled case by case, with nothing to refer to, are where most default debt comes from.
Tool 3: Decide a Position for Each Debt, and Write It Down
For each debt, choose one of the three positions (pay it down, cap it and watch it, or own it knowingly) and use the ranking to justify the choice. If you cap and watch, name the limit and the trigger. If you own it knowingly, write down the reason and the review date. John Cutler's strategy prompt16 is a useful template for the reason: "Until we [change condition], additional investment in [capability] is unlikely to materially improve [outcome]." Written that way, the decision carries its own condition for being revisited.
Give each decision an owner. An unwritten decision turns back into default debt as soon as the people who made it move on.
Tool 4: Review the Choices on a Rhythm
Set a fixed schedule for revisiting both the ranking and the positions. Quarterly suits most SMEs; any longer and the business tends to outgrow its choices before it reviews them. Revisit sooner if a trigger fires. Two questions are enough: has anything hit its limit, and does the ranking still reflect what the business is trying to do?
Mantage's delivery practice is clear on this: constraints change, and a ranking that isn't revisited becomes a record of what the business used to believe. A position that's never reviewed is already on its way back to being inherited.
After these four steps, every debt the business owns has a name, a reason and a date against it, even before any of it has been paid down.
The Realities of Choosing
The process is useful, and it's also uncomfortable. Four difficulties come with it.
Writing it down is uncomfortable. An inherited debt feels like an oversight; a decided debt is a documented judgement that a leader will be asked about if it goes wrong. That discomfort is why most debt stays unchosen. It's also why choosing works: accountability is what makes the decision get revisited, instead of drifting until something breaks.
The premium is visible; the protection isn't. Money spent paying down or monitoring a debt produces no return anyone can point to when it works, because the thing it prevented doesn't happen. The series has met this before: Technical Debt described a quarter of debt reduction looking, from outside engineering, like "a quarter with no new features". That spend will need defending every budget round, and it helps to have the position written down and owned before the conversation starts.
Some risks aren't yours to accept. A leadership team can decide to accept its own Innovation Debt. It can't decide, on behalf of customers, employees or regulators, to accept risks that fall on them: legal compliance, safety, data protection, and Cultural Debt serious enough to harm people. For those, owning it knowingly isn't an available position, whatever the ranking says.
The ranking will be contested, and that's useful. If leaders can't agree the order, that disagreement was already there, being settled piecemeal and out of sight in every trade-off made below them. Bringing it into the open is often the most valuable output of the session. A business that can't agree its ranking is looking at its Strategy Debt.
These difficulties are the price of turning inherited risks into decisions someone owns, and it's a smaller price than carrying the same risks unexamined.
Organisational Debt as a Leadership Discipline
Each of the eight earlier pieces described one type of debt and the levers for paying it down. The idea running beneath all of them is that each type is what a particular unranked trade-off looks like once it has compounded. Innovation Debt, the previous piece, ended on the point that not investing can be the right call "if it's a decision". The primer's last line said the leaders who get ahead of debt "know what they're carrying and make conscious choices about when to pay it down".
The primer's advice on prioritisation, to "choose two or three that matter most for your next twelve months, and sequence the rest", answers which debt to fix first. This piece supplies what sits underneath that sequence: a ranking that says what each debt was traded against, and a position for each one that says what to leave in place and why.
Mantage's strategy delivery work builds the constraints ranking into the strategy itself, so trade-offs have something to be judged against instead of being settled on instinct each time. Operations review starts with the chosen-or-default inventory and puts limits and triggers in place for the debts the business decides to own. Mentoring supports leaders through the harder part: putting their name to a decision to own a risk, and defending the premium when nothing visibly goes wrong.
Every business carries debt, and every debt began as a trade-off that made sense at the time. The businesses that stay healthy can say, for each debt they own, who chose it, why, and when they'll look at it again. In the rest, the same risks sit on the books with nobody's name against them. Closing that gap takes one decision per debt, written down and owned.
Where to go from here
I have produced a free-to-use diagnostic tool and tracker to help you take the inventory. Rate each of the eight types, then ask of every debt on the list: chosen, or default?
Referenced Articles
- Organisational Debt - Primer
- Cultural Debt
- Operational Debt
- Capability Debt
- Strategy Debt
- Technical Debt
- Regulatory Debt
- Data Debt
- Innovation Debt
- Martin Fowler, "Technical Debt Quadrant" (martinfowler.com, October 2009)
- Jez Humble, Joanne Molesky and Barry O'Reilly, Lean Enterprise: How High Performance Organizations Innovate at Scale (O'Reilly Media, 2015)
- Rian van der Merwe, Making It Right: Product Management for a Startup World (Smashing Magazine, 2014)
- Paul Fjelrad, "Architectural Archaeology" (Watchmen Consulting, September 2026)
- Betsy Beyer et al. (eds.), The Site Reliability Workbook: Practical Ways to Implement SRE (O'Reilly Media, 2018)
- Karl Wiegers and Joy Beatty, Software Requirements, 3rd edition (Microsoft Press, 2013)
- John Cutler, "Strategy Prompts: Investment Until Condition"