What it is

Technical debt is the work you skipped to go faster: no tests, a public subnet “for now,” a 32-core VM, a key in a file, a diagram with two arrows. You still have to pay. Later, with interest.

In cloud, debt is extra visible because it bills monthly. An unused environment, an old Lambda, an FTP server someone renamed asynchronous legacy tunneling. The cloud will keep running it until someone turns it off.

Not all debt is stupid. A prototype that is supposed to die is fine. A prototype that became production and kept the scaffolding is how you get the 2am page.

Why it matters in the meeting

When JJ asks why a “simple change” takes three weeks, the answer is often debt, not laziness. The simple change touches the thing nobody wants to restart.

Bart tracks risk. Debt is risk with a friendly name. Calling it debt does not make it a finance problem only. It is an operations problem with a delayed invoice.

Real world

Cloud makes debt easier to open and easier to hide. A second account, a forgotten resource group, a “temporary” public IP. There is no attic. There is a console search you have not run.

The healthy version is a list: what we skipped, why, and when we pay it down. The unhealthy version is folklore. Selena remembers. Dave the cat does not file Jira tickets.

In plain terms

Technical debt is not a personality flaw. It is a loan. Cloud just reports the interest in CAD every month. Name it, cap it, or keep paying the minimum forever.

What to ask

  • What are the top five shortcuts still running in production, named, with an owner?
  • Which unused environments are still billing, and who is allowed to delete them?
  • When did we last restore a backup, rotate a leftover key, or redraw the network?
  • If we spent one sprint only on debt, what would we retire first?

You just knew a little more Jack than you did five minutes ago.

All concepts