"20% for tech debt" doesn't work
5 traps will stop your technical vision from happening
Most startups start like this:
A founder has a product hypothesis. The idea needs to be developed quickly to validate it with the market to get some feedback.
The founding team has a limited budget and usually goes through multiple iterations or pivots. There is no time to deliberate on design patterns, frameworks, or software architecture. They pick what works for them, "here and now."
Fast forward a year - everything goes well:
The company gained traction
The user base is growing
Additional engineers are hired.
Now, the problems start to appear…
The tech complexity is increasing, and the new hires are not happy with the state of the codebase.
Engineers can’t just build one product feature after another. The code must be constantly optimized, cleaned up, and updated. Development processes must be automated as much as possible to guarantee a working product here and now.
Otherwise, organizational entropy will eventually make systems fragile and stop the entire delivery process. A great example of this is LinkedIn's Operation InVersion, where LinkedIn halted development for two months to fix all its issues.
It’s time to address the technical debt!
Today we have a special guest -
, author of . As the name promises - it’s the absolute best newsletter for getting practical advice! I highly enjoy the (free!) weekly deep dives, and I learned a lot from Mirek in the last couple of months.Here you can find a PDF cheat sheet summarizing this article.
The company goes for the ‘20%-tech-debt’ rule
Back to our story.
The young CTO reads a bit online about recommended ways to tackle it, and stumbles upon the practice of dedicating 20% of capacity to purely engineering work. Here’s what Marty Cagan says (author of "Inspired," "Empowered," and "Transformed," as well as head of Silicon Valley Product Group):
Product management takes 20% of the capacity right off the top and gives this to engineering to spend as they see fit – they might use it to rewrite, rearchitect, or refactor problematic parts of the codebase, or to swap out database systems, improve system performance.
This definitely helps. Setting aside time to address the tech debt will bring a ton of value to the tech stack and product (better stability, performance, quality, etc.) as well as the organization and its culture (increased morale, trust, and decisiveness).
Unfortunately, it’s not so simple.
5 dangerous traps when working with the ‘20%-tech-debt’ rule
1. Separate Backlogs for Product and Tech
Everyone’s happy with a new change.
Engineers are happy that the Product team doesn’t interfere in their technical work. The Product team is glad they don’t have to deal with technicalities and can focus on defining features.
But the reality is different. Product and technology are not separate things. The product must drive the technology, and the technology must enable the product (read more: The Role of Engineering In Organization).
In the new setup:
Fixing bugs goes to the tech backlog;
Improving automations goes to the tech backlog;
Updating libraries and patching security issues go to the tech backlog.
But you cannot let everything tech-related land in a separate technical backlog. Almost each of these initiatives has some value for customers or the organization. They improve reliability, security, speed of delivery, and more.
What to Do
If you end up with two buckets – product backlog and tech backlog – focus on this: Every item on the technical list should have a clearly defined business value. Once it does, it should be moved to the product backlog, where it gets prioritized along with other product tasks.
Be pragmatic. 20% dedicated to tech work is 1/5 of the entire product capacity. This means you should reserve that only for critical activities that are too hard to explain to non-tech stakeholders.
You can use a PR/FAQ document as an exercise to help define such value. If you cannot name it clearly, maybe it’s not worth pursuing?
2. The Company Doesn’t Understand the Value of Your Work
Let’s talk about the value of our technical work.
Don’t confuse 20% of capacity for tech debt with Google’s famous “20% time,” where employees could focus on side projects unrelated to their jobs. Most likely, you are expected to utilize your 1/5 of the week on initiatives that directly impact the product or company’s value.
It can be dangerous if a business or product doesn’t interfere with tech work. If they don’t care or don’t understand why you do what you do, your initiatives will always be the first to be deprioritized when there are “urgent” things to do.
If the value of your work is unknown, it’s also much more challenging to negotiate additional investments like hiring, training, more time, etc.
What to Do
In one of my previous companies, we had monthly review meetings where product teams presented the progress of their work. In addition, representatives of engineering groups showed the progress of technical initiatives not connected to any particular team.
Initiatives like Core Web Vitals improvements, migration to cloud services, framework updates, and rewriting to different languages were presented publicly to make everyone understand why we do them.
One example was migrating the mobile app from Objective-C to Swift. Without an explanation, such a project can be seen as the engineering team playing with shiny new technology.
We clarified that this initiative would improve compilation time (time to market, developer experience) and help with hiring (at that time, Objective-C engineers became significantly more expensive, and many Swift engineers declared they didn’t want to deal with Objective-C code).
Constant reminders of the value of technical work will make the organization support you with these initiatives rather than seeing them as a necessary evil.
3. Diluted Focus
Once you get “20% for tech”, you might think it'll solve all your problems. At least, this was my inner optimist telling me that. So you jump into library updates, optimizations for CI/CD pipelines, some refactoring, and bug fixes.
Soon, you realize you have made no progress anywhere.
This was my personal experience, where as a leader, I assigned separate tech initiatives to every single person on my teams. These tasks or areas to improve had very little in common, causing everyone to go in different directions.
What to Do
Building a long-term engineering strategy was a true game-changer for me. Once we had this picture, deciding on our goals, default behaviors, and which initiatives to focus on was much easier.
Remember the 1st trap - most of the tech-debt efforts should be in the product roadmap!
4. "We’ll Fix It Later"
This one is probably the most dangerous. Once your organization dedicates 20% of its capacity to tech maintenance, it becomes tempting to push things to customers even faster, assuming you will fix everything later.
You will not.
Dedicated time for tech is to make things better, not just less bad. Even when you build an MVP, it must be functional, usable, and reliable (I wrote about it here: MVP, PoC, Prototype).
One example I’ve observed (too often!) is writing tests post-release: “Once we push it to customers, we’ll have a week or two to write all the missing checks.” In most cases, such tasks in your backlog are never touched because you either must fix all production issues or jump into a new initiative that is always more important than two weeks dedicated to writing unit tests.
What to Do
Whether you build an MVP or another product iteration, you should always meet some baseline defined by Non-Functional Requirements or your SLIs/SLOs/SLAs.
Your 20% of capacity is intended to achieve some strategic tech goals rather than fixing issues you made intentionally.
5. Ineffectiveness
20% of capacity for tech initiatives is not that much. It’s one day a week, 1.5 hours a day, or ~4-5 days a month. Even if you strictly keep the rule of having a dedicated day for tech maintenance, big initiatives can take months, if not years.
Let’s say you have a significant initiative to break down a monolithic system. You roughly estimate it will take 2-3 months of work (40-60 working days). Working on this in your single “tech debt day” will take you a year.
I haven’t even mentioned how hard it is to return to the context of such work if you focus on it only one day a week or how difficult it is to do something meaningful within a single hour a day.
What to Do
This ties back to some of the previous points. First, strategic initiatives, like re-platforming or rearchitecting, should become product priorities. Their value must be known, and they should get support from the entire organization rather than being addressed when no one is watching.
Such initiatives also must have a good plan. Maybe they can be broken down into smaller steps and translated into tech goals/KPIs or Non-Functional Requirements. In such a case, there must be a good way of tracking them so you, your team, and stakeholders from the rest of the organization can review them regularly and adjust company priorities accordingly.
Final Thoughts on 20% for Tech
While the article may sound a bit pessimistic about dedicating extra time to tech initiatives, I believe it’s a good idea.
Thanks to this approach, many teams I worked with achieved great things like migrating to different languages, moving on-prem solutions to the cloud, reducing errors and bugs by the order of magnitude, and introducing excellent standards for quality, reliability, and performance.
But you cannot approach this in an unstructured way. Here are some recommendations to help you maximize the value of your "20% for tech" and avoid common traps in this concept:
The role of engineering is to solve customer problems. See how your tech initiatives make your product more reliable, useful, and frictionless. If not for customers, try to correlate your activities with one of the four factors essential to the success of any organization: growth, profitability, expansion, and customer satisfaction.
Translate technical work into product value. Make sure the job is understandable to non-tech stakeholders. Use the PR/FAQ document as an exercise to unveil the meaning of your initiatives. The engineering Leader’s role is to ensure that the product drives technology and technology enables the product.
Structure your technical needs. Use frameworks like Ten Types of Technical Debt, the DevOps Culture Checklist, or Ten Types of Software Engineering Waste to classify tech debt, making it easier to prioritize and explain to stakeholders.
Build an engineering strategy so each initiative contributes to long-term plans. Use the Engineering Strategy Framework to structure this. For more inspiration, look at the examples of Strategic Blocks.
Set goals, measure progress, and discuss insights with the team. Build the simplest data dashboards and review them weekly or monthly to ensure you’re moving in the right direction. Take inspiration from Practical solutions to track your goals.
Use Non-Functional Requirements or SLI/SLO/SLA in your product work. Rather than using your “20% for tech” to fix things later, ensure high standards from the beginning so your tech initiatives make things better, not just less bad.
There are no exceptions for MVPs. A Minimal Viable Product is a product that is functional, reliable, and usable. The scope is reduced, but not the quality. I’ll tell it again: “20% for tech” is not to fix your intentional negligence.
 | A guest post by
|
Structuring the technical debt and baking it into the engineering culture so that we don't build half-baked solutions, no matter how simple the requirement, made a big difference in my thinking.
While working solo, when I built a helper library or a tool, I strived to have the least amount of code for the specific scenario I was solving, and I lived by this rule for so long.
While this is not wrong, now I see that the drawback of such simple solutions was a rigid architecture that almost always required a rewrite later.
As for the exact percentage, I don't know. There's a difference between a tech debt such as a long-ish running query or replacing a JS library that we've been dragging for years and has security vulnerabilities. But right now, we dedicate around 20% of our effort to only one of our tech debts. That's an entire rewrite, it doesn't have a separate backlog, and it's part of the sprint planning.
Good presentation of some potential pitfalls of dedicating a % of time for tech debt or other maintenance work. However I disagree with the title, which seems to imply the entire approach doesn't make sense.
A few years ago, before my team started carving out a % of time for maintenance work, there were some tasks that were simply not done because they were too difficult to tie to individual features of interest to the business. For example: annual upgrades of dependencies, security-related infrastructure work, etc. My team is definitely better-off after consistently carving out a % for maintenance tasks that can't be tied to individual features.