Why the 70/30 Rule Is Killing Your Engineering Team

Every engineering team faces the tension between shipping new features and maintaining existing code. Too much feature work accumulates technical debt. Too much maintenance slows product growth. This guide shows how to use engineering data to find—and communicate—the right balance.

"The teams that win aren't the ones that ship the most features or the ones with the cleanest code. They're the ones who consciously choose where on the spectrum to be—and adjust as conditions change."

The Hidden Cost of All-Features-No-Maintenance

When teams prioritize features exclusively, several patterns emerge:

• Rising cycle times: Old code becomes harder to change
• Increasing defect rates: Fragile code breaks more often
• Knowledge concentration: Only original authors can safely modify legacy areas
• Developer frustration: Engineers hate working in neglected codebases
• Slowing velocity: Eventually, debt interest exceeds new capacity

The Debt Interest Metaphor

Technical Debt Compound Interest:

Year 1: 100% feature velocity, 0% maintenance
        → Debt accumulates, velocity stays high

Year 2: 85% effective velocity (debt overhead)
        → More workarounds, longer cycle times

Year 3: 65% effective velocity
        → Significant time spent on firefighting

Year 4: 45% effective velocity
        → Most "feature" work is actually fixing old code

The irony: Teams that never do maintenance end up doing
nothing but maintenance-disguised-as-features.

The 70/20/10 Rule (And Why It Often Fails)

You've probably heard the "70/20/10 rule"—allocate 70% to features, 20% to maintenance, and 10% to innovation or experimentation. It's a popular framework because it's simple. But in practice, it fails for several reasons:

Why 70/20/10 Breaks Down

THE DYNAMIC BALANCE FRAMEWORK
═══════════════════════════════════════════════════════════════

Instead of fixed ratios, use context-aware targets:

GROWTH MODE (accelerating)
├── Features:      70-80%
├── Maintenance:   15-25%
├── Innovation:    5-10%
└── When to use:   Pre-product-market fit, rapid scaling

SUSTAINABLE MODE (cruising)
├── Features:      50-60%
├── Maintenance:   25-35%
├── Innovation:    10-15%
└── When to use:   Stable product, steady growth

RECOVERY MODE (paying debt)
├── Features:      30-40%
├── Maintenance:   40-50%
├── Innovation:    10-20%
└── When to use:   After major launch, excessive debt

CRISIS MODE (firefighting)
├── Features:      10-20%
├── Maintenance:   70-80%
├── Innovation:    0-10%
└── When to use:   Critical stability issues

The key: Know which mode you're in and decide intentionally.

"The 70/20/10 rule is like saying 'drive at 65 mph.' It ignores whether you're on a highway, in a school zone, or stuck in traffic. Context matters more than ratios."

How to Calculate Your Current Ratio from Git Data

Most teams have no idea what their actual feature/maintenance split is. They think it's 70/30 when it's actually 45/55. Here's how to measure reality:

Method 1: PR Label Analysis

LABELING TAXONOMY FOR FEATURE/MAINTENANCE TRACKING
═══════════════════════════════════════════════════════════════

Category: FEATURE (Value Creation)
Labels:   feat, feature, enhancement, new-*, add-*
Examples:
  - "feat: Add export to CSV functionality"
  - "Add user dashboard widgets"
  - "enhancement: Improve search performance"

Category: MAINTENANCE (Value Preservation)
Labels:   fix, bug, hotfix, patch, security, deps, chore
Examples:
  - "fix: Resolve timeout in checkout flow"
  - "security: Update vulnerable dependencies"
  - "chore: Migrate to Node 18"

Category: TECH DEBT (Value Investment)
Labels:   refactor, cleanup, debt, improve-*, optimize
Examples:
  - "refactor: Extract payment service"
  - "cleanup: Remove deprecated API endpoints"
  - "optimize: Reduce bundle size by 40%"

Category: INNOVATION (Value Exploration)
Labels:   experiment, spike, research, prototype
Examples:
  - "spike: Test new ML recommendation approach"
  - "prototype: Voice search POC"

Formula:
  Feature %    = (Feature PRs / Total PRs) × 100
  Maintenance % = (Maintenance PRs / Total PRs) × 100
  etc.

Method 2: Git-Native Proxies (No Labels Required)

Don't have consistent labels? You can infer the ratio from Git data patterns:

QUICK RATIO ESTIMATION FROM GIT DATA
═══════════════════════════════════════════════════════════════

Step 1: Count PRs by type (last 90 days)
────────────────────────────────────────
  Total PRs merged:                        180
  PRs with "feat"/"feature" in title:       72  (40%)
  PRs with "fix"/"bug"/"hotfix":            54  (30%)
  PRs with "refactor"/"cleanup":            18  (10%)
  PRs with dependency updates:              18  (10%)
  Other/uncategorized:                      18  (10%)

Step 2: Map to categories
────────────────────────────────────────
  Feature Work:     40% (feature PRs)
  Maintenance:      50% (fixes + deps + half of other)
  Tech Debt:        10% (refactors)

Step 3: Compare to your expectation
────────────────────────────────────────
  Expected:   70% feature / 30% maintenance
  Actual:     40% feature / 50% maintenance
  Gap:        30 percentage points toward maintenance

  Verdict: You're in Recovery Mode, not Growth Mode.

Using Code Churn as a Maintenance Indicator

While no single metric perfectly distinguishes features from maintenance, code churn rate provides useful signal:

What Churn Reveals

Combining Signals

Churn alone doesn't tell the full story. Combine with:

• File hotspots: High-churn files that change frequently may need architectural attention, not just cleanup
• Test failure rates: Rising failures + high churn = instability. Stable tests + high churn = healthy refactoring.
• PR size trends: Growing PR sizes may indicate accumulating complexity

Signs You've Over-Indexed on Features

Teams rarely consciously decide to neglect maintenance. It happens gradually, one deadline at a time. Watch for these warning signs:

WARNING SIGNS: TOO MUCH FEATURE, TOO LITTLE MAINTENANCE
═══════════════════════════════════════════════════════════════

EARLY WARNINGS (Act now—easy to fix)
────────────────────────────────────────
□ Churn rate creeping up quarter-over-quarter
□ Same files appearing in multiple hotspot reports
□ "We'll fix it after launch" becoming a pattern
□ Skipped unit tests "to save time"
□ Growing backlog of "should fix" tickets

MODERATE WARNINGS (Act soon—harder to fix)
────────────────────────────────────────
□ Cycle time increasing 20%+ in legacy areas
□ New engineers struggling to onboard to old code
□ "It's faster to work around it" becoming common
□ Test suite taking 50%+ longer to run
□ Increased incidents after deployments

SEVERE WARNINGS (Act immediately—painful to fix)
────────────────────────────────────────
□ Cycle time 2x+ slower in legacy vs. new services
□ Key engineers refusing to work on certain modules
□ "Nobody knows how this works" for critical paths
□ More than 40% of PRs are bug fixes
□ Engineers citing codebase as reason for leaving

CRITICAL (You're in crisis)
────────────────────────────────────────
□ Feature delivery has slowed despite headcount growth
□ Major systems considered "untouchable"
□ Discussing full rewrite or replacement
□ Customer-facing incidents weekly or more
□ Team morale visibly declining

"By the time you're discussing a rewrite, you've already lost 12-18 months. The best time to invest in maintenance was a year ago. The second best time is today."

The Maintenance Debt Snowball Effect

Deferred maintenance doesn't just accumulate—it compounds. Each shortcut creates friction for future work, which creates pressure for more shortcuts. This is the snowball effect.

THE DEBT SNOWBALL: HOW SMALL DECISIONS COMPOUND
═══════════════════════════════════════════════════════════════

QUARTER 1: "We'll clean it up later"
────────────────────────────────────────
  - Ship feature with hacky workaround
  - Skip unit tests to meet deadline
  - Copy-paste code instead of extracting utility

  Immediate impact: None visible
  Hidden cost: +5% friction for future changes

QUARTER 2: More pressure, same choices
────────────────────────────────────────
  - Workaround breaks, add second workaround
  - New feature built on shaky foundation
  - "Quick fix" in production to address bug

  Visible impact: Some repeat bugs
  Hidden cost: +15% friction (compounding)

QUARTER 3: The snowball is rolling
────────────────────────────────────────
  - New engineers can't understand the code
  - Changes in one place break three others
  - "Safe" changes requiring extensive review

  Visible impact: Slower delivery, more bugs
  Hidden cost: +30% friction (accelerating)

QUARTER 4: Technical bankruptcy risk
────────────────────────────────────────
  - Team afraid to touch core systems
  - Simple features taking weeks
  - Best engineers starting to leave

  Visible impact: Crisis discussions
  Hidden cost: +60% friction (exponential)

The math: If Q1 friction was 10 hours/week, by Q4 it's 16 hours.
That's 6 hours/week lost PER ENGINEER. For a 10-person team,
that's 60 hours/week—1.5 full-time engineers worth of capacity.

Innovation Accounting Frameworks

How do you know if your feature investment is actually paying off? Shipping features doesn't equal creating value. Innovation accounting helps you track whether your feature work is generating results.

The Feature Investment Framework

INNOVATION ACCOUNTING: TRACK FEATURE ROI
═══════════════════════════════════════════════════════════════

For each major feature investment, track:

INPUT METRICS (Effort)
────────────────────────────────────────
□ Engineering hours invested
□ Number of PRs/commits
□ Elapsed time (start to ship)
□ Opportunity cost (what didn't get built)

OUTPUT METRICS (Results)
────────────────────────────────────────
□ User adoption (% of users using feature)
□ Engagement (how often feature is used)
□ Revenue impact (if measurable)
□ Support ticket reduction (if applicable)
□ User satisfaction change

EFFICIENCY METRICS (Process)
────────────────────────────────────────
□ Actual vs. estimated effort
□ Bugs discovered post-launch
□ Rework required after launch
□ Time to first value (when users benefited)

LEARNING METRICS (Knowledge)
────────────────────────────────────────
□ Validated hypotheses
□ Invalidated assumptions
□ New capabilities built (reusable?)
□ Technical debt created vs. paid down

The Maintenance Investment Framework

MAINTENANCE ACCOUNTING: PROVE MAINTENANCE VALUE
═══════════════════════════════════════════════════════════════

For maintenance/debt work, track before and after:

VELOCITY METRICS
────────────────────────────────────────
□ Cycle time in affected area (before/after)
□ PR size in affected area (before/after)
□ Code churn rate (before/after)
□ Time to onboard new engineer to area

QUALITY METRICS
────────────────────────────────────────
□ Bug rate in affected area (before/after)
□ Incident frequency (before/after)
□ Test coverage (before/after)
□ Test reliability (flaky test rate)

RISK METRICS
────────────────────────────────────────
□ Bus factor (knowledge silo risk)
□ Dependency vulnerability count
□ Security audit findings
□ Compliance gaps

Example Maintenance ROI Case:
────────────────────────────────────────
Investment:   80 engineering hours (2 weeks, 1 engineer)
Result:       Cycle time dropped 40% in billing module
              Bug rate dropped 60%
              2 engineers can now work in area (was 1)

Monthly savings: ~20 hours × $75/hour = $1,500/month
Payback period:  80 hours ÷ 20 hours/month = 4 months
Annual ROI:      (12 months - 4 months) × $1,500 = $12,000

Healthy Ratios by Company Stage

The "right" balance depends on your context:

The 20% Rule

A widely-cited guideline: allocate at least 20% of engineering capacity to maintenance, technical debt, and infrastructure improvements. This includes:

• Dependency updates and security patches
• Refactoring high-churn code
• Improving test coverage
• Documentation and knowledge sharing
• Developer tooling and CI/CD improvements

Teams that consistently allocate less than 20% to maintenance typically see velocity decline within 12-18 months.

How Successful Companies Handle This Balance

Let's look at how high-performing engineering organizations approach the feature/maintenance balance:

CASE STUDY: THE "20% TIME" APPROACH
═══════════════════════════════════════════════════════════════

Company Type: Large tech companies (Google-style)
Approach:     Engineers get ~20% time for self-directed projects

What works:
  ✓ Empowers engineers to fix pain points they experience
  ✓ Some "20% projects" become major products
  ✓ Builds culture of ownership

What doesn't:
  ✗ Hard to coordinate across team
  ✗ Critical maintenance may get ignored if unglamorous
  ✗ Doesn't scale well at smaller companies

Best for: Mature organizations with strong engineering culture

────────────────────────────────────────────────────────────────

CASE STUDY: THE "TECH DEBT SPRINT" APPROACH
═══════════════════════════════════════════════════════════════

Company Type: Mid-size SaaS companies
Approach:     Every 4-6 sprints, dedicate one sprint to debt paydown

What works:
  ✓ Predictable maintenance investment
  ✓ Concentrated effort on biggest pain points
  ✓ Easy to communicate to stakeholders

What doesn't:
  ✗ Can feel like "permission to accumulate debt"
  ✗ May not be enough if debt is severe
  ✗ Urgent features may override scheduled sprints

Best for: Teams with moderate debt and regular release cycles

────────────────────────────────────────────────────────────────

CASE STUDY: THE "BOY SCOUT" APPROACH
═══════════════════════════════════════════════════════════════

Company Type: Small-to-medium teams, fast-moving startups
Approach:     Leave code better than you found it, every PR

What works:
  ✓ Distributed maintenance—no dedicated "debt time"
  ✓ Continuous improvement, never falls too far behind
  ✓ Builds good habits across team

What doesn't:
  ✗ Hard to tackle large systemic issues
  ✗ May slow down individual PRs
  ✗ Requires strong code review culture

Best for: Teams that review all PRs thoroughly

────────────────────────────────────────────────────────────────

CASE STUDY: THE "DEDICATED PLATFORM TEAM" APPROACH
═══════════════════════════════════════════════════════════════

Company Type: Larger organizations (100+ engineers)
Approach:     Separate team focused on infrastructure/debt

What works:
  ✓ Deep expertise in systemic improvements
  ✓ Feature teams can focus on features
  ✓ Long-term improvements get championed

What doesn't:
  ✗ Can create "us vs. them" culture
  ✗ Feature teams may stop caring about code quality
  ✗ Coordination overhead

Best for: Organizations large enough to justify dedicated team

Quarterly Rebalancing Strategies

The right balance shifts over time. Build a quarterly review process to adjust your allocation based on changing conditions.

QUARTERLY BALANCE REVIEW TEMPLATE
═══════════════════════════════════════════════════════════════

STEP 1: Measure Current State (Week 1)
────────────────────────────────────────
□ Pull PR data for last quarter
□ Categorize by type (feature/maintenance/debt/other)
□ Calculate actual ratio
□ Compare to target ratio

Questions to answer:
  - What was our target? What was actual?
  - Where did unplanned maintenance come from?
  - What features took longer than expected?

STEP 2: Assess Health Indicators (Week 1)
────────────────────────────────────────
□ Cycle time trend (improving/stable/declining?)
□ Churn rate trend
□ Hotspot changes (new hotspots? resolved ones?)
□ Test failure rate
□ Engineer satisfaction (survey or 1:1 feedback)

Questions to answer:
  - Is our codebase getting healthier or sicker?
  - Are there early warning signs of debt snowball?
  - What do engineers think we should prioritize?

STEP 3: Evaluate Business Context (Week 2)
────────────────────────────────────────
□ What's on the roadmap for next quarter?
□ Any major launches or deadlines?
□ Are we pre- or post- a major release?
□ Any compliance/security deadlines?
□ Headcount changes (growth/contraction)?

Questions to answer:
  - What external pressures affect our balance?
  - Is this a "push features" or "stabilize" quarter?
  - What can't wait vs. what's flexible?

STEP 4: Set Next Quarter's Targets (Week 2)
────────────────────────────────────────
□ Choose operating mode (Growth/Sustainable/Recovery/Crisis)
□ Set specific ratio targets
□ Identify specific maintenance priorities
□ Allocate explicit capacity for debt work
□ Define "escape hatches" for emergencies

Deliverable: One-page plan with ratios and rationale

Monthly Check-In Questions

Between quarterly reviews, do a quick monthly check-in:

1. Are we on track for our quarterly ratio target? If not, what's pulling us off course?
2. Any new hotspots or concerning trends? Catching problems early is cheaper than fixing them later.
3. Any reason to adjust our targets? Sometimes circumstances change mid-quarter.

Making the Business Case for Maintenance Work

Framing Maintenance as Investment

Executives often view maintenance as "not shipping." Reframe it:

• Instead of: "We need time to refactor"
  Say: "Investing 2 weeks now will reduce future feature delivery time by 30%"
• Instead of: "The code is messy"
  Say: "Our cycle time has increased 40% in this area due to accumulated complexity"
• Instead of: "We have technical debt"
  Say: "We're paying 20% overhead on every change in this module"

Data to Bring to the Conversation

1. Cycle time trends: Show how delivery speed is declining in neglected areas
2. Hotspot analysis: Identify specific files/modules causing friction
3. Defect rates: Connect maintenance neglect to quality issues
4. Developer surveys: Qualitative feedback on codebase health
5. Competitor comparison: Are competitors shipping faster?

The ROI Framework for Maintenance

MAINTENANCE ROI CALCULATION
═══════════════════════════════════════════════════════════════

STEP 1: Quantify Current Cost
────────────────────────────────────────
  Cycle time premium:     Legacy module takes 3x longer
  Hours wasted per month: 40 hours (across team)
  Hourly cost:            $75 (fully loaded)
  Monthly friction cost:  40 × $75 = $3,000/month

STEP 2: Estimate Investment
────────────────────────────────────────
  Refactoring effort:     160 hours (4 weeks, 1 engineer)
  Investment cost:        160 × $75 = $12,000

STEP 3: Project Improvement
────────────────────────────────────────
  Expected improvement:   50% reduction in friction
  Monthly savings:        $3,000 × 50% = $1,500/month

STEP 4: Calculate Payback
────────────────────────────────────────
  Payback period:         $12,000 ÷ $1,500 = 8 months
  Year 1 ROI:             (12 - 8) × $1,500 = $6,000
  5-year ROI:             $1,500 × (60 - 8) = $78,000

PRESENTATION SUMMARY
────────────────────────────────────────
  "For a $12,000 investment (4 weeks, 1 engineer), we
   eliminate $78,000 in friction over 5 years. That's
   a 6.5x return—better than most feature investments."

Proposing a Plan

Maintenance Investment Proposal Template:

Problem:
  - Cycle time in [module] increased 45% over 6 months
  - 3 of our top 5 hotspots are in this area
  - Developers report 2+ hours/week lost to workarounds

Proposal:
  - Allocate 25% of next sprint to targeted refactoring
  - Focus on top 3 hotspots identified by change frequency
  - Expected outcome: 30% cycle time reduction in affected area

Success Metrics:
  - Cycle time in [module] returns to Q1 levels
  - Hotspot change frequency decreases
  - Developer satisfaction improves (survey)

Timeline: 2 sprints of focused work, then reassess

"Never pitch maintenance as a cost. Always pitch it as an investment with measurable returns. If you can't measure the return, you probably shouldn't prioritize it."

Tracking Balance Over Time

Monthly Balance Review

Create a recurring review cadence:

1. Review churn trends: Is it trending up, down, or stable?
2. Check hotspots: Are the same files always problematic?
3. Assess velocity: Is cycle time stable or growing?
4. Quality check: Test failure rate, review coverage
5. Adjust allocation: Increase maintenance if signals are negative

Leading vs Lagging Indicators

Act on leading indicators before lagging indicators force your hand.

Practical Balancing Strategies

The Boy Scout Rule

"Leave the code better than you found it." Encourage small improvements with every feature PR:

• Rename unclear variables while you're in the file
• Add missing tests for code you're modifying
• Extract duplicated logic into shared utilities
• Update outdated comments

This spreads maintenance across all work rather than batching it.

Tech Debt Sprints

Schedule periodic maintenance-focused sprints:

• Every 4-6 weeks, one sprint focused on debt paydown
• Use hotspot data to prioritize what to tackle
• Celebrate the work publicly to reinforce its value

Maintenance Budgets

Reserve explicit capacity:

• 20% of every sprint allocated to maintenance
• Rotate who does maintenance to spread knowledge
• Track maintenance work separately to demonstrate investment

The "Maintenance Fridays" Approach

MAINTENANCE FRIDAY STRUCTURE
═══════════════════════════════════════════════════════════════

Every Friday afternoon (or one full day per sprint):

ALLOWED:
────────────────────────────────────────
✓ Fix that annoying bug you've been ignoring
✓ Update outdated dependencies
✓ Improve test coverage in your area
✓ Refactor code you touched this week
✓ Update documentation
✓ Address code review feedback backlog

NOT ALLOWED:
────────────────────────────────────────
✗ New feature work
✗ Scope creep on maintenance tasks
✗ "While I'm here, let me also..."

TRACKING:
────────────────────────────────────────
□ Log maintenance work in dedicated channel
□ Tag PRs with "maintenance" label
□ Share wins in weekly team meeting

Why it works:
  - Predictable, protected time
  - Small, incremental improvements
  - Engineers choose what matters to them
  - Creates habit of continuous improvement

Your Action Plan

This Week: Measure Your Reality

1. Pull last quarter's PR data: Categorize by type (feature/maintenance/debt)
2. Calculate your actual ratio: Compare to what you thought it was
3. Identify your mode: Are you in Growth, Sustainable, Recovery, or Crisis?

This Month: Build Your System

1. Choose a categorization method: PR labels, branch prefixes, or commit conventions
2. Define your categories: What counts as feature vs. maintenance vs. debt?
3. Set up tracking: How will you measure your ratio monthly?
4. Pick a maintenance strategy: Boy Scout, Tech Debt Sprints, or Maintenance Fridays

This Quarter: Review and Adjust

1. Conduct quarterly balance review: Measure actual vs. target
2. Assess health indicators: Are cycle times, churn, and hotspots improving?
3. Set next quarter's targets: Adjust based on learnings and business context
4. Document and share: Make balance metrics visible to the team

For more on recognizing maintenance contributions, see our guide on Developer Recognition Programs. For quantifying the cost of neglected maintenance, see Quantifying Technical Debt. For understanding investment categories, see our guide on KTLO vs. Innovation Investment Profile.