Q&A

Technical Debt Is Not Free: Chad Green on Making the Invisible Visible

• By David Ramel
• 07/23/2025

Ask any development team about technical debt and you're likely to get a nod of recognition--followed by a shrug. It's a familiar term, but too often treated as a theoretical concept rather than a measurable risk. In reality, technical debt--whether incurred intentionally or as the byproduct of fast-paced delivery--can quietly erode a team's velocity, derail timelines, and add friction to product innovation if left unmanaged.

That's the central focus of the upcoming session "Technical Debt Is Not Free," part of the Sept. 8-12 San Diego 2025 Visual Studio Live! conference lineup. Led by Chad Green, senior systems architect at Jasper Engines & Transmissions, the session aims to help developers move beyond buzzwords and toward sustainable, tactical practices for identifying, scoring, and reducing debt in their codebases.

Green brings firsthand experience to the discussion, having seen the long-term impact of neglected debt across teams of all sizes. His session promises to equip attendees with not only diagnostic tools--like the Technical Debt Ratio and his own pragmatic Technical Debt Score--but also concrete strategies to communicate technical debt's business impact to stakeholders.

He also brings something else: a revelatory phrase he learned from an exec that has steered his thinking and even served as the spark for his session.

He discusses that phrase below in a Q&A we held to learn more about the session, the red flags to watch for, and how teams can start reducing debt in small, consistent steps--and how to learn more about this topic and prepare for his session.

VisualStudioMagazine: What inspired you to present a session on this topic?
Green: The inspiration came from countless real-world conversations, but one in particular stood out to me. I had a Vice President who understood technical debt, at least on paper. Whenever we discussed issues or the need to take shortcuts with new features, he'd often say, "We can just write that up as technical debt," as if naming it solved the problem. I found myself repeating the same line: "Sure, but technical debt isn't free. Sooner or later, we have to pay it back--with interest."

That phrase lingered. It became the heartbeat of this talk because too many teams treat technical debt as an abstract label rather than a tangible liability. My goal is to shift that mindset. To show that documenting debt is only the first step. Actual progress occurs when teams develop habits to manage, track, and ultimately pay down debt before it compounds into a crisis.

Can you give a quick example of a metric or scoring system you've used to measure technical debt effectively?
A solid starting point is the Technical Debt Ratio, the classic measure of how much effort it would take to fix issues versus the effort required to build the system. It gives teams a macro-level view of debt accumulation. But in practice, I found that it didn't always help prioritize what to tackle first.

That's why I developed a complementary metric I'll be covering in the session: the Technical Debt Score. It's a lightweight approach to evaluating debt-related work items one by one, based on factors such as reward, criticality, and complexity. It helps development teams and stakeholders align on what matters most, rather than just staring at a mountain of issues with no clear path forward.

How do you recommend presenting technical debt to non-technical stakeholders in a way that resonates with business goals?
It starts with a financial analogy: I often say, "We can either pay the interest slowly with delayed releases and bugs, or pay down the principal with targeted investment." That framing, risk mitigation, maintainability, and time-to-market tend to align far better with executive priorities than abstract discussions of code quality.

However, to truly make it resonate, I take it a step further. I translate the technical into business impact by telling a focused story. For example, imagine we are carrying technical debt around Single Sign-On (SSO). If our strategy includes targeting more enterprise clients, I'll say: "SSO is one of the top requirements during IT security reviews. Without it, sales cycles stretch out, and we risk losing deals." Suddenly, the debt isn't just about authentication code, it's about revenue friction.

When stakeholders can see how specific tech decisions tie directly to customer pain points or strategic goals, the urgency becomes real. You're no longer just reporting on code quality; you are advocating for business acceleration.

Are there any red flags that indicate when technical debt is reaching a critical level?
Yes, but ideally, you want to catch the warning signs before they go full-blinking red. That is why I emphasize the value of consistent monitoring and reflective checkpoints. If you're regularly reviewing things like velocity trends, code complexity metrics, and qualitative developer feedback, you often see the smoke before the fire.

That said, when you are at the red flag stage, a few signals tend to show up loud and clear:

• Onboarding new developers takes significantly longer than expected.
• Estimations keep slipping, and delivery dates become unpredictable.
• The phrase "we don't touch that part of the code unless we have to" starts making the rounds.
• Product improvements get deferred, not because they're low-value, but because the cost of change is unknown or too risky.

And here's the thing: technical debt rarely explodes overnight. It's a slow leak. Regularly assessing your backlog, running static analysis tools, and allocating sprint time for intentional remediation can help ensure that those red flags never appear in the first place.

What's a small, actionable step a team can take tomorrow to start reducing their existing technical debt?
Start small, but start intentionally. Carve out just one hour per sprint and commit that time to chipping away at technical debt. Maybe it's cleaning up a confusing test, simplifying a gnarly function, or writing documentation for an overlooked module. The key is consistency, not size. Over time, those little acts compound into significant improvements.

But here's the catch: you can't fix what you can't see. In my session, "Technical Debt Is Not Free," I'll walk through practical ways to identify, record, and prioritize technical debt in a way that is meaningful for your team and your business. You will leave with concrete strategies to help make these small steps part of a sustainable, scalable approach.

What resources can attendees use to learn more and prepare for your session?
To build a strong foundation, I recommend reading Martin Fowler's work on technical debt and exploring tools like SonarQube to see how automated analysis can reveal hidden debt. But the real preparation? That's personal.

I would like you to come ready to reflect. What technical debt do you already know about in your systems? What might be lurking beneath the surface? How is that debt impacting your team's velocity, morale, or ability to deliver value?

We'll have a few minutes for audience interaction, so bring your stories -- the battle scars, the trade-offs, the "we'll fix it later" cards that never got prioritized. My goal is to make this session not just informative but collaborative. We'll walk through practical ways to identify, prioritize, and handle technical debt together -- and chances are, your real-world examples will help others in the room.

Note: Those wishing to attend the session can save money by registering early, according to the event's pricing page. "Save $300 when you register by the Aug. 15 Early Bird deadline", said the organizer of the event, which is presented by the parent company of Visual Studio Magazine.