Managing Tech Debt

# Managing Tech Debt - All Guest Insights

*18 guests, 20 mentions*

---

## Adriel Frederick
*Adriel Frederick*

> "The answer was like, Yo, we got to rebuild it. There was no answer where we couldn't have a product like this. We needed some ability to be able to influence prices so that we could actually run an effective marketplace. The current solution didn't work. It wasn't as operationally flexible as we needed it to be."

**Insight:** When a technical solution lacks the operational flexibility required by the business, a full rebuild is often necessary despite the emotional and resource cost.

**Tactical advice:**
- Evaluate if current technical debt is preventing necessary operational control.
- Be willing to admit when a complex algorithmic approach has failed and pivot to a more flexible architecture.

*Timestamp: 00:32:15*


## Austin Hay
*Austin Hay*

> "The job of a marketing technologist is to think often one to two years down the road about what we're going to need to solve for and design systems in an elegant way, not to break the bank, but to at least be the minimum viable product to actually get there. And a lot of my job, and I think the job of marketing technologists is trying to preserve that future state in the most minimally invasive engineering and resource way possible."

**Insight:** Preventing future technical debt requires architecting systems that are 'minimally invasive' today but scalable for needs 1-2 years out.

**Tactical advice:**
- When setting up tools, ask: 'What happens a year from now if I don't change anything?'
- Implement foundational elements like SSO or proper data schemas early to avoid catastrophic migrations later.

*Timestamp: 00:50:07*


## Camille Fournier
*Camille Fournier*

> "Engineers notoriously, notoriously, notoriously, massively underestimate the migration time for old system to new system and that causes a lot of problems. By the way, you still have to support the old system while you're working on the new system."

**Insight:** Full system rewrites are often traps because teams underestimate migration time and the burden of supporting two systems simultaneously.

**Tactical advice:**
- Account for significant migration time when planning system updates
- Plan for the resource cost of supporting the legacy system during a transition

*Timestamp: 00:16:24*

---

> "Take pieces potentially of the old system, uplift them, make them more scalable, make them easier to work with, clean up the tech debt, but trying to say we're going to just go away. We're going to rewrite, we're going to build something brand new and it's going to solve all our problems, it just very rarely works."

**Insight:** Incremental evolution and targeted tech debt cleanup are more successful than 'big bang' rewrites.

**Tactical advice:**
- Uplift specific APIs or components rather than the whole framework
- Create a staged plan for system evolution

*Timestamp: 00:19:14*


## Casey Winters
*Casey Winters*

> "The idea is that some of the most impactful projects that product teams can work on at scale... are the hardest to measure. And because of that, they just get chronically underfunded... I walk through some examples of a few tactics that work to get around this problem, building custom metrics to show the value, being able to run small tests that prove the worthwhile-ness of the investment."

**Insight:** Securing investment for non-sexy technical improvements requires quantifying their value through custom metrics and small-scale experiments.

**Tactical advice:**
- Build custom metrics to demonstrate the business value of performance or stability
- Run small tests to prove that technical investments will yield long-term results
- Align with engineering and design peers to present a unified front for technical investments

*Timestamp: 24:49*


## Dylan Field
*Dylan Field 2.0*

> "You always have to keep in mind tech debt and there might be, when you're moving slow, systematic reasons for that