Technical Debt: Why Your Product Keeps Getting Slower
Learn what technical debt really means and how to fix it without drowning in jargon.
Prerequisites
- • Basic understanding of how software teams work
- • Experience working with developers
When familiar development work starts taking longer, review where the team is losing time.
How technical debt affects delivery
Recurring bugs, changes that break other parts of the product, and increasingly difficult maintenance can slow a team down. Investigate the affected areas and estimate the time spent on them before deciding what to fix.
What Is Technical Debt? (Simple Version)
Technical debt is work left by implementation choices or accumulated problems that makes later changes harder. The cost appears in extra maintenance, repeated fixes, and time spent working around those choices.
Two ways debt can accumulate
1. Deliberate shortcuts The team accepts an implementation trade-off to ship sooner, knowing it may need more work later.
Examples:
- Hard-coded prices instead of a pricing system
- Copy-pasted code instead of reusable components
- Manual processes instead of automation
2. Accumulated complexity Problems can build up over time without one deliberate decision causing them.
Examples:
- Old code that nobody understands anymore
- Different coding styles mixed together
- Outdated tools that need upgrading
Investigate how much either type affects delivery before deciding whether to repair it.
Identify what is slowing the team down
Signs to investigate
- Comparable features take twice as long as before
- Bugs return in the same area
- Developers report that another fix is needed before they can proceed
- Small changes require touching many files
- New team members struggle to understand the code
Other possible causes
- A feature is more complex than previous work
- The team is learning a new technology
- Fewer people are available
- Requirements keep changing
Check these explanations before attributing the slowdown to technical debt.
Ask your team what slows them down most. Repeated mentions of the same area give you a place to investigate; they do not establish the cause on their own.
Estimate the cost
Cost estimate
Weekly cost = Hours lost per developer per week × Team size × Hourly rate Annual cost = Weekly cost × 50 weeks
The example below assumes $100 per hour and 50 working weeks. Replace both assumptions with figures appropriate to your team.
Example calculation
Suppose a team of 5 developers each loses 8 hours per week to maintenance problems. At the assumed rate of $100 per hour:
- Hours lost: 8 hours × 5 people = 40 hours/week
- Weekly cost: 40 × $100 = $4,000
- Annual cost: $4,000 × 50 = $200,000/year
Try This Calculator
Review your team’s delivery trend:
Label estimates and assumptions. This measures the cost of time consumed, not necessarily cash the business will save after a repair.
Prioritize repairs
Use this 2×2 grid to compare urgency and effort:
Your Technical Debt Priority Grid
| Easy to Fix | Hard to Fix | |
|---|---|---|
| Urgent (Blocks work daily) | Do Now | Plan Next |
| Not Urgent (Annoying but manageable) | Do During Downtime | Maybe Later |
Examples:
- Do Now: Slow test suite that runs 20 times/day
- Plan Next: Database that will hit limits in 3 months
- Do During Downtime: Messy code that works but is hard to read
- Maybe Later: Old framework that still works fine
Review urgent, easy fixes first, while checking whether a harder repair is needed to unblock other work.
Illustrative examples
The following scenarios are hypothetical. Their figures illustrate how to describe a problem, its impact, and a repair; they are not reported company results.
Example 1: The E-commerce Site That Got Slower
Problem: Page load went from 2 seconds to 10 seconds over a year.
Why: Quick fixes piled up. Nobody cleaned old code. Database queries multiplied.
Cost: 40% of visitors left. Lost $50,000/month in sales.
Fix: Two developers spent 1 week optimizing. Load time dropped to 3 seconds.
Lesson: Where accumulated implementation problems cause a slowdown, estimate both maintenance costs and user impact.
Example 2: The Mobile App With Bad Reviews
Problem: App crashes increased from 1% to 5% of sessions.
Why: Old error handling code. Never updated for new features.
Cost: Rating dropped from 4.5 to 2.8 stars. Downloads fell 60%.
Fix: One developer fixed error handling in 3 days.
Lesson: Include effects on users when estimating the cost of a recurring bug.
Example 3: The Feature That Takes Forever
Problem: Adding a simple form field takes 3 weeks.
Why: Form code scattered across 15 files. No documentation.
Cost: Competitors launched 5 features while you built one.
Fix: Restructured form system over 2 sprints. New features now take 2 days.
Lesson: Compare the time needed for similar changes before and after a repair.
Your First Month Action Plan
Use this month-long plan to investigate one problem and begin a repair.
Week 1: Ask the Right Questions
Schedule 30 minutes with each developer. Ask:
- "What slows you down most?"
- "How many hours per week do you lose to this?"
- "What would it take to fix it?"
Write down everything. Look for patterns.
Week 2: Calculate the Cost
Use the simple formula:
- Add up hours lost from Week 1 interviews
- Multiply by $100/hour (or your team's rate)
- Calculate weekly and annual cost
You now have a number to share.
Week 3: Pick One Win
From your Week 1 list:
- Find something in the "Urgent + Easy" quadrant
- Get agreement from the team
- Estimate the fix time with the developers
- Calculate the payback period
Week 4: Get Buy-In and Start
Present to your boss (see scripts below). Start fixing your first item. Track the improvement.
Scripts for Talking to Your Boss
These scripts use illustrative numbers. Replace them with your observations and label forecasts as estimates before sharing them.
Script 1: The Cost Conversation
"I discovered our team loses 40 hours per week to technical problems. That's $4,000 per week or $200,000 over 50 working weeks. I'd like to fix the top issue which will take 3 days and save us 10 hours per week."
Script 2: The Speed Conversation
"Our feature delivery has slowed by 40% in the last 6 months. The main cause is [specific problem]. We estimate a 1-week fix and will compare delivery time afterward to see how much it improves."
Script 3: The Risk Conversation
"We have a growing problem with [issue]. If we don't fix it, we'll likely see [specific bad outcome]. The team estimates X days for the fix now. We should assess how delaying it changes the effort and risk."
Script 4: The Customer Impact
"Our support tickets about [problem] have tripled. Each ticket costs $50 to handle. We estimate a 5-day fix and an 80% reduction in these tickets; we will measure the result after release."
Common Mistakes to Avoid
Mistake 1: Trying to Fix Everything
Problem: You make a list of 50 problems. Fix: Pick ONE. Fix it completely. Then pick another.
Mistake 2: Not Tracking Improvement
Problem: You fix things but can't prove impact. Fix: Measure one metric before and after (speed, bugs, or hours).
Mistake 3: Going It Alone
Problem: You decide what to fix without the team. Fix: Always ask developers what hurts most. They know.
Mistake 4: Waiting for the Perfect Time
Problem: "We'll fix it after this launch." Fix: Reserve capacity for repairs and review whether the allocation matches the problems.
Mistake 5: Using Too Much Jargon
Problem: You say "refactoring the middleware layer." Fix: Say "fixing the thing that makes checkout slow."
An illustrative 70/20/10 allocation
One starting point for discussion is:
- 70% New Features: Keep shipping value
- 20% Fix Technical Debt: Steady improvement
- 10% Innovation: Try new things
A temporary 50/40/10 split gives repairs more capacity. Neither split is a universal rule. Agree on the allocation using the urgency, expected benefit, and effort of the work, then review the results.
Creating Your Ongoing Process
Every Week
- Ask in standups: "What slowed you down?"
- Track hours lost in a simple spreadsheet
- Celebrate when something gets fixed
Every Sprint
- Reserve the agreed capacity for debt fixes
- Pick from your priority matrix
- Share improvements with stakeholders
Every Quarter
- Review your technical debt list
- Calculate total cost saved
- Adjust your 70/20/10 split if needed
Quick Wins to Start With
Check whether these problems affect your team and estimate the effort before treating them as quick fixes:
- Slow Tests: Tests taking >10 minutes may interrupt work; measure how often developers wait for them
- Broken Development Setup: New developers taking days to start coding
- Manual Deployments: If releasing takes hours of manual work
- Missing Documentation: When everyone asks the same questions
- Flaky Tests: Tests that fail randomly waste debugging time
Choose one based on impact and effort, and agree on a repair plan.
Try This First
Today (15 minutes): Ask one developer "What's the most annoying thing you deal with daily?"
Tomorrow (30 minutes): Calculate how many hours that thing wastes per week.
This Week (1 hour): List your top 5 problems and put them in the 2×2 matrix.
This Sprint: Fix one thing from the "Urgent + Easy" quadrant.
Next Steps
- Use our Velocity Calculator to track improvement
- Try the Impact/Effort Matrix to prioritize
- Read How to Track Team Velocity