How to Shift Engineering Maintenance vs. Innovation - The missing link in Engineering management | Pensero [Let's talk](../book-demo) [Login](/auth/login/) [Login](/auth/login/) [Let's talk](../book-demo) [Login](/auth/login/) [Blog](../blog) / Article ## How to Shift Engineering Maintenance vs. Innovation Learn how to balance engineering maintenance and innovation to reduce technical debt, improve productivity, and create more time for strategic work. ![](https://framerusercontent.com/images/WF5wXySb5oYBsfMDPbU0hRuXY3M.png?width=1600&height=900) ![](https://framerusercontent.com/images/GjPJ8lgQ2s9KH4YirhymwwZxVY.png?width=1152&height=1152) Pensero · Pensero Marketing · Jun 10, 2026 Most engineering organizations are spending more capacity on maintenance than they realize, and less on innovation than they intend. The problem is not a lack of ambition. Engineering leaders want to build. Their teams want to build. The strategic roadmap is full of new features and platform investments. But somewhere between intention and execution, a significant share of engineering capacity gets absorbed by bug fixes, sustaining work, unplanned requests, and the compounding interest of past technical shortcuts. The ratio drifts, quietly, quarter over quarter, until a board review or a planning cycle forces the conversation. That shift, from 70% maintenance to 30%, is not a coincidence or a lucky sprint. It is the result of making the ratio visible, tracking it continuously, and having a clear target to move toward. This article covers how to measure where you stand, what drives the ratio in the wrong direction, and how to shift it deliberately. ## **Tools for measuring innovation rate and maintenance split** Knowing your innovation rate requires a measurement framework that classifies work accurately, without depending on engineers to tag tickets correctly or managers to estimate allocation after the fact. AI-based work categorization, applied at the delivery level rather than the planning level, is the only approach that produces a reliable picture of where engineering capacity actually goes. ### **1. Pensero** Pensero is an empowerment tool for engineering performance that brings together real signals from GitHub, Jira, and the tools your team already uses to uncover how work moves, where it gets blocked, and how development practices and AI usage translate into real business impact. Innovation rate is one of Pensero's 10 core Benchmark dimensions: the share of delivery going to new features versus maintenance, sustaining work, and rework, classified automatically using AI models and agents that understand the content of every work item, not just its label or ticket category. This means the innovation rate reflects actual delivery content, not how engineers estimated or tagged work upfront. A ticket labeled "feature" that resolves a recurring defect gets classified correctly. Rework that arrives as a new ticket gets captured in the ratio. Roadmap alignment, the share of delivery tied to stated strategic priorities, sits alongside innovation rate in the same framework, providing a second angle on the same question: not just what type of work is being done, but how much of it connects to what the organization said it would build. [Pensero Benchmark](https://pensero.ai/landing/benchmark) places your innovation rate in percentile rank against all Pensero customers using real production data, updated weekly. [Pensero Calibrate](http://www.pensero.ai/landing/calibration) enables team-level comparison, putting two or more teams side by side on innovation rate and roadmap alignment with the industry median as a reference line. This surfaces whether the maintenance burden is evenly distributed or concentrated in specific teams carrying disproportionate sustaining work. The platform integrates with GitHub, GitLab, Bitbucket, Jira, Linear, GitHub Issues, Slack, Microsoft Teams, Notion, Confluence, Google Calendar, Cursor, and Claude Code. Zero configuration required. Customers include TravelPerk, ClosedLoop, Elfie.co, and Caravelo. Pricing as of March 2026: free tier up to 10 engineers and 1 repository; $50/month premium; custom enterprise pricing. Compliant with SOC 2 Type II, HIPAA, and GDPR. ### **2. Jellyfish** Jellyfish tracks work allocation across categories, features, maintenance, technical debt, and support, using its work categories framework (Roadmap, KTLO, Support, Infrastructure), with customization available. [Investment allocation](https://www.investopedia.com/terms/a/assetallocation.asp) is one of Jellyfish's core strengths: connecting engineering effort to business outcomes and showing how capacity is distributed across initiative types. Classification relies on a combination of Jira data and configuration rather than AI-based content analysis of actual delivery. ### **3. LinearB** LinearB provides investment allocation metrics that classify work into categories to show how engineering capacity is split between new features, maintenance, and unplanned work. Classification is based on ticket metadata and configuration. Useful for teams that want category-level visibility with lightweight setup; accuracy depends on the quality of ticket taxonomy and tagging discipline in the source data. ### **4. Swarmia** Swarmia surfaces work type distribution as part of its process health metrics, with basic categorization of delivery by initiative type. Less focused on the innovation-vs-maintenance split as a standalone strategic metric; more oriented toward workflow patterns and PR-level process health. ## **Are we building the right things?** This is the question that innovation rate answers, and it is the one most engineering leaders cannot answer with data. Most organizations have a general sense of the split. Engineering leaders know when the team feels reactive. Product managers notice when roadmap items keep getting delayed. The board asks why the new platform features promised last quarter are still in backlog. But the conversation stays qualitative because the data to make it quantitative either does not exist or is assembled manually from Jira exports that are already stale by the time someone looks at them. Innovation rate measured continuously, as a share of complexity-weighted delivery, classified from actual work content rather than planned estimates, turns a qualitative conversation into a tracked metric. When it trends down, the maintenance burden is growing. When it trends up, the deliberate investment in reducing sustaining work is paying off. When it is flat at a low number, the organization has a structural problem that will not resolve itself. The target ratio varies by organization type, growth stage, and codebase maturity. A young product company with a clean codebase and aggressive roadmap might run at 70% or higher innovation. A mature platform supporting many customers on a large codebase might consider 50% a strong result. What matters is that the ratio is known, tracked, and moving intentionally rather than drifting invisibly. ## **Are we getting a good return on what we are investing?** Engineering is one of the largest cost lines on the P&L. When a significant share of that investment is absorbed by maintenance and rework, the effective cost of building new things is much higher than the headline engineering budget suggests. The calculation is direct: if an engineering team of 40 engineers is running at 60% maintenance, only 16 engineers worth of capacity is going to new product development. The other 24 are sustaining what already exists. At a fully loaded cost of $200K per engineer per year, that is $4.8M annually in sustaining investment, money that could be funding competitive differentiation if the maintenance burden were reduced. This is the framing that gets attention in board conversations. Not "we have too much technical debt", which is abstract and sounds like a resource request, but "here is the share of engineering investment that is not building new value, here is what it costs in real terms, and here is what shifting that ratio by 20 percentage points would free up." That is a capital allocation conversation, and it is one that boards and CFOs engage with directly. Pensero's capitalizable output metric runs alongside innovation rate in the same framework, tracking what share of delivery qualifies for capitalization as capital expenditure versus operating expense. For organizations managing R&D cost attribution and [software capitalization](https://pensero.ai/blog/internal-use-software-capitalization), the innovation-versus-maintenance split directly affects what portion of engineering spend is defensible as CapEx, which has real financial statement implications. *The information about Section 174/174A in this article is for informational purposes only and should not be construed as tax advice. Tax treatment of R&E costs depends on specific facts and circumstances, industry classification, and company structure. Organizations should consult with qualified tax professionals, CPAs, or tax counsel before making R&E capitalization or expensing decisions. Pensero provides documentation tools to support tax compliance processes, but cannot provide tax advice or guarantee specific tax treatment outcomes.* ## **Did rework increase? What is actually driving the maintenance burden?** Before you can shift the ratio, you need to understand what is filling it. Maintenance is not a single category, it is several distinct problems that require different responses. **Defect-driven maintenance** is the most visible. Bug fixes, incident responses, and hotfixes absorb engineering capacity in ways that are relatively easy to trace back to their origin: a high-defect-rate delivery period, a rushed release, a codebase area with high knowledge concentration and inadequate review. This type of maintenance is directly reducible by improving quality signals earlier in the delivery cycle. **Rework** is more subtle. Code that ships, gets used, and then gets significantly revised because the original implementation was incomplete or misaligned with actual requirements. Rework shows up as new features or improvements in ticket systems, it is often labeled as enhancement or v2 work, but it is actually paying back a quality debt from the original delivery. Pensero's rework attribution tracks code revisions at the team and individual level, making the hidden rework cost visible without requiring manual classification. **Sustaining work and KTLO (keep the lights on)** is the category that most organizations undercount. Dependency updates, infrastructure maintenance, compliance work, tooling upgrades, and performance optimization all land in this bucket. None of it is glamorous, and all of it is necessary, but the question is how much of it is unavoidable and how much has accumulated because proactive investment in platform quality was deferred in favor of shipping features. Understanding which of these categories is driving your maintenance ratio determines what kind of intervention will actually move it. Reducing defect rate requires quality improvements in the delivery process. Reducing rework requires clearer requirements and tighter feedback loops between product and engineering. Reducing KTLO burden often requires a deliberate platform investment that pays back over time through reduced ongoing maintenance cost. ## **Is AI creating more maintenance than it saves?** This is a question most organizations with significant AI adoption need to ask, and most are not asking it with data. The AI Impact data from Pensero makes the risk concrete. In one customer workspace over 90 days, AI-assisted code reached 39% of merged code and delivered a 1.2x lift in output. But quality tax, the share of PRs consisting of rework, rose to 45.1%, up 13.2 percentage points. AI tools that help engineers ship faster can, if not matched by equivalent review discipline, increase the rework burden that feeds directly into the maintenance ratio. The mechanism is not mysterious. AI-assisted code completion helps engineers reach a shippable state faster. If the review process does not keep pace, if the additional PRs generated by AI adoption are being merged with lower scrutiny because the team is optimizing for velocity, the defect rate and rework rate rise even as the output volume increases. More is shipped, and more of it comes back. This means an organization that uses AI tools to accelerate delivery without tracking the rework impact may find its innovation rate declining even as its total delivery volume increases. The absolute output goes up. The share of that output that is genuinely new value may go down. Pensero surfaces this connection directly: AI adoption, quality tax, rework, and innovation rate sit in the same measurement framework. When AI adoption rises and the quality tax rises in proportion, that is a signal to examine whether the delivery acceleration is translating to sustainable new value or compounding the maintenance burden. ## **How do we compare to similar teams?** Not every organization with a high maintenance ratio has a problem. A mature platform company with a large installed base, significant compliance obligations, and extensive integration surface area will run a structurally higher KTLO burden than a greenfield product team. The question is not whether your maintenance ratio is high in absolute terms, but whether it is high relative to comparable organizations. Pensero Benchmark places innovation rate in percentile rank against the full Pensero customer base, updated weekly. This provides the external reference that distinguishes a structural characteristic from a solvable problem. An organization in the 40th percentile on innovation rate that is a mature enterprise platform may be operating normally. The same percentile for a growth-stage SaaS company is a signal that the technical debt burden is above what similar organizations are carrying. Pensero Calibrate adds the internal comparison: which teams within the organization are running the highest maintenance ratios, and is that distribution what you would expect given the nature of their work? If the platform team is running 60% maintenance while the product team is at 30%, that may reflect a legitimate difference in codebase maturity. If both are running at 60%, there is a broader organizational pattern worth investigating. ## **Frequently Asked Questions** ### **What is a good innovation rate for an engineering team?** There is no universal target because the right ratio depends heavily on the type of product, codebase maturity, and stage of the organization. As a general orientation: growth-stage product companies typically aim for 60-70% or higher on new feature and platform investment, with maintenance and sustaining work below 30-40%. More mature platforms with large installed bases may accept a higher sustaining burden as structurally necessary. What matters more than any specific number is that the ratio is known, benchmarked against real peers, and moving in the intended direction over time. ### **What is KTLO and how does it affect innovation rate?** KTLO stands for Keep the Lights On, the sustaining work required to maintain existing systems without adding new functionality. It includes dependency updates, infrastructure maintenance, security patches, performance optimization, compliance work, and tooling upgrades. KTLO is often undercounted because it is labeled and prioritized as technical work rather than categorized as maintenance in planning systems. When Pensero classifies work items by actual content rather than ticket labels, KTLO tends to account for a larger share of delivery than organizations expect, which is part of why many teams systematically underestimate their true maintenance burden. ### **Why does rework accumulate and how do you reduce it?** Rework accumulates when the original delivery was shipped faster than it was understood, incomplete requirements, insufficient review, AI-generated code accepted without deep scrutiny, or time pressure that compressed the quality gate. It then arrives as follow-on work: enhancements, v2s, or bug fixes that are actually rebuilding something that was not quite right the first time. Reducing rework requires addressing the quality signal at the source: clearer requirements before work begins, review discipline that keeps pace with delivery velocity, and tracking rework attribution by team and individual so the pattern is visible before it becomes a major maintenance driver. ### **How does technical debt relate to the maintenance ratio?** Technical debt is the accumulated cost of past delivery shortcuts, code that works but is hard to maintain, extend, or understand. It drives maintenance burden in two ways: directly, through the ongoing cost of working around fragile or undocumented code; and indirectly, through the higher defect rate that poorly structured code tends to produce over time. Reducing technical debt is a form of maintenance investment that, done deliberately, reduces the ongoing maintenance burden rather than adding to it. Organizations that track innovation rate over time often find that a period of intentional platform investment, which looks like high maintenance in the short term, produces a sustained improvement in innovation rate once the debt is paid down. ### **Can AI tools help shift the ratio toward innovation?** Yes, but only if the quality tax that AI adoption can introduce is managed alongside the velocity benefit. AI coding tools that accelerate feature development will improve the innovation rate if the additional velocity translates to genuinely new value shipped with stable quality. If the acceleration produces higher rework rates, more AI-generated code that needs revision, the maintenance burden grows even as the output volume rises. The organizations that use AI tools to genuinely improve their innovation ratio are those that match AI adoption with review discipline and track both the delivery lift and the quality tax in the same measurement framework. ### **How long does it take to shift from a high-maintenance to a high-innovation ratio?** The timeline depends heavily on what is driving the maintenance burden and what interventions are applied. Ignasi Vegas's organization shifted from 70% to 30% maintenance, but that shift required deliberate investment, clear visibility into where maintenance was coming from, and a sustained commitment to addressing the root causes rather than just the symptoms. Organizations that start measuring the ratio accurately for the first time often find that the first quarter of visibility alone changes behavior, teams that can see their own innovation rate tend to make different prioritization decisions than teams flying blind. Meaningful movement in the ratio typically becomes visible within one to two quarters of continuous measurement and active intervention. # Get months of engineering performance data now Stop deciding on gut feel. Get 90 days of objective data in minutes. [Let's talk](../book-demo) # Get months of engineering performance data now Stop deciding on gut feel. Get 90 days of objective data in minutes. [Let's talk](../book-demo) # Get months of engineering performance data now Stop deciding on gut feel. Get 90 days of objective data in minutes. [Let's talk](../book-demo) [![](https://framerusercontent.com/images/1v1teeWpH0SzUYk5hDKcYFScErY.png?width=180&height=180)](../) © 2026 [Careers](../careers) [Blog](../blog) [Privacy policy](../privacy-policy) [Cookie policy](../cookie-policy) [Terms of service](../terms) [LinkedIn](https://www.linkedin.com/company/penseroai/) [Support](../support) [Security](https://pensero.trust.site/?ph_distinct_id=undefined&ph_session_id=undefined&ph_source=framer_landing) ![](https://framerusercontent.com/images/iXlw4NDLGJLJbTHbLklPOeLqP5o.svg?width=102&height=20) [![](https://framerusercontent.com/images/1v1teeWpH0SzUYk5hDKcYFScErY.png?width=180&height=180)](../) © 2026 [Careers](../careers) [Blog](../blog) [Privacy policy](../privacy-policy) [Cookie policy](../cookie-policy) [Terms of service](../terms) [LinkedIn](https://www.linkedin.com/company/penseroai/) [Support](../support) [Security](https://pensero.trust.site/?ph_distinct_id=undefined&ph_session_id=undefined&ph_source=framer_landing) ![](https://framerusercontent.com/images/iXlw4NDLGJLJbTHbLklPOeLqP5o.svg?width=102&height=20) [![](https://framerusercontent.com/images/1v1teeWpH0SzUYk5hDKcYFScErY.png?width=180&height=180)](../) © 2026 [Careers](../careers) [Blog](../blog) [Privacy policy](../privacy-policy) [Cookie policy](../cookie-policy) [Terms of service](../terms) [LinkedIn](https://www.linkedin.com/company/penseroai/) [Support](../support) [Security](https://pensero.trust.site/?ph_distinct_id=undefined&ph_session_id=undefined&ph_source=framer_landing) ![](https://framerusercontent.com/images/iXlw4NDLGJLJbTHbLklPOeLqP5o.svg?width=102&height=20)