Optimizing Your "20% Time for Technical Debt"
How to Avoid Common Mistakes and Misconceptions
The reality of many startups, including those I have worked for, often starts like this:
A founder has a product hypothesis. The idea needs to be developed quickly to validate it with the market to see if it solves their problem and if they are willing to pay for the service.
Finding product-market fit and problem-solution fit can be a chaotic battle. The founding team has a limited budget and time to achieve this. There can be multiple iterations or pivots from the original idea. There is little time to deliberate on design patterns, frameworks, or software architecture. The team is small, and their focus is diluted across countless tasks. They pick what works for them, "here and now."
Fast forward to the future. Hopefully, everything went well, the company gained traction, the user base is growing, tech complexity is increasing, and now it's time to pay down some debts.
One of these is technical debt, ensuring that your tech stack not only serves customers well but also can be developed quickly and maintained without much hassle.
Here, you can find a PDF cheat sheet summarizing this article.
The Company’s 20% Capacity Goes to Tech Debt and Maintenance
A recommended practice for high-performing tech organizations is to dedicate 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.
Indeed, engineers cannot only build product features. Their code must be constantly optimized, cleaned up, and updated. The tech stack must be reliable as defined by SLIs/SLOs/SLAs and meet Non-Functional Requirements. Development processes must be automated as much as possible to guarantee a working product here and now, and continuity in its further development.
Fortunately, many organizations today understand that they must proactively pay down technical debt. Otherwise, organizational entropy will eventually make systems fragile and halt 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.
To avoid such situations, CEOs and CTOs worldwide set the rule: 20% of time goes to tech, so everyone can sleep peacefully.
Not necessarily.
Traps and Mistakes to Avoid When Setting Your 20% Capacity Rule
To be clear, I am supportive of this rule. Such investment brings much 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).
However, I have fallen into a few traps in the past, and I want to help you avoid them.
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).
Fixing bugs goes to the tech backlog; improving automations goes to the tech backlog; updating libraries and patching security issues goes to the tech backlog.
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
Your job is to ensure this value is known by the product organization and is prioritized accordingly, next to product feature work. You can use a PR/FAQ document as an exercise to help define such value. If you cannot name it clearly, this technical work may not be done at all.
If you end up with two separate buckets – product backlog and tech backlog – focus on this: Every item on that list should have a clearly defined business or product 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.
The Company Doesn’t Understand the Value of Your Work
In addition to the previous point, 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 “more interesting” 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.
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, bug fixes and others.
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.
Fortunately, our goals were visualized, measured, and discussed weekly. Through feedback sessions, the team made it clear that they were too distracted, and it was nearly impossible to progress when everyone was chasing different goals.
What to Do
Similarly to product strategies or roadmaps, you must build one for technology. It’s easy to jump into random initiatives, but your focus will become too diluted without a good plan.
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.
"We’ll Fix It Later"
Out of all the misconceptions, 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.
Side note: The cost of fixing bugs grows exponentially the longer they remain undetected. I covered it here: Do You Need More Testers or Better Tests?
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 few 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.
What to Do with 20% of Capacity for Tech Debt?
This article may sound a bit pessimistic about dedicating extra time to tech initiatives. I’m far from rejecting this 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:
Always serve your customers and make your organization more successful. 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, 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.
Final Thoughts on 20% for Tech
I’m a practitioner of DevOps culture and Shift-Left practices. Having a dedicated day for tech-only work is a great starter, but my ultimate approach (not always reachable) goes like this:
Rather than a separate backlog or dedicated days, add 20% of extra time to every single product initiative. Each task should contribute to your tech KPIs and meet all NFRs. Use the Scout Rule and leave your code better than you found it.
If things cannot be addressed with the systematic Scout Rule, rather than bending over backward to make the impossible possible, make your tech work a product work. Software architecture, replatforming, CI/CD processes, scalability, and other technicalities are strategic for your product and the business. Provide enough context so they can be prioritized along with other product initiatives.
What do you think about it? Does your organization have a “20% of capacity for tech” equivalent? If so, how do you approach it? Does it work for you? I would love to hear your thoughts and learn about your experiences.