First of all, misleading title? It says that tech debt must be treated as regular business tasks when needed, not denies its existence.

> Throughout my career, I’ve been an engineer complaining about tech debt, a manager prioritizing (and deprioritizing) addressing tech debt, and a product manager, where I assume I primarily inspire the creation of new tech debt.

It takes staying on a codebase that has been mismanaged for 5-7 years to know from experience what tech debt really does. Author's CV doesn't show that: he's been 1st employee of a startup, 2nd employee, a PM, and intern i.e. most of the time it was something made from scratch and lasted 1-3 years. That's not enough to see an old project rot. In fact, my first thought while reading was "This post was written by a manager", and yup, by a PM.

> Sometimes people want to schedule tech debt in, saying things like “20% of each sprint should be dedicated to tech debt” or allocating a debt fix-it week

The reason is that the industry is full of managers who ignore tech debt entirely and will prioritize it never. All over the place there people who have never seen the tech but will micromanage engineers, preventing doing anything without immediate "customer impact" or "profit impact". It is unfortunately common for a manager to come in, mismanage for 1-2 years, reap rewards for "quick delivery", and leave without seeing damage ripples starting 3-5 years later. Businesses have virtually no measures to prevent this.

Allocating fixed 10-20% is a consensus that protects the team from manager changes. You may understand why something is a systemic problem that has long-term or unpredictable damage, but the next guy doesn't have to. If this was a standard practice which managers don't dare challenge, like code reviews, software engineering would be relieved from proudly incompetent "business focused" managers who run projects downhill. It is either this, or the other popular alternative of working without a manager (search it, there is a lot of advocacy for that).

Just like code reviews are safely net against potential crazy changes esp. from newcomers, fixed time could be a safety net against short-sighted management.

> Don’t treat tech debt as separate from feature work

We understand that, we're actually already at the next step: how do we as engineers operate in environment, where too many managers can't understand why tech debt should have same priority as feature work.

Tech debt is a useful fiction - but getting to the author's point, what's important for me to track as tech debt won't be important to you. We'll also have different capacities and priorities for managing that debt. Any one-size-fits-all approach is inappropriate.