Technical Debt Has Interest Rates

Every team I've ever worked with has a pile of technical debt, and every team describes it the same way: like it's one thing. One big gray blob labeled "the stuff we should have done better."

It's not one thing. Technical debt has interest rates, and the rates are wildly different depending on what you borrowed against.

Some debt is a mortgage. You took it on deliberately, you know the monthly payment, and it's attached to an asset that's appreciating. The quick-and-dirty integration you shipped to land the enterprise customer? Mortgage. You'll pay it down on a schedule, and it bought you something real.

Some debt is a car loan. Depreciating, annoying, but manageable. The hand-rolled deployment script that only one person understands. It costs you a little every month in toil and anxiety, but it doesn't threaten the business.

And some debt is a payday loan. It compounds while you sleep, and by the time you notice the rate, you're working for the debt instead of the other way around. The authentication library pinned three major versions behind because upgrading it breaks everything. The database schema that makes every new feature take twice as long. The shared service with no owner that five teams depend on.

Here's the thing about payday-loan debt: the interest doesn't show up as a line item. It shows up as velocity decay. Features that used to take a week now take a month, and nobody can point to why. Engineers start padding estimates. The good ones leave, because they can feel the building rotting around them even if management can't see it.

So how do you tell which kind you're holding? I've got three questions I ask.

First: does this debt slow down *every* future change, or just some? A messy module that one team touches twice a year is a car loan. A tangled core that every feature has to route through is a payday loan. Compound interest applies to the critical path.

Second: does the debt block security work? This is the one that keeps me up at night. If you can't patch a vulnerability in under a week because the upgrade path is broken, your interest rate just became a breach waiting to happen. Debt that degrades your security posture isn't technical debt anymore. It's unpriced risk, and the market always collects.

Third: who owns paying it down, and when? Debt with an owner and a date is a mortgage. Debt with no owner and no date is a payday loan, full stop. "We'll fix it when we have time" is how you say "never" with extra syllables.

The uncomfortable truth is that most organizations are excellent at taking on debt and terrible at pricing it. Leadership sees the feature ship; they don't see the 40% tax on every subsequent sprint. And engineers, bless us, are complicit — we warn about the debt in the abstract and then quietly work around it instead of putting a number on it.

So put a number on it. Not a story-points-are-made-up number. A real one: this module costs us roughly two engineer-weeks per quarter in workarounds. This upgrade path means a critical patch takes nine days instead of one. Translate the debt into time and risk, because that's the language budgets understand.

And then refinance the payday loans first. Not all of them — you can't pay down everything, and trying will just stall the roadmap. But find the one piece of debt that taxes every future decision and kill it. The relief is immediate. Teams can feel the difference within a sprint, and suddenly the next piece of debt looks payable too.

Debt isn't the enemy. Unpriced debt is.

The interest is always compounding. The only question is whether you're the one collecting.

Pricing Is a Promise: Honest Signals in a Discount Season

Written by Alanna Gray, 2025

December is the loudest month in business. Every inbox fills with countdown timers and “almost gone” banners, every storefront promises the biggest sale of the year, and the pressure on a small operator to shout along is real. I run short-term rentals in Atlanta, and I feel it too — the empty weeknight on the calendar starts whispering that a fake “40% off, today only!” banner would fix it.

I don’t run that banner. Not because discounts are wrong, but because a price is a promise, and a demand signal is a statement of fact. The moment either one stops being true, you’re not marketing anymore. You’re just hoping nobody checks.

Scarcity you invent is a lie with a deadline

“Only 2 left!” is a claim about the world. If there are actually nine left, the claim is false, and it doesn’t become true because everyone else is doing it. In my old life as an internal auditor, we had a simple test for numbers we put in front of people: could you show your work if someone asked? A price should pass the same test. If a guest asked why this week costs what it costs, I should be able to answer in one honest sentence.

There is real scarcity in hospitality — a calendar date genuinely is one of one. When it’s booked, it’s gone. That makes honest scarcity more valuable, not less: when I say a weekend is sold out, it is sold out, and guests who’ve been told the truth before believe me. The operators who cry “almost gone” all month train their customers to ignore every signal they send, including the true ones.

Say the seasonal part out loud

Holiday weeks cost more in my business. Christmas week in Atlanta, a big game weekend, a festival — demand is real, and pretending otherwise helps nobody. What I won’t do is bury that in a mystery “fee” at checkout or dress it up as a discount off a price nobody ever paid.

The honest version is a sentence: rates are higher this week because the whole city is full, and they’re lower in mid-January because it isn’t. Guests understand seasons. Farmers’ markets have run on this logic forever — nobody feels cheated that peaches cost more in June than peach-flavored anything does in February. What people resent is discovering the rules were hidden. Transparent seasonal pricing turns a potential complaint into plain information, shared before money changes hands.

A real offer has a real end

Discounts themselves aren’t the problem. I run offers — a quieter-week rate, a thank-you for a returning guest. But a real offer has three things the seasonal noise usually lacks: a real starting price it comes down from, a real reason, and a real end date that I honor. When the date passes, the offer ends. If I quietly extend every “final day” sale into next month, I’ve taught everyone that my deadlines are theater — and a customer who learns that lesson applies it to everything else I say, including the checkout instructions and the house rules.

Hold quality when the race goes down

December also brings the temptation to cut quietly: thinner cleaning between stays, slower replies, the small services dropped because the margin feels tight. That’s the discount nobody advertises, and it’s the one guests actually remember. An auditor learns to watch what an organization does under pressure, because pressure reveals the real controls. A small business is the same. The season when it’s hardest to hold the standard is exactly the season that decides whether people come back in the quiet months — and whether they tell their friends.

What an honest operator can do this season

None of this requires a marketing department. It’s a handful of practices, most of them one-time decisions:

• Audit your own signals. Read every word your listings, site, and ads say about price and availability. Anything you couldn’t prove with your calendar or your books comes out today.
• Publish your seasons. Name your high-demand periods and say plainly that rates rise then — and when they fall. One honest paragraph replaces a year of suspicion.
• Give every offer an end date, then keep it. Put the date in writing, and let it expire even if it stings. The credibility is worth more than the extra bookings.
• Never say “sold out” as a strategy. Say it only when the dates are actually gone. Real scarcity, stated plainly, is the strongest signal a small operator has.
• Cut costs where guests can’t feel it. Renegotiate supplies, tighten your own schedule, fix the leak in your process — not the experience you promised at the price you charged.

December will be loud whether I join in or not. I’d rather be the business whose prices people trust in January, when the shouting stops and the guests who remember being told the truth come back.

Post-Quantum Isn't Coming. It's Here.

For years, post-quantum cryptography lived in the same category as flying cars: technically real, practically distant, something you'd get to eventually. Then last August, NIST published the actual standards — FIPS 203, 204, and 205 — and "eventually" became "now." The math is done. The algorithms have names. The migration clock is running.

And here's what I want everyone to understand: this is not a math problem anymore. It's a program-management problem.

I say this as someone who's spent a career in key management, so I know exactly how unglamorous this sounds. Nobody's giving keynotes about inventory spreadsheets. But the hard part of post-quantum migration was never the algorithms — NIST and a few hundred cryptographers handled that. The hard part is finding every place cryptography lives in your organization and changing it, in the right order, without breaking anything.

Think about what "every place cryptography lives" actually means. It's the TLS libraries, obviously. But it's also the VPN concentrators, the code-signing infrastructure, the HSMs and whether their firmware supports the new algorithms, the IoT devices with crypto baked into silicon that can't be updated, the third-party SaaS vendor who handles your data and hasn't published a migration plan, the backups encrypted with algorithms you're about to retire, the certificates with ten-year lifetimes issued back when ten years felt safe.

Nobody has a complete list. I'd bet money on it. Most organizations can't fully inventory their current crypto usage, and now they need to migrate all of it. Discovery alone is a multi-quarter program for any company of size.

Then there's the sequencing problem, which is where it gets genuinely tricky. You can't just flip a switch. The new algorithms have different performance characteristics — bigger keys, bigger signatures, more computation. That matters for constrained devices, for high-throughput TLS terminators, for anything where latency is measured in microseconds. Hybrid approaches — running classical and post-quantum together during transition — are the sane path, and they're also twice the operational complexity.

And the vendors. Everyone's waiting on everyone else. Your HSM vendor is waiting on firmware validation. Your cloud provider has a roadmap but the dates are soft. Your auditors haven't decided what "compliant" means yet. Coordinating a migration across a supply chain where every link moves at a different speed is pure program management — dependencies, critical paths, escalation, the works.

The quiet urgency behind all of this has a name: harvest now, decrypt later. Adversaries are collecting encrypted traffic today on the assumption that they'll decrypt it once quantum computers mature. If your data has a secrecy lifetime longer than the migration timeline — and for a lot of regulated data, it does — then the window that matters isn't "when quantum computers arrive." It's already open.

So what should you actually do? Start with inventory. Not a pilot, not a working group to discuss forming a working group — an inventory. Where does crypto live in your environment? What algorithms, what key lengths, what lifetimes? You can't migrate what you can't see, and most organizations are about to discover they're blinder than they thought.

Then prioritize by data lifetime and exposure. The stuff facing the internet, protecting long-lived secrets, goes first. The internal system with a three-year refresh cycle can wait its turn.

And staff it like the program it is. This needs someone running it full-time — tracking vendors, sequencing migrations, managing the hybrid period, reporting to leadership in terms of risk reduced rather than algorithms deployed. The cryptographers did their part. Now it's our turn.

The quantum apocalypse isn't coming. It's a migration project. And migration projects are won by people with spreadsheets, not people with whiteboards.