What happens when a team dedicates 10% of their time to fixing technical debt?

Introduction: More Than a Mess of Code

Technical debt often evokes feelings of guilt and frustration. It’s what we whisper about during retros, grumble over in PRs, and quietly accept as a side effect of real-world software delivery. But what if we’ve been thinking about it all wrong?

At Zühlke, we believe technical debt isn’t just a technical flaw. It’s a strategic lever — one that impacts velocity, team morale, innovation, and business sustainability. Left unmanaged, it erodes productivity. Handled wisely, it becomes an investment in long-term resilience.

In this article, we explore the dual nature of technical debt — as both a technical concern and a product/business risk — and share how we’ve embedded a best practice of allocating at least 10% of engineering time to reducing it.

What Is Technical Debt, Really?

Coined by Ward Cunningham, technical debt is a metaphor that likens short-term compromises in software quality to financial borrowing. Like real debt, it can accelerate progress — or bankrupt you later.

Types of Technical Debt:

• Design Debt: Inflexible architectures that block evolution.
• Code Debt: Messy or duplicated code that slows developers.
• Documentation Debt: Missing context that hinders onboarding and collaboration.
• Infrastructure Debt: Outdated systems or configurations that increase fragility.
• Process Debt: Inefficient workflows and manual steps that hinder scaling.

These forms of debt arise from tight deadlines, shifting requirements, legacy constraints — or sometimes, simply neglect.

“Tech debt is like a credit card for your codebase. Easy to get into, hard to get out of.” — Juan Jose Behrend

The Business Risk of Ignoring Tech Debt

Technical debt isn’t just an engineering concern—it’s a product and business risk.

• Missed Deadlines: Teams slow down as complexity grows
• Increased Costs: More time is spent maintaining, not innovating
• Talent Retention: Skilled engineers burn out or leave
• Customer Frustration: Bugs, instability, and missing features become common
• Security Gaps: Outdated dependencies and fragile systems increase vulnerability

Ignoring tech debt is like ignoring interest on a loan—it compounds silently, then hits all at once.

Business Impact

When tech debt piles up, it constrains agility and slows time-to-market. Companies may find themselves outpaced by more nimble competitors — not due to inferior ideas, but due to bloated systems.

A study titled "Code Red: The Business Impact of Code Quality" by Adam Tornhill and Markus Borg, analyzed 39 proprietary production codebases and revealed that:

• Low-quality code contains 15 times more defects than high-quality code.
• Resolving issues in low-quality code takes 124% more time.
• Issue resolutions in low-quality code are far less predictable, with 9 times longer maximum cycle times.

This research highlights the tangible cost of technical debt and poor code quality on development speed and predictability.

Cultural Decay

The "broken windows" theory applies to software: once mess is tolerated, care diminishes. This sets off a vicious cycle where the bar for quality drops across the board.

To address these risks effectively, we must first understand how different roles perceive and influence technical debt — because the way people think about tech debt shapes how (or whether) it gets resolved.

How Roles Perceive Technical Debt

Product Owner View

Product Owners (POs) tend to focus less on the technical details and more on delivery, prioritization, and business outcomes. Their questions often revolve around effort, urgency, and trade-offs:

• “How much time will it take to fix?” (Worried about delays.)
• “Is it blocking anything critical?” (Weighing business value.)
• “Can we make it visible and prioritize it properly?” (Seeking transparency.)
• “I don’t care unless it’s causing problems.” (If the impact is hidden, urgency may be low.)

💡 Takeaway: To gain a PO’s support, translate tech debt into business impact — lost velocity, instability, or rising costs.

Lead Architect

Lead Architects see technical debt through a long-term lens. Their concerns are stability, scalability, and sustainability.

• “We need to surface this to the team.” (Creating visibility.)
• “Let’s design it the right way going forward.” (Preventing future debt.)
• “Who wants to collaborate on fixing this?” (Promoting ownership.)
• “I’ll help convince the PO.” (Acting as a bridge between tech and business.)

💡 Takeaway: Great architects don’t just react to debt — they anticipate it, advocate for addressing it, and design to avoid it.

Developer View

From a developer's perspective, technical debt awareness depends on two key factors:

• Experience – More experienced developers recognize tech debt and its consequences.
• Willingness to address it – Some developers raise concerns, while others ignore them due to pressure or lack of motivation.

Since developers often work under tight deadlines, they may take shortcuts that unintentionally introduce technical debt.

⚖️ The Pragmatic Developer (Balances Priorities)

• "This code is messy, but we don’t have time for a full refactor. I’ll leave a TODO and fix it later."
• "I know this is not the best solution, but it works for now."
• "Let’s at least document this workaround so future devs don’t get stuck."
• "We should track this in our backlog, but I doubt it’ll ever get prioritized."

💡 Key Trait: Finds a balance between short-term delivery and long-term maintainability.

😖 The Frustrated Developer (Wants to Fix Tech Debt but Feels Stuck)

• "Why are we still using this outdated framework?"
• "If only we had time, I could clean up this spaghetti code..."
• "I don’t want to touch this module—every change breaks something."
• "Every bug fix here takes forever because of tech debt."

💡 Key Trait: Understands the pain of tech debt but may feel powerless to address it.

🙃 The Careless Developer (Ignores or Contributes to Tech Debt)

• "Let’s just copy-paste this code instead of refactoring."
• "Tests? Who needs them? It works on my machine!" 🚀🔥
• "I’ll just comment this out instead of deleting it."

💡 Key Trait: Prioritizes speed over quality, often leading to long-term problems.

🥳 The Proactive Developer (Reduces Tech Debt Because It’s Fun!)

• "Let’s refactor this while we’re already working in this area."
• "I’ll write a quick test to make sure this doesn’t break later."
• "We should automate this process instead of doing it manually every time."
• "I’ll bring this up in the next sprint planning so we can allocate time to fix it."

Evolution of Technical Debt with Team Growth

As development teams gain experience and a deeper understanding of the system, they often recognize earlier design decisions that may now be seen as suboptimal or limiting. This heightened awareness can lead to the identification of technical debt that wasn't apparent initially. Regularly revisiting and reassessing the codebase allows teams to align the architecture with current best practices and business needs.

A Reframed View: Tech Debt as a Strategic Tool

Not all debt is bad. Strategic technical debt — taken on consciously to validate ideas, meet a critical deadline, or accelerate discovery — can be powerful. The key is intentionality and a plan to pay it back.

“Good tech debt is a deliberate and conscious trade-off… Bad tech debt is borrowing with no way to repay.” — Alex Ewerlöf

We often ask clients to reflect:

• Are we aware of the debt we’re taking on?
• Is it documented and visible?
• Do we have a plan to address it?

A Zühlke Best Practice: The 10% Rule

At Zühlke, we advocate for allocating at least 10% of engineering time to systematically reduce technical debt. This practice isn’t just about cleanup — it’s about:

• Maintaining flow: Unblocking delivery pipelines.
• Building collective code ownership: Developers collaborate, learn, and document.
• Shifting left: Identifying fragility earlier in the lifecycle.
• Preventing new debt: Cleaner codebases lead to better coding habits.

This regular investment creates a flywheel of improvement and the results are stunning:

1. Cleaner Code: Repeated effort made messy areas easier to maintain
2. Faster Delivery: We cleared recurring blockers, which sped up feature work
3. Stronger Teams: Knowledge sharing and collective refactoring boosted morale
4. Preventive Mindset: Engineers started designing with sustainability in mind
5. Managerial Trust: Product owners saw fewer regressions and faster ramp-ups
6. Better Decisions: We became more strategic about “when to take debt”

“It’s not just about fixing old code—it’s about building a foundation for speed.”

Making the Investment Work: Practical Guidance

Here’s how to embed this mindset and practice in your organization:

📌 Track It Transparently

Use labels like tech-debt in your backlog. Make it visible to product owners and leadership. Frame it as risk mitigation and long-term acceleration — not “cleanup.” However, be mindful that such items might be de-prioritized in favor of new features.

🖇️ Tag Refactorings to Features

Associate necessary refactoring efforts directly with feature development. This ensures that addressing technical debt becomes part of the feature implementation process, improving the codebase while delivering new functionalities.

📊 Measuring the Invisible

One challenge with technical debt is that it’s not obvious in Jira or burn-down charts. But it can be tracked with meaningful metrics:

By integrating these strategies, teams can manage technical debt proactively, ensuring it aligns with ongoing development efforts and business objectives.

We recommend adding a tech debt dashboard to your engineering metrics, ideally surfaced in retros or quarterly planning.

🛠 Include in Sprint Planning

Allocate 10% of each sprint for debt reduction. Don’t let it become a stretch goal.

ℹ️: Allocating a portion of each sprint to address technical debt is a widely recognized practice in agile development. This approach ensures that code quality is maintained alongside the delivery of new features. The specific percentage allocated can vary based on the team's needs and project requirements.

📣 Share the Wins

Demo improved test coverage, removed duplication, or better CI pipelines. Celebrate small wins to show value.

🤝 Involve Everyone

Let developers decide what to tackle — from removing dead code to automating painful deployments.

⚖ Prioritize Strategically

Balance high-impact fixes with low-hanging fruit. Use metrics like:

• Code complexity
• Defect density
• Code churn
• Lead time to change

From Tactical Fixes to Strategic Advantage

Technical debt isn’t just a dev team problem. It’s a business enabler when managed — and a growth killer** when ignored.

Reframing technical debt as a shared responsibility leads to:

• More ownership
• Build faster, safer
• Greater agility.
• Healthier engineering culture.
• Stronger alignment between business and tech.

The path to innovation is paved not just with new features, but with sustainable foundations.

Closing Reflection

Managing technical debt isn’t glamorous. But in our experience at Zühlke, it’s one of the clearest indicators of engineering maturity — and one of the most powerful drivers of long-term value.

Don’t wait for the system to rot. Start investing today. Just 10% of time, consistently applied, can change everything.

Want to learn more about our engineering best practices at Zühlke?
We’d love to share how we help clients build resilient, future-ready platforms.

---

Authors: Abishek Anthony, Romano Roth