Swarupa Mahambrey, Vice President of Software Engineering at The College Board, breaks down what tech debt really looks like in a mission critical environment, and how an engineering mindset can prevent it from quietly choking delivery. She shares a practical operating model for paying down debt without stopping the roadmap, and the cultural habits that make it stick.

You will hear how College Board carved out durable space for engineering excellence, how they use testing and automation to protect reliability at scale, and how to make the trade offs between features, simplicity, and user experience without slowing the team to a crawl.

Key Takeaways

• Tech debt behaves like financial debt, delay the payment and the interest compounds until even simple changes become painful

• A permanent allocation of capacity can work, dedicating 20 percent of every sprint to tech debt can reduce support load and improve delivery

• Shipping more features can slow you down, simplifying workflows and validating with real usage can increase velocity and reduce tickets

• Resilience is not about avoiding every failure, it is about designing for graceful degradation so spikes and outages become small blips instead of crises

• Automation is not “extra,” it is part of the definition of done, including unit tests as acceptance criteria and clear code coverage expectations

Timestamped Highlights

• 00:00 Why tech debt is a mindset problem, not just a backlog problem

• 01:00 Tech debt explained with a real example, what happens when a proof of concept becomes production

• 03:45 The feature trap, how “powerful” workflows can overwhelm users and explode maintenance costs

• 11:03 Engineering Tuesday, one day a week to strengthen foundations, not ship features

• 14:39 Stability vs resilience, designing systems that bend instead of shatter

• 20:06 Testing and automation at scale, unit tests as a requirement and code coverage guardrails

A line worth keeping

“If we don’t intentionally carve out space for engineering excellence, the urgent will always crowd out the important.”

Practical moves you can steal

• Protect a fixed slice of capacity for tech debt, make it part of the operating model, not a one time cleanup

• Treat automation as acceptance criteria, no test, no merge, no release

• Use pilots and targeted releases to learn early, then iterate based on metrics and real user behavior

• Design for graceful degradation with retries, fallback paths, and clear failure visibility

Call to action

If this episode helped you think differently about tech debt and engineering culture, follow The Tech Trek, leave a quick rating, and share it with one engineer who is fighting fires right now.