Technical debt is the accumulated cost of shortcuts in a product's code and systems. Diligence measures it through how much engineering time goes to maintenance, how fast changes ship and how often they break things.
10 min read · Level 3
I find engineers far more candid about technical debt than founders, not because founders hide it but because founders see the roadmap and engineers see the code. Asking two or three engineers the same question about where their time goes usually produces a clearer picture than any architecture diagram.
Technical debt is not bad in itself. Shortcuts that help a startup learn quickly are often the right choice. It becomes a risk when the interest - the ongoing cost of working around old decisions - grows faster than the team.
Measures that do not require reading code:
Measure What it shows Share of engineering time on maintenance how much capacity debt consumes Time from idea to shipped change how easily the system changes Frequency of releases confidence in the system Share of releases causing problems fragility Areas engineers avoid touching concentrated debt Test coverage and automated checks safety of making changes
A team of 12 engineers says about 45% of their time goes on fixing bugs, workarounds and maintenance:
12 x 45% = 5.4 engineers' worth of time
Only about 6.6 engineers' worth of effort goes into new product. A plan to double feature output by hiring 12 more engineers may achieve far less if the debt is not addressed.
Because debt slows everything the company plans to do. It delays product launches, increases outages and makes hiring less effective.
It is also where technical and financial diligence meet: engineering is often the largest cost in a software company.
Educational, not personalised financial advice. Nothing in the Investor Academy is a recommendation to buy, sell or hold anything — what is right for you depends on your own circumstances and the rules where you live.
Release history over a year.
Period Releases per month Releases causing incidents Year ago 20 5% Now 8 20%
The team has grown, but it ships less often and breaks things four times as frequently. The investor asks what changed, and whether the planned new hires will be spent building features or fixing the system.
Asking founders whether they have technical debt, which always produces 'some, under control', instead of measuring how engineering time is actually spent.
Get estimates of maintenance versus new work from the team, not only the leader.
Review release frequency and incident rates over time.
Ask which parts of the system are hardest or riskiest to change.
For large investments, have an experienced engineer assess the code.
During diligence on companies where product development speed matters to the plan.
Do not treat early-stage shortcuts as failures in themselves; judge whether debt is understood and manageable.
Software delivery research, including the widely cited DORA research programme, has used measures such as deployment frequency, lead time for changes and change failure rate as indicators of how effectively engineering organisations deliver, finding strong differences between high- and low-performing teams.
How often and how safely a team ships is a measurable proxy for the health of its systems.
Create a free account to read the rest and apply it to your own investing.