Technical debt is not a thing
So, in order to strategize – to decide what work to do in what order – we need to estimate, at the very least:
t: The amount of value that will be created by doing a given task
P: The amount of labor required to do the task
“Spend at least 20% of our time paying down tech debt” is not a principle. It’s an excuse to substitute our arbitrary personal taste for a realistic, evidence-based appraisal of cost and value.
I like the push to actually quantify tech debt and its repayment. 20% feels like a way to avoid thinking critically about the time investment.
“Technical debt” is just what we call it when the deferred value takes the form of a decrease in our team’s velocity.
There’s more to tech debt than just reduced productivity. There’s impact on users, such as due to inconsistent or slow functionality. There’s impact on the business due to higher security risk or breached SLAs because time-to-resolution is longer. There’s morale impact to employees, which reduces retention, etc. etc.
One way is to adopt the simple model of a time horizon. Suppose a team declares the following as their goal:
To produce the most value possible over the coming year.
This team has a time horizon of 1 year. So, when there comes a proposal to make a particular improvement to their productivity (be it a process fix or some automation or whatever else), they can estimate:
How many hours of labor it will take to implement
How many weeks it will take to complete that labor
How many hours of labor it will save them over the year (the remainder of the year, that is, after subtracting the weeks spent implementing)
In this way, productivity investments can be evaluated each on their own merit, rather than being lumped together into the “technical debt” pile.
While it’s useful to always have a time horizon in mind for any work, I don’t think this would actually solve any of the problems the author lists here. Whether the time horizon is a quarter, a year, or five years, direct work is likely to squeeze out all the indirect work, especially if they’re compared as equals. As flawed as 20% rule is at least it acts as a sort of “protection” against feature work completely consuming all the planned time.