The Technical Debt Tax

The Line Item That Isn't There

Every startup has line items for engineering salaries, cloud infrastructure, and tooling. Those numbers sit in the board deck, color-coded and argued over every quarter. They're the costs you negotiate.

There's another cost that never makes the slide. It compounds silently until one day a founder looks at a team of eight engineers and wonders why they ship like a team of five. The engineers aren't lazy. The standups are still full of work. The roadmap still slips.

You can feel the drag even when you can't price it. A feature that used to take two weeks takes four. A simple config change ships with a Slack thread of "be careful around that module." A new hire takes a full quarter to make their first meaningful commit, and nobody finds that surprising anymore. None of this shows up in the P&L. All of it shows up in the output.

Where the Cost Actually Lives

Ward Cunningham coined the term technical debt in 1992 to describe a specific trade: ship code you don't fully understand yet, with the explicit plan to pay down the shortcut as your understanding catches up. Martin Fowler has spent two decades pointing out that most teams use the metaphor wrong. They treat debt as "code we'll clean up later" rather than as a live interest payment on every future change.

Here's what the interest actually looks like on a given Tuesday. You're the engineering lead. A PM asks for a change to the pricing flow. Six months ago, that was a one-day job. Today, the pricing logic touches four services, two of which were built around assumptions that stopped being true last quarter. Your best engineer opens the PR and realizes she has to refactor the billing adapter before she can safely change the price string. That refactor surfaces a test suite nobody's trusted in three months. She's now three days into a one-day task. You haven't hired a worse engineer. You've asked the same engineer to move the same weight through thicker mud.

Multiply that Tuesday across every engineer and every ticket for a quarter and you have a number. The ThoughtWorks Technology Radar has tracked this erosion across hundreds of engagements and consistently flags it as the dominant productivity killer in mature codebases. Charity Majors has written that observability debt in particular is often the hidden one — you can't pay down what you can't see, and most teams can't see where their time is actually going.

The four costs feed each other. Slower velocity pushes leaders to hire. New engineers hit the same mud, plus onboarding complexity that grows with the codebase. More engineers in a fragile system create more debt faster. Somebody eventually proposes a rewrite, which costs two to three times what building it correctly would have. Each cost makes the next one larger.

Naming It

We call this the technical debt tax. Like any tax, you pay it whether you acknowledge it or not. Across our engagements at GigSmart, ToolWatch (now AlignOps), Oxen.ai, and Brandfolder, the pattern is consistent enough to price roughly: mature-stage startups without deliberate technical leadership typically lose around 30% of engineering capacity to this tax before anyone names it. When the tax goes unnamed long enough, it becomes a spiral — hiring to compensate for velocity loss, which creates more debt, which requires more hiring.

That 30% is the shape of what we've seen, not a hard law. It tracks with what Gergely Orosz at The Pragmatic Engineer has documented when teams start measuring cycle time against a clean baseline. The specific percentage matters less than the recognition: the tax is real, it compounds, and nobody sends you the bill.

The Five Things Worth Measuring

If you want to know your rate, stop estimating and start measuring.

Track how long comparable features take now versus six months ago. Not perception — ticket data. If a two-week feature has become four, the delta is your velocity tax, and it's probably an undercount because the hardest tickets don't get written down honestly.

Watch bug trajectory. Production bugs climbing while feature output flattens means you're accruing debt faster than you're repaying it. The ratio of "fix" commits to "feat" commits in your git history will tell you the truth faster than any dashboard.

Ask engineers directly what percentage of their time goes to fighting the codebase versus building new things. The answers are uncomfortable and accurate. They are also, in our experience, the single best predictor of whether a team is about to lose its senior talent.

Notice deployment confidence. If nobody wants to ship on a Friday, the codebase is telling you something the metrics won't. Routine deployments that require a runbook and a prayer aren't routine.

Measure onboarding speed. If new engineers take longer than three to four weeks to contribute productively, you're not onboarding engineers. You're training archaeologists on a codebase nobody fully remembers.

The Reframe

The question most founders ask is "how do we pay down the debt?" That's the wrong question. The right question is whether you took the debt on deliberately in the first place.

Debt that was chosen — shipped fast to hit a deadline, with a named person accountable for the cleanup — is leverage. It's how you beat slower competitors to market. Debt that accumulated because no one was steering the architecture is something else entirely. It's the cost of not having had the conversation. Cunningham's original framing drew this line cleanly: the metaphor only works when the team understands the loan they took. Absent that understanding, you're not in debt. You're in decay.

This is where experienced technical leadership earns its cost. A fractional CTO at two days a week runs roughly $120K annually. Against eight engineers at $150K a piece, a 30% tax is $360K walking out the door every year — $1.08M over three years. The leadership question isn't whether you can afford senior architectural judgment. It's whether you can afford to keep paying the tax instead.

The Decision You Actually Have

You won't avoid debt. The teams that win aren't the ones that never take shortcuts — they're the ones who took them on purpose, with a named person who knows where the body is buried and a plan to go back for it. That's a choice you can still make. The teams that lose are the ones where the shortcuts piled up while everyone was busy, and now no one can point at the Tuesday when things got heavy.

If you're reading this and already nodding at your own codebase, the tax has been running for a while. The next move is figuring out your actual rate — not the story you tell the board, but the number underneath. That's the diagnostic we run, and it's usually the first honest conversation the team has had about what the last two years actually cost.