Bias, Metrics and Technical Debt

In a discussion on technical debt, the point often made by engineering is "if we do not pay attention to the debt right now, in the future, we will not be able to effectively engineer as the debt will be too great".

This is true, but it is often a hard point to communicate to someone outside of engineering in a way they can relate to.

This article considers why the risk posed by technical debt is hard to communicate and what you can do to make "technical debt" more easily relatable.

What is technical debt?

Technical debt is the accumulated cost of past technical decisions.

The debt is the extra work your system forces you to do beyond the useful work required for a change.

Technical debt does not arise because of bad decisions or poor engineering.

Technical debt arises because systems are engineered, requiring decisions to be made. The consequences of those decisions remain in the system and are felt during all future work.

Technical debt is real

Engineering decisions have an impact on a product as it continues to be used. If some of these decisions are not revisited in the light of changes in business fortune, a company's product can suffer.

Knight Capital company failure

In 2012, a US automated stock trader, Knight Capital, erroneously created millions of trades involving 400 million shares. The total financial exposure was over $6 billion.

The failure arose when a Knight server ran an outdated and long dormant function that had previously been used for obsolete trading strategies. When the market opened, this dormant code was mistakenly activated and began generating millions of trades.

The decision to leave the dormant code in the system was a huge oversight. Ultimately, Knight lost over $460 million and was acquired by a competitor.

Y2K

The Year 2000 problem (Y2K) was the potential for computer errors related to the formatting and storage of calendar data for dates in and after the year 2000.

To save the limited memory in computers pre-2000, many four-digit years (1985) were represented with only the final two digits (85), making the year 2000 indistinguishable from 1900.

This decision led to computer code being unable to distinguish dates correctly. It had the potential to bring down worldwide infrastructures for computer-reliant industries.

It is estimated that the US spent $100 billion dollars remediating Y2K.

Friendster

In March, 2003, Jonathan Abrams launched Friendster, one of the first social media sites. By June, 2003, Friendster had 835,000 users. By fall, there were 3 million.

This sudden influx of traffic created a problem. The site was slow. A Friendster webpage sometimes took 40 seconds to load.

Abrams saw the need for a site reconfiguration but the board was indifferent. Frustrated with wait times, users began migrating to Myspace, which attracted 22.1 million unique users monthly in 2005. Friendster was getting just 1.1 million.

Friendster's traffic scaled faster than the decisions of its original design could handle. Slow page loads adversely affected the user experience, but the executives at Friendster did not see page load time as important. By 2009 Friendster was sold to MOL Global for $40 million.

Discussion

Dormant code left in a system, short-cuts to save memory, and a software design not updated to handle huge amounts of traffic.

These early decisions had a profound impact on how a computer system behaved later.

Technical debt is a by-product of engineering a system. It is the cost and risk overhead created by the environment.

The Environment

When engineering builds a software solution, two different artefacts are created: the solution that solves the customers' problem, and a computing environment in which that solution runs.

Consider a website that lets users store their personal notes in the cloud.

An amount of code will be required that directly provides the solution. Code to log the user in, that lets them type notes and save them.

To achieve this, additional code is required to:

• register and login users, helping them reset their password
• save notes in durable storage associated with a user's account
• display a coherent user interface that meets usage and accessibility requirements

User login credentials and their notes must be saved somewhere, requiring some form of persistent storage.

To enable the first version to be released as quickly as possible (a business decision to get ahead of competitors), an engineering decision is taken to store login and note data in files.

A backup schedule is required so that everyone's notes are periodically copied elsewhere. Users would not be happy if the system lost their notes due to a hardware failure.

This additional code, the use of files, the backup mechanism, and all the hardware necessary to run the code, is the environment.

Adding a new feature

A new feature is to be added: the ability to send a note to another user.

The addition of this feature has to take place within the context of what already exists: the user interface code, login support, file storage, the backup schedule.

Technical debt is the accumulated cost of past technical decisions whose consequences must be paid later. The use of files is technical debt as all other solutions (such as the backup mechanism) will process those files.

The consequences of using file storage

Sending a note requires writing to another user’s set of files. This requires the safe and coordinated writing of data in the face of errors, such as software crashes and hardware failure. A note should be sent either in its entirety or not at all (a user would not want to see a partial note). But file systems do not provide an atomic multi-user update mechanism, so engineers must build it for themselves.

An atomic mechanism is one that works all or nothing. In the context of sending a note to another user, the note is either fully written or not written at all. Atomic update is the solution to partial note updates.

Two users sending notes at the same time to each other can corrupt a user's set of note files. Engineers must design a coordination protocol to handle concurrency and prevent corruption.

To send a note, the system must first find the recipient’s set of files. File systems do not provide indexed queries, so engineers must build scanning or indexing code. This would be straightforward for 100 users but scaling to 100 million requires careful attention to how the files are arranged in a directory hierarchy.

If the write of a note fails halfway due to a software crash or hardware failure, a user's note store might become corrupt. Engineers must design write and test journaling or temporary‑file commit protocols.

Backups run on a schedule. If a file is being modified while the backup process copies it, a partial or inconsistent copy may be written to the backup. Engineers must add pause and resume logic or transactional backup behaviour.

The earlier decision to store data in files is felt as technical debt because engineers have to add these features to ensure a file system can be used safely to share notes.

In moving on from the original version to sending notes it is clear that a technology other than files is now required. Remaining with files requires engineers to implement technologies that already exist elsewhere.

Using files let the business release version one quickly beating their competition, but the focus must now be on scaling the solution and to do that using files will increase business risk in future as engineering will struggle to provide reliable, concurrent, atomic storage at scale using files.

Remaining with files represents a design, implementation, and test effort. This effort is technical debt. It is the work that becomes necessary because of earlier decisions.

Overall, it would be faster to remove the use of files and move to a more principled database-backed solution that will enable the business to scale and operate with less risk. A database provides solutions for error handling, concurrent operation and atomic data handling. Using a database enables the engineers to focus on features without also building the mechanism to achieve this using files.

Why is it difficult to communicate technical debt?

When the idea of sending notes to other users is raised, engineering may communicate that not paying attention to technical debt as part of the change will mean more work in the future.

This discussion usually concludes with two numbers: how much time is required to address both the technical debt and the new feature, and how much time is required to release just the new feature.

Given this, implementing just the new feature usually wins the argument even though the business is still carrying the risk of the technical debt.

Why is this?

Biases

Biases are systematic distortions in thinking, judgement, or behaviour that cause people to lean toward certain conclusions, interpretations, or decisions over others. A bias is a preference that tilts someone away from neutrality. A bias may be unconscious or conscious.

Examples are:

• Cognitive bias: a mental shortcut that leads to flawed reasoning.
• Confirmation bias: seeking information that supports what you already believe.
• Selection bias: drawing conclusions from a non‑representative sample.
• Algorithmic bias: when a system’s outputs skew because of its training data or design.

When deciding whether to address technical debt or not a number of biases are at play.

Present bias

Given two similar rewards, humans show a preference for one that arrives sooner.

For example: when asked "Would you prefer a dollar today or three dollars tomorrow?" humans are more likely to choose the immediate reward.

However, when asked "Would you prefer a dollar in one year or three dollars in one year and one day?", people are happy to wait the extra day.

Those individuals who take the dollar today are described as "present-biased".

In the technical debt case, the sooner reward is the next feature, without addressing the technical debt. The latter reward is the next feature with the technical debt addressed.

The latter reward is the same thing as far as they are concerned but just delayed (so why wait?). It is hard for them to relate to the presence of technical debt as they are not the person directly affected by it, although its effects will eventually be felt by everyone in the business.

Normality bias

Normality (or normalcy) bias is a psychological phenomenon where individuals disbelieve or minimize threat warnings, assuming that the future will resemble the past.

This bias arises from several cognitive mechanisms:

• Cognitive dissonance: discomfort from holding conflicting beliefs leads people to downplay threats
• Optimism bias: overestimating positive outcomes helps individuals feel immune to misfortune
• Anchoring bias: reliance on initial information causes reluctance to update risk assessments

Even though engineering are saying that files are no longer the right approach, the system currently works fine using files.

Normality bias causes people to downplay the threat posed by continuing to use files and the risk associated with building code to use files safely in the face of errors, concurrency, and atomic (all or nothing) update.

In short, a leader's thinking is: files has not gone wrong so far, why would it in future?

In fact, using files enabled the faster deployment of version one. So the use of files is seen as an advantage and that getting rid of them would be a strategic mistake.

Availability bias

Availability bias is a cognitive bias where people judge the likelihood or importance of events based on how easily examples come to mind, rather than on objective data. Less memorable or less accessible information is often undervalued, even if it is more statistically relevant.

If someone outside engineering has no direct experience of dealing with technical debt, when presented with the future risk that it poses, they are likely to undervalue its effect.

Optimism bias

Optimism bias is the cognitive tendency to overestimate the likelihood of positive events and underestimate the likelihood of negative events.

Individuals believe they are more likely than others to experience favorable outcomes and less likely to encounter negative events. This bias is widespread, affecting roughly 80% of the population, and is observed across cultures, genders, and age groups.

Optimism bias reflects a systematic distortion in how the brain processes information about risks and rewards. When people receive information that is better than expected, they readily adjust their beliefs, but when information is worse than expected, they tend to ignore or underweight it.

Positive expectations also activate the brain’s reward system, reinforcing optimistic thinking.

Optimism bias can lead to poor decision-making and the underestimation of risk such as the possible impact of smoking on health.

People consistently rate their chances of positive outcomes as above average and negative outcomes as below average, a pattern that is statistically impossible for everyone simultaneously.

When considering technical debt, those outside engineering see the results of engineering effort, not the activities necessary to achieve it.

Even though engineers might have to work significant amounts of overtime to get files working for version two, a successful outcome reinforces someone's overestimation of a positive event.

In short, the business carried on using files and the system worked: the outcome was positive. Therefore, not addressing the technical debt was the right call.

Communicating the effects of technical debt to non-engineers

This section goes into the detail of how to measure and calculate metrics that can be used to communicate the business risk of accumulating technical debt.

Given these biases, an effective way to communicate the effects of technical debt to non-engineers is by quantifying cost, impact and risk:

If you pursue this route, you will first of all need to collect the data that the metrics are based on, perform the calculations and communicate what the metrics mean within the context of your organisation.

Each section below contains a discussion of how to calculate the metrics.

TD

Development work, W, is divided into two parts: U and TD.

U is the useful amount of work required to deliver that feature, such as the code that directly implements send note functionality.

TD is the amount of work required to construct U within the environment built based on previous business and engineering decisions. This is the work required to safely use files in the face of errors, concurrency and atomic update.

Over time, U stays stable as large jobs are broken down into smaller ones that are roughly the same size.

However, over time, TD increases as the number of previous engineering decisions accumulates and completing U has more environment to consider.

Calculating TD

It is possible to collect the values of U and TD. U is the amount of work (in hours) that it took to deliver the requested feature. TD is the part of U (in hours) that was required because of the environment.

Accurate figures for U and TD can be collected after W has been completed. Actual figures are preferred to estimates as they reflect the current state of the system as it affects the business each day.

Risk velocity

This is the speed with which TD is increasing over time.

It measures how fast the organisation is accumulating risk.

Calculating risk velocity

Assume we have sampled 10 TD values collected over the course of the previous ten sprints where each sprint is two weeks in length.

   TD = [5, 6, 7, 9, 10, 12, 15, 17, 20, 24]
Delta = [1, 1, 2, 1,  2,  3,  2,  3,  4]

The first delta (1) is 6 - 5. The second delta is 7 - 6, the third is 9 - 7, and so on.

Calculating risk velocity shows that the extra work required for TD is always increasing, and that the size of each increase is itself rising as the delta value increases over time: it is 1 at the start and 4 twenty weeks later.

Risk acceleration

Risk acceleration is the change in velocity.

This answers the question: are we accumulating more risk or less risk per unit of time?

Calculating risk acceleration

          TD = [5, 6, 7,  9, 10, 12, 15, 17, 20, 24]
       Delta = [1, 1, 2,  1,  2,  3,  2,  3,  4]
Acceleration = [0, 1, -1, 1,  1, -1,  1,  1]

Acceleration is computed from the delta. The first acceleration is 1 - 1. The second is 2 - 1, the third is 1 - 2, and so on.

The pattern in the example acceleration is mostly positive, meaning the environment is getting harder to work with as time passes.

Conditional impact

Conditional impact is the full negative cost assuming that the TD-induced failure occurs. The probability of TD occurring may be small. However, conditional impact measures the cost to the business if that event occurred, regardless of its probability.

Technical debt increases the time it takes to deliver outcomes. As a business scales and gains more users, any negative event will impact more people. So even if the probability of that negative event is low, the impact of the event if realised can be catastrophic.

Conditional impact reveals how bad a TD‑driven failure is, how much damage the environment can produce, and whether the organisation’s risk appetite can tolerate the downside and whether risk tolerance thresholds are already breached.

Calculating conditional impact

In calculating the conditional impact, the goal is to quantify the likely damage to the organisation should a TD event occur.

To calculate:

• Identify the failure mode
  For example, files are corrupted due to concurrent activity of two users exchanging notes
• List everything that is impacted should this happen
  • direct engineering recovery time
  • customer‑visible outage duration
  • number of users affected
  • data loss magnitude
  • reputational cost
  • regulatory exposure
• Assign a cost value:
  • cost in hours
  • cost in money
  • cost in lost opportunity

This gives you a list of cost values that are represented in their own units. It is more informative to leave the values in their respective units (hours or monetary cost), rather than translate all values to a single unit and then sum because when summing, the relative importance of one value (reputational cost) may be swallowed up by another value, e.g., the cost to recover based on 40 hours of engineering time.

Impact = (
    40 hours,          # engineering recovery
    2 hours,           # outage duration
    100000,            # users affected
    5000,              # data loss magnitude
    50000,             # financial / reputational cost
    Medium             # regulatory exposure
)

The list tells you the full downside profile across all relevant types of cost.

Risk appetite

Risk appetite is the maximum downside your organisation is willing to tolerate from a TD‑driven failure. It is defined in terms of TD, its velocity, and its potential knock-on effects.

Put another way: how much TD‑related damage can the business absorb without threatening overall strategy, delivery, or business reputation?

Risk appetite is a business-wide metric and is set by business leaders outside engineering.

It expresses:

• the largest acceptable TD‑driven failure
• the maximum tolerable interruption to delivery
• the biggest acceptable customer‑visible impact
• the largest acceptable financial or reputational hit
• the highest tolerable fragility before the system becomes unsafe

Risk appetite captures the maximum impact tolerable from a negative event.

If a business has a low risk appetite, the organization is prepared to address its risk earlier. If the risk appetite is higher, a business is willing to carry TD-related exposure for longer periods on the understanding any fallout from a negative event will be larger.

Calculating risk appetite

1. Identify leadership constraints
   These constraints exist even if they are not written down.
   • maximum acceptable outage
   • maximum acceptable customer harm
   • maximum acceptable financial loss
   • maximum acceptable reputational damage
   • maximum acceptable regulatory exposure
2. Translate constraints into measurable units
   • outage: "We cannot be down more than 2 hours."
   • customer harm: "Anything above 500 users is unacceptable."
   • financial loss: "We can tolerate up to £10k."
   • reputational damage: "Low is acceptable, medium is not."
   • regulatory exposure: "Zero tolerance."
3. Construct the appetite vector

   RiskAppetite = (
       2 hours,     # maximum outage
       500,         # maximum users affected
       10000,       # maximum financial loss
       Low,         # maximum reputational hit
       None         # maximum regulatory exposure
   )
   

   This list of values defines the maximum tolerable downside.
4. Compare conditional impact to appetite
   Risk appetite is breached when any of the values from conditional impact exceeds the corresponding value of the appetite vector. For example:
   
   If conditional impact has been found to be (40h, 2h, 100000, 5000, 50000, Medium)
   
   And the organization's risk appetite is set at (2h, 500, 10000, Low, None)
   
   Then the appetite has been breached at both maximum tolerable financial loss and maximum tolerable reputational hit.
5. Use appetite to drive action
   If CI exceeds RA for any value, remediation is mandatory, not optional.

Risk tolerance

Risk tolerance is the minimum value over which action should be started to mitigate any negative impact of a TD-related event. This is also a business-wide metric set by leaders outside engineering.

If the value for risk tolerance is over a stated amount, this is a signal that action should be taken before the appetite is reached.

Risk appetite is the cliff edge. Risk tolerance is the guardrail placed well before the cliff.

It is a warning and should not be ignored as the business is moving towards a precarious situation.

A business may be prepared to temporarily flex risk tolerance to ensure the delivery of a project: briefly tolerating the risk posed by one part of the system so another part may be changed. This is similar to TD being created by the original choice of files for note storage. Tolerating risk might be OK in the short-term but the business carrying increasing risk overtime is eventually going to have to be paid.

Calculating risk tolerance

1. Choose measurable indicators Risk tolerance must be defined using the same values as conditional‑impact

   • engineering recovery time
   • outage duration
   • users affected
   • data loss magnitude
   • financial / reputational cost
   • regulatory exposure

2. Define appetite first You cannot calculate tolerance until appetite is known.

   RiskAppetite = (
       8h,       # max engineering recovery
       2h,       # max outage
       500,      # max users affected
       0,        # max data loss
       £10k,     # max financial/reputational cost
       None      # max regulatory exposure
   )
   

3. Set tolerance as a percentage of appetite This approach can be flexed.

   • 50% of appetite for operational metrics
   • 25% of appetite for customer‑impact metrics
   • 0% for regulatory exposure (zero tolerance)

   RiskTolerance gives you early‑warning thresholds.

   RiskTolerance = (
       4h,        # 50% of 8h
       1h,        # 50% of 2h
       125,       # 25% of 500 users
       0,         # same as appetite (zero tolerance)
       £2.5k,     # 25% of £10k
       None       # same as appetite (zero tolerance)
   )
   

4. Alternatively. You can derive tolerance from historical TD behaviour If you have TD, velocity, and acceleration data, you can set tolerance based on:

   • the point where TD velocity historically begins to accelerate
   • the point where fragility scores begin to rise
   • the point where correlated failures begin to appear
     
     For example:
     
     
   • If TD velocity > 2 hours/sprint then tolerance breached
   • If TD acceleration > 1 hour/sprint² then tolerance breached
   • If fragility score > 0.4 then tolerance breached
     
     This method ties tolerance directly to engineering reality.
5. Use both risk appetite and risk tolerance The strongest approach is hybrid as appetite defines the maximum and historical TD behaviour defines the early warning.

This produces stable and defensible thresholds.

How tolerance is used

Risk tolerance is the trigger point.

If any conditional‑impact dimension exceeds tolerance, you must act now.
If conditional impact exceeds appetite then you are already too late.

Tolerance is the action threshold. Appetite is the catastrophe threshold.

The gap between the two is your opportunity to address the issue. It is breathing space, room to flex. But that space is not infinite. TD will accumulate over your appetite levels eventually.

Mitigation cost

Mitigation cost is the price of reducing TD, its velocity, or its fragility. It is the economic side of choosing files for note storage: the "pay now vs pay later with interest" decision.

Mitigation cost expresses how much is costs the business to reduce TD enough to bring risk velocity, acceleration, and fragility within acceptable values.

It is not the cost of the work (W) or its useful component (U). It is the cost of making the environment safer.

It is the cost of moving away from file-based notes, to another approach, such as, one based on a relational database, and the cost associated with building the environment around that technology which does provide support for error recovery, concurrency and atomic (all or nothing) updates.

This cost is the environmental cost. Its value captures the cost being paid later, having taken earlier engineering decisions, plus the interest.

The interest is the growth behaviour of TD, the extra overhead you have already paid per unit of time, the ongoing compounding effect of the fragility introduced by TD, and the rising cost of all your users interacting with a degraded environment. The interest is the penalty you pay for delaying remediation.

Calculating the mitigation cost

Mitigation cost is the price of making the environment safe again.

This calculation is about quantifying the work required to remove the environmental penalties created by past decisions, plus the interest already paid.

1. Identify the remediation action Mitigation cost is tied to a specific change in the environment such as moving from a file-based solution to one based on a database, plus building the environment around that database. This is the scope of mitigation.

2. Break the whole of the remediation into concrete tasks List every engineering activity required to remove the TD penalty:

   • design new persistence model
   • implement schema and migrations
   • write new data‑access layer
   • remove file‑based logic
   • add proper concurrency controls
   • add atomic commit behaviour
   • rewrite backup logic
   • update any UI flows
   • test, deploy, and monitor

   This is the engineering work required to eliminate the TD represented by the use of files.

3. Estimate engineering effort
   For each task, estimate:

   • hours
   • people
   • calendar time
   • testing overhead
   • deployment overhead

   Then sum the hours for the direct cost of the engineering effort.

4. Calculate the interest already paid
   Interest includes:

   • extra TD hours per sprint
   • extra fragility‑driven incidents
   • extra operational overhead
   • extra debugging time
   • extra coordination time
   • extra recovery time from TD‑driven failures

   You can also compute interest by summing TD velocity and acceleration and multiplying by the number of sprints since the TD was created. This captures the penalty for delaying remediation.

5. Sum the engineering cost and the interest Mitigation cost is the cost to engineer the new solution (step 2), plus adding in the cost from step 4.

6. Optional: include opportunity cost which is the the value of what you cannot do because you are doing something else. The opportunity cost is:

   • features not delivered
   • customers not served
   • revenue not captured
   • strategic initiatives delayed

Environmental fragility

Environmental fragility is the susceptibility of your engineering environment to fail. It is the property that determines how easily small TD‑driven issues cascade into large, multi‑system failures.

It captures how easily the environment breaks when TD, velocity, or acceleration increase.

It is an early warning signal. If your system is fragile and prone to failure, your engineers will be attending to fixing the enviroment and not focussing on building new features for your customers.

Calculating environmental fragility

The fragility measure is built from observable signals in your environment. Its values form a composite indicator derived from how your system behaves under the pressure created by TD. These values are turned into a single score that captures how fragile your environment is.

1. Correlated‑failure frequency
   Count how often a single defect triggers failures in multiple components.
   
   For example:
   
   • one bug → 3 services fail
   • one data issue → 5 alerts are triggered
   • one outage → cascading retries, leading to queue saturation
     
     To turn into a single value use F1 = failures correlated to TD / total failures
2. How many components are affected
   Measure how many components are affected when something goes wrong.
   
   To turn into a single value use F2 = components affected / total components
3. Recovery sensitivity
   Measure how long recovery takes relative to the size of the initial defect.
   
   To turn into a single value use F3 = recovery time / initial defect size
   
   If a tiny defect causes a huge recovery window, fragility is high.
4. Coupling density
   Quantify how tightly components depend on each other.
   
   To turn into a single value use F4 = number of unsafe dependencies / total dependencies
   
   Unsafe dependencies include:
   • undocumented interfaces
   • brittle contracts
   • shared mutable state
   • implicit ordering
   • hidden side effects
5. TD amplification factor
   Measure how much TD increases the cost of small changes.
   
   To turn into a single value use F5 = extra work caused by TD / useful work
   
   This is your TD(t) ratio which is the proportion of total work that is technical‑debt overhead at time t. It is an expression of how much the environment is dragging you down you right now.

To construct the fragility list you combine the five values from above.

FragilityVector = (
    F1,   # correlated-failure frequency
    F2,   # how many components are affected
    F3,   # recovery sensitivity
    F4,   # coupling density
    F5    # TD amplification factor
)

To convert to a single fragility score, you first of all convert F1 to F5 into a value between 0 and 1. This can be done by dividing the F value with the maximum amount tolerable for that value.

You will then have a list of 5 numbers between 0 and 1.

To convert these 5 to a single fragility score you sum them and divide this value by 5.

This gives a score between 0 (robust) and 1 (extremely fragile).

You can also weight dimensions if leadership cares more about customer impact or regulatory exposure.

How to interpret the score:

• 0.0–0.2 → robust
• 0.2–0.4 → stable
• 0.4–0.6 → fragile
• 0.6–0.8 → highly fragile
• 0.8–1.0 → catastrophic fragility

This score will show you whether:

• TD is merely inconvenient or a serious business threat
• velocity and acceleration will compound
• small issues will cascade
• appetite and tolerance thresholds are meaningful
• mitigation cost is urgent or optional

Fragility determines how much worse technical debt becomes when it interacts with the environment.

Technical debt on its own is overhead. Fragility is what makes that overhead dangerous.

Conclusion

In building a product, decisions have to be made. In building a technology-based product, those earlier decisions can make future change more time-consuming.

What should be done is to explicitly surface and track metrics that reflect the organization's levels of technical debit. This gives the organization better sight of the risk that the debit represents.

Metrics neutralise bias by replacing belief, hunches or guesses with evidence.

The metrics in this article present a business with a technical debt governance model.

Governance must include risk appetite and tolerance thresholds and leaders must incorporate TD metrics into decision-making.

Technical debt must be treated as a business risk and not as an engineering outcome.

Paying attention to technical debt during decision-making will lead to improved delivery predictability, reduced environment fragility, fewer system failures and lower long-term cost.

Ignoring technical debt is a strategic decision, not an engineering one.

Read next: - When Urgency is High but Progress is Slow
When urgency rises faster than progress, your work environment is signalling that the work structure has slipped, leading to more overhead and wasted work.

Related Articles

• When Your Board Wants a Strategy and You Have Three Weeks
• The Missing Structure Agile Cannot Fix
• Software Delivery Constraints and Pipeline Throughput
• When Code Is Cheap, Judgement Matters More
• Measuring Reliability in the Age of AI