Skip to main content
All Guides
Metrics

The Slide That Changed How Our Board Sees Engineering

Stop talking about "maintenance" and start talking about "investment." How to measure and present your engineering investment profile to the board.

11 min readUpdated January 3, 2026By CodePulse Team

Your board doesn't want to hear about "refactoring" or "maintenance." They want to hear about Capital Allocation. This guide shows you how to measure, categorize, and present your engineering investment profile—the balance between "Keep The Lights On" (KTLO) work and innovation—in terms that align with business goals and get executive buy-in.

"If more than 40% of your capacity goes to KTLO, you're running a support operation, not building a product."

Reframing Maintenance as Investment

In finance, money spent on operations is an Expense (bad for EBITDA). Money spent on building long-term assets is an Investment (good for the balance sheet).

Engineering work follows the same logic:

  • KTLO (Keep the Lights On): Expense. Essential, but minimizes value erosion.
  • Innovation/New Features: Investment. Creates new value and revenue potential.
  • Enhancement/Improvement: Hybrid. Extends the value of existing assets.

Your goal as a leader isn't to "eliminate maintenance"—that's impossible. Your goal is to optimize your Investment Profile to maximize the percentage of effort going toward value creation while keeping the lights reliably on.

🔥 Our Take

Innovation drag is the silent killer of engineering organizations.

Most engineering leaders know their team is spending "too much time" on maintenance, but they can't quantify it. Without numbers, they can't get budget for improvement. Without improvement, KTLO grows. It's a death spiral. The teams that break out are the ones who measure their investment profile and treat it like the strategic metric it is.

Categorizing and Tagging Work

Before you can measure your investment profile, you need a consistent way to categorize work. Here's the framework we recommend:

The Four Investment Categories

CategoryDefinitionExamplesFinancial Treatment
InnovationNet-new capabilities that didn't exist beforeNew product lines, major features, new integrationsCapitalizable
EnhancementImprovements to existing capabilitiesPerformance improvements, UX upgrades, feature expansionPartially capitalizable
KTLO / MaintenanceWork required to keep existing systems runningBug fixes, security patches, dependency updates, on-callExpense
Tech DebtIntentional investment in future productivityRefactoring, platform improvements, test coverageExpense (but ROI-positive)

Practical Tagging Methods

You have several options for categorizing work, each with trade-offs:

Work Categorization Methods

Method 1: PR Labels (Recommended)
  • Require labels on every PR: type:innovation, type:enhancement, type:ktlo, type:tech-debt
  • Pros: Low friction, Git-native, automatable
  • Cons: Requires discipline, subjective categorization
Method 2: Branch Naming Convention
  • Prefix branches with category: feature/, enhance/, fix/, debt/
  • Examples: feature/new-billing-module, enhance/checkout-performance, fix/payment-timeout-bug
  • Pros: Automatic from Git data, no extra tooling
  • Cons: Less flexible, harder to change after creation
Method 3: Commit Message Tags
  • Conventional commits with type prefixes: feat:, fix:, refactor:, chore:
  • Example: feat: Add new export functionality
  • Pros: Granular, standard convention
  • Cons: Requires commit discipline, can be gamed
Method 4: Issue/Ticket Labels
  • Tag at the planning level with epic type in your project management tool
  • Links back to PRs via integration
  • Pros: Business context, product involvement
  • Cons: Requires issue tracker, sync overhead

"Don't let perfect be the enemy of good. Any consistent categorization beats none. Pick a method and stick with it for 3 months before iterating."

Git-Based Proxies (No Labeling Required)

If your team doesn't have consistent labeling yet, you can infer investment categories from Git data:

CategoryGit Signals (Proxies)Accuracy
InnovationNew repos, new directories, high addition ratio (80%+ new code)High
EnhancementChanges to feature directories, moderate add/modify ratioMedium
KTLOSmall PRs, config files, "fix" in title, high churn filesMedium-High
Tech DebtRefactor keywords, high deletion ratio, test file changesMedium

📊Seeing This in CodePulse

CodePulse helps you visualize your investment split:

  • Repo Activity: Filter Repositories to see which services are active. Are they legacy maintenance services or new product services?
  • Churn Rates: High churn in old files usually indicates unplanned rework (KTLO).
  • File Hotspots: The File Hotspots view shows where repetitive work is happening.
  • Executive Summary: See the overall health grade in the Executive Summary.

Measuring Investment Allocation

The Basic Formula

Investment Ratio Formulas

Innovation Ratio = (Innovation + Enhancement PRs) / Total PRs x 100

KTLO Ratio = (KTLO + Bug Fix PRs) / Total PRs x 100

Examples:
Q1 Example
Total PRs: 240, Innovation: 96 (40%), Enhancement: 48 (20%), KTLO: 72 (30%), Tech Debt: 24 (10%)
= 60% Investment, 30% Maintenance
Interpretation:
60%+Healthy profile for a growth-stage company
50-60%Balanced profile for mature companies
<50%KTLO dominance - needs attention

Going Deeper: Weighted by Effort

PR counts can be misleading. A quick bug fix counts the same as a multi-week feature. For more accuracy, weight by effort:

Weighted Investment Ratio

Weighted Ratio = Sum(Category Hours) / Total Hours x 100

Effort proxies: Engineer-days, Lines changed, PR size x Cycle time, or Story points

Examples:
Line-Based
Total Lines: 50,000, Innovation: 30,000 (60%), Enhancement: 8,000 (16%), KTLO: 10,000 (20%), Tech Debt: 2,000 (4%)
= 76% Investment, 20% Maintenance
Interpretation:
NoteWeighted ratio often looks healthier than PR count because innovation PRs tend to be larger
See your engineering metrics in 5 minutes with CodePulse

Healthy vs Unhealthy Ratios by Company Stage

"The right KTLO ratio depends on your company stage. A Series A company with 50% KTLO is dying. A public company with 50% KTLO might be thriving."

Investment Profile Benchmarks

Company StageInnovationEnhancementKTLOTech Debt
Pre-Seed / Seed70-80%10-15%5-15%0-5%
Series A60-70%15-20%10-20%5-10%
Series B50-60%15-25%15-25%5-15%
Series C+40-50%20-30%20-30%10-15%
Public / Enterprise30-40%25-35%25-35%10-15%

Warning Signs: The Death Spiral

The KTLO Death Spiral

Stage 1: Creeping KTLO (30-40%)
  • "We'll clean it up after the launch"
  • Technical debt accumulates
  • New features ship slower
  • Escape: Fix with 10-15% tech debt allocation
Stage 2: Maintenance Dominance (40-50%)
  • More bugs than features shipped
  • Best engineers start leaving
  • Roadmap slips become normal
  • Escape: Requires dedicated "debt sprint" (4-6 weeks)
Stage 3: Crisis Mode (50-60%)
  • Every change breaks something
  • Team morale tanks
  • Executives question engineering competence
  • Escape: Major intervention needed (team restructure?)
Stage 4: Technical Bankruptcy (60%+)
  • Feature development nearly stops
  • Considering full rewrite
  • Company viability at risk
  • Escape: Rewrite or die (most companies fail here)

🔥 Our Take

The 40% threshold is not arbitrary—it's where the math stops working.

At 40% KTLO, you need to dedicate half of your remaining capacity (30% of total) just to maintain innovation at status quo. That leaves 30% for actual growth. With engineering efficiency typically at 60-70%, you're really getting 20% of headcount toward growth. Add management overhead and you're barely moving forward. This is why 40% is the line. Cross it and you're slowly dying.

R&D Capitalization and Finance

Your CFO cares about this deeply. Under GAAP (accounting rules), costs associated with developing new software features can often be Capitalized (treated as an asset) rather than Expensed.

Why This Matters for Valuation

  • Higher Profitability (Paper): Capitalizing costs reduces your immediate operating expenses, improving EBITDA.
  • Better Valuation: Higher profitability/efficiency can lead to better valuation multiples.
  • Investor Confidence: Showing intentional investment vs. uncontrolled spending.
  • Audit Readiness: Clear documentation of how engineering time is allocated.

What's Capitalizable?

R&D Capitalization Rules (ASC 350-40 / IAS 38)

Not Capitalizable
  • Bug fixes and maintenance
  • Training and documentation
  • Research / feasibility studies
  • Data conversion
  • General infrastructure (unless project-specific)
  • Support and operations
Capitalizable
  • New feature development (post-feasibility)
  • Major product enhancements
  • New product lines
  • Platform development (if extends useful life)
  • Software purchased for internal use
Gray Area (consult your CFO/auditors):
  • Performance improvements
  • Major refactoring that extends life
  • Security hardening
  • Testing infrastructure

"By proving that 70% of your team's time is spent on Innovation (capitalizable work), you are directly helping the CFO improve the company's financial picture."

Documentation Requirements

For audit-ready capitalization tracking, you need:

  1. Clear project definitions (what's being built, when it started, expected completion)
  2. Time allocation by category (your investment profile)
  3. Evidence of post-feasibility stage (for software capitalization)
  4. Reasonable estimation methodology (documented and consistent)

💰Generating Capitalization Reports in CodePulse

CodePulse can help with R&D capitalization documentation:

  • Export Data: Use the CSV Export feature to pull PR data by time period and repository
  • Repository Mapping: Map repos to projects in Repositories to align with finance categories
  • Time Trends: Use Year in Review for quarterly allocation summaries

Presenting to Executives

Don't show a list of JIRA tickets. Show the "Investment Layer Cake"—a visual representation of where engineering capacity is going.

The One-Slide Investment Profile

Q1 2025 Engineering Investment Profile

By PR count
Good
55%
+7 pts from Q4
Innovation
Stable
20%
Enhancement
Good
18%
-6 pts from Q4
KTLO
Stable
7%
Tech Debt
Q4 Baseline:Innovation 48%, KTLO 24% (post-launch bug surge)
Q2 Target:Innovation 60%, KTLO 15%
Key Insight:Recovered from Q4 launch. KTLO dropped 6 points as critical bugs resolved. On track for 60% innovation in Q2.

Language That Works

Don't SayDo Say
"We're doing a lot of maintenance""18% of capacity is in sustaining investment"
"Tech debt is slowing us down""Our KTLO ratio is 5 points above target"
"We need time for refactoring""A 2-week strategic debt investment will shift our profile by 8 points"
"We're fixing a lot of bugs""Post-launch stabilization consumed 6% additional capacity"
"Developers are frustrated""Our innovation ratio dropped 12 points—we're losing growth capacity"

Handling Tough Questions

Handling Tough Questions

Executive

"Why is innovation only 55%? Shouldn't it be higher?"

You

"For a Series B company, 55% innovation is healthy—industry benchmark is 50-60%. We're in the sweet spot. Going higher would risk quality (more bugs, more KTLO later). Our goal is sustainable 60%, not unsustainable 80%."

Executive

"Can we just stop all maintenance and ship features?"

You

"KTLO isn't optional—it's the cost of having customers. Zero KTLO means zero bug fixes, zero security patches. But we can optimize. Our target is 15%, which is aggressive but achievable with automation investment."

Executive

"How does this compare to [Competitor]?"

You

"Most companies don't share this data, but based on industry benchmarks, our 55% innovation ratio is top quartile. The median is 45-50% for companies our stage."

Executive

"What would it take to hit 70% innovation?"

You

"70% would require either (a) significant platform investment to reduce KTLO overhead, or (b) aggressive feature cutting to reduce surface area. Option A takes 2 quarters. Option B loses customers. I'd recommend we target 65% over 3 quarters through automation."

Detect code hotspots and knowledge silos with CodePulse

Correcting an Imbalanced Profile

If your profile is inverted (e.g., 60% KTLO), you need a "Debt Paydown" strategy. There are three approaches, each with different risk profiles:

Option 1: The Gradual Shift (Conservative)

The Gradual Shift

Overview
  • Allocate 10-15% of sprint capacity to debt paydown every sprint
  • Timeline: 4-6 quarters to significant improvement
  • Risk: Low | Disruption: Minimal
Best For
  • Teams without executive urgency
  • Stable product with no major launches
  • Risk-averse organizations
Watch Out For
  • "Debt work" getting deprioritized when deadlines hit
  • Slow momentum (hard to see progress)
  • Gradual backsliding if not measured

Option 2: The Focused Sprint (Moderate)

The Focused Sprint

Overview
  • Dedicate 4-6 weeks of a sub-team (3-5 engineers) to targeted debt work
  • Timeline: One quarter to measurable improvement
  • Risk: Medium | Disruption: Moderate (sub-team context switches)
Best For
  • Teams with specific high-interest debt
  • When you can identify 3-5 high-impact areas
  • Mid-stage companies with some slack
Watch Out For
  • "Debt team" becoming isolated
  • Other teams accumulating new debt while you fix old
  • Definition of "done" getting fuzzy

Option 3: The Investment Quarter (Aggressive)

The Investment Quarter

Overview
  • Full quarter focused on platform/infrastructure work with reduced feature output
  • Timeline: One quarter of "investment", 2+ quarters of payback
  • Risk: High | Disruption: Significant (roadmap impact)
Best For
  • Teams in crisis (50%+ KTLO)
  • When tech bankruptcy is imminent
  • After executive buy-in with clear ROI case
Watch Out For
  • Business impact if done without alignment
  • Scope creep ("while we're at it...")
  • Team burnout from intense focused work

For detailed guidance on building the business case for debt paydown, see our guide on quantifying technical debt.

Tracking Progress Over Time

Measuring your investment profile once is useful. Tracking it quarterly is transformational.

Setting Up Quarterly Tracking

  1. Establish your baseline: Measure current state across all four categories.
  2. Set targets by quarter: Define where you want to be in 3, 6, and 12 months.
  3. Review monthly: Check progress, identify slippage early.
  4. Report quarterly: Include in board updates and executive reviews.
  5. Adjust annually: Recalibrate targets based on company stage changes.

Leading vs Lagging Indicators

Leading (Predict Trouble)Lagging (Confirm Trouble)
Bug PRs trending up week-over-weekKTLO ratio exceeds target
Increasing churn in core filesCycle time increasing
Engineers skipping retros/planningAttrition increasing
Hotfix frequency increasingRoadmap slippage
Test failures trending upCustomer complaints increasing

🔔Setting Up Investment Profile Alerts

Automate your monitoring with CodePulse alerts:

  • Navigate to Alert Rules to configure thresholds
  • Set alerts for Churn Rate above your target
  • Monitor Cycle Time trends as a leading indicator
  • Track PR Size to catch scope creep in maintenance work

Your Action Plan

This Week: Measure Your Baseline

  1. Pull last quarter's PRs: Export from GitHub or CodePulse.
  2. Categorize a sample: Manually tag 50-100 PRs to establish patterns.
  3. Calculate ratios: Innovation, Enhancement, KTLO, Tech Debt.
  4. Compare to benchmarks: Where do you stand for your company stage?

This Month: Establish Process

  1. Choose a tagging method: PR labels, branch naming, or commit conventions.
  2. Document definitions: What counts as Innovation vs Enhancement vs KTLO?
  3. Train the team: Get buy-in on consistent categorization.
  4. Set up tracking: Weekly or bi-weekly measurement cadence.

This Quarter: Report and Improve

  1. Set targets: Where should your profile be in 3, 6, 12 months?
  2. Create the one-slider: Investment profile visualization for executives.
  3. Identify interventions: What will move the needle most?
  4. Track leading indicators: Catch problems before they show up in the ratio.

For more on measuring and presenting engineering metrics, see our guides on Board-Ready Engineering Metrics, Feature vs. Maintenance Balance, and Building the Business Case for Engineering Metrics.

See these insights for your team

CodePulse connects to your GitHub and shows you actionable engineering metrics in minutes. No complex setup required.

Free tier available. No credit card required.