The tech debt spreadsheet that made my cofounder finally understand why we need a refactoring sprint

For six months I had been telling my cofounder that we needed to dedicate a sprint to paying down technical debt. Every time, the conversation followed the same script. I would say we have significant tech debt. He would ask what that means for the business. I would explain that our codebase was getting harder to work in. He would ask how that compared to shipping the features that clients are asking for. I would struggle to quantify it. He would say let us revisit next quarter. Quarter after quarter, the debt grew.

Generate a moody startup meeting aftermath scene: roadmap cards, pitch deck on screen, notebook with engineering estimates, dark neutrals with amber accents, 16:9, no people, no cheesy corporate vibe.

This phase is where the title finally started to feel expensive. It also builds on what I learned earlier in “I mass-rejected 200 resumes and hired the person who asked the best questions in the interview.” Hiring, planning, founder conversations, and bad weeks in production all piled into the same calendar. A lot of the systems thinking I kept in lifeos and flowscape showed up here too: clarity is not paperwork, it is how you stop uncertainty from leaking into people.

Editorial supporting image for the section "Why "Tech Debt" Fails as Communication" in the article "The tech debt spreadsheet that made my cofounder finally understand why we need a refactoring sprint". Show conference-room table or desk with planning notes, incident timeline, dashboard printouts, half-drunk coffee, and a worn notebook for "The tech debt spreadsheet that made my cofounder finally understand why we need a refactoring sprint". Focus on one operational artifact that makes the post feel lived-in rather than conceptual. Color palette: slate, amber, off-white paper, low-contrast office shadows. Mood: tense but controlled, operational, carrying team and system weight at the same time. Composition: 16:9 landscape image, documentary/editorial feel, no text overlays, no stock-photo polish. Avoid: No staged handshake photos, no smiling meeting stock imagery, no motivational poster energy, no text overlays.

Why “Tech Debt” Fails as Communication

The phrase “tech debt” is engineering jargon that communicates nothing to a non-technical person. It sounds abstract, it sounds like something engineers complain about to avoid doing product work, and it has no inherent urgency. When an engineer says “we have tech debt,” a business person hears “engineers want to do work that does not ship features.” The framing is adversarial before the conversation even starts.

The fundamental problem is that tech debt is described in engineering terms when it needs to be described in business terms. My cofounder does not care about code quality for its own sake. He cares about revenue, retention, risk, and velocity. If tech debt affects those things, he will prioritize it. If I cannot connect the dots, he will not, and he should not.

This was my failure, not his. I was asking him to trust my judgment that tech debt mattered without giving him the evidence to make that judgment himself. In a startup where every sprint matters, “trust me” is not a strategy for resource allocation.

The Spreadsheet

In late January 2025, after yet another deferred refactoring conversation, I spent a weekend building a spreadsheet. Not a document about technical architecture. A business risk document that happened to be about code.

Each row was a single tech debt item. The columns told the business story.

• Description: One sentence explaining the issue in non-technical language
• Customer impact: What a client would experience if this goes wrong. Example: “Bank statement import fails silently, client reports missing transactions”
• Probability: How likely the issue is to cause a customer-facing incident in the next 90 days. Rated High, Medium, or Low based on incident history
• Blast radius: How many clients would be affected. One client, a segment, or all clients
• Revenue at risk: Dollar estimate of monthly recurring revenue associated with affected clients
• Remediation cost: Engineering effort in person-weeks
• Cost of inaction: What happens if we do not fix it. Measured in expected incident response hours and client churn risk

I populated 23 rows. Three had high probability ratings, meaning I expected them to cause incidents within 90 days. The top three items alone represented risk to $340,000 in annual recurring revenue. The total remediation cost for all 23 items was 14 engineering weeks. The cost of fixing the top three was 4 weeks.

The Conversation That Finally Worked

I booked 30 minutes with my cofounder and walked through the spreadsheet. I did not use the words “tech debt” once. I framed it as an operational risk review. Here are 23 known risks in our product. Here is the probability of each one causing a client-facing incident. Here is the revenue at risk. Here is what it costs to fix.

His first question was: “Why have we not fixed the top three already?” That was the moment I knew the framing worked. He was not asking why engineers wanted to refactor. He was asking why the business had not mitigated known revenue risks. The conversation shifted from “engineers want time for cleanup” to “the company has unmitigated operational risks.”

We agreed on a two-week sprint dedicated to the top seven items. Not because he suddenly understood the technical details, but because the business case was clear. Four weeks of engineering time to mitigate risk to $340,000 in ARR is a no-brainer investment. The same information, framed as “we need to refactor some modules,” had been getting deferred for six months.

What I Learned About Translating Engineering to Business

• Never use the phrase “tech debt” with non-technical stakeholders. Describe the risk in their language.
• Every technical issue can be connected to a customer impact. If it cannot, it is not actually urgent.
• Probability and blast radius matter more than severity. A severe issue with low probability loses to a moderate issue with high probability.
• Revenue at risk is the number that moves budget conversations. Find it and use it.
• Remediation cost in person-weeks is more meaningful than story points. Business people understand time and headcount.
• Framing matters more than content. The same information presented as “risk mitigation” gets approved while “tech debt cleanup” gets deferred.

Create a realistic editorial image of a technical planning desk after a difficult decision: cleaned-up notes, timeline revisions, calmer composition, 4:3, grounded startup atmosphere, no text.

This is where the role stopped feeling like senior-engineer-plus. Every decision had a human system wrapped around it: founders, customers, auditors, tired teammates. The same systems thinking bled into portfolio, pipeline-sdk, and dotfiles, where defaults matter more than heroics.

If you cannot explain why a technical improvement matters to the business in one sentence without using the word “technical,” you do not understand the business case well enough. Go back and figure it out before asking for the sprint.

The spreadsheet took four hours to build. The refactoring sprint shipped on schedule. We fixed the top seven items, prevented two incidents that would have hit in March based on the trend data, and reduced our incident response burden by roughly 10 hours per month. My cofounder now asks me for the risk spreadsheet update every quarter. He does not call it the tech debt spreadsheet. He calls it the risk register. The language matters.