--- title: "What Is KTLO in Software Development? | Uplevel" description: "KTLO (keeping the lights on) is the maintenance work that keeps systems running — and AI is making it harder to do. Here's what leaders should know." type: blog version: 2 version_id: "a2adb700-2aeb-4e1a-8641-2ff6affc2f7a" generated_at: "2026-06-26T00:53:27.310Z" author: "Joe Levy" date_published: "2025-08-13T04:00:00.000Z" date_modified: "2026-06-26T00:52:20.421Z" language: en reading_time: "22 min" word_count: 4230 keywords: ["What Is KTLO in Software Development?", "Playing time allocation Tetris", "Frequently Asked Questions", "Stay up to date"] url: "https://uplevelteam.com/blog/ktlo-in-software-development" --- # What Is KTLO in Software Development? | Uplevel > KTLO (keeping the lights on) is the maintenance work that keeps systems running — and AI is making it harder to do. Here's what leaders should know. ## Key Takeaways - Playing time allocation Tetris - The value DORA can't measure - The hidden cost of poor KTLO allocation - Negotiations and agreements in KTLO - Making the Invisible Visible ## Contents - [Playing time allocation Tetris](#playing-time-allocation-tetris) - [The value DORA can't measure](#the-value-dora-can-t-measure) - [The hidden cost of poor KTLO allocation](#the-hidden-cost-of-poor-ktlo-allocation) - [Negotiations and agreements in KTLO](#negotiations-and-agreements-in-ktlo) - [Making the Invisible Visible](#making-the-invisible-visible) - [How Uplevel Helps Engineering Leaders Manage KTLO](#how-uplevel-helps-engineering-leaders-manage-ktlo) - [Frequently Asked Questions](#frequently-asked-questions) [Back to Resources](https://uplevelteam.com/resources) [Time Allocation](https://uplevelteam.com/blog/tag/time-allocation) Jun 26, 2026 # KTLO in Software Development: Best Practices for Leaders KTLO (keeping the lights on) is the maintenance work that keeps systems running — and AI is making it harder to do. Here's what leaders should know. * * * Engineering effectiveness is reaching a turning point. With AI changing how code gets written and economic pressures demanding efficiency gains, engineering leaders in 2025 face a paradox: deliver more business value with existing resources while maintaining system reliability in an increasingly complex technical landscape. At the center of this challenge sits a fundamental resource allocation decision that every engineering organization must make: how much time to spend on KTLO. KTLO (or KLO) is an acronym that stands for "keeping the lights on"  — the maintenance and support activities that pay down and prevent the buildup of technical debt. It's important work, but the time spent on making sure things are running smoothly is time deliberately *not* spent on innovation or value delivery. The challenge I see many leaders facing is where to strike the balance. ## Playing time allocation Tetris I've worked with engineering teams for three-ish decades, and the question of how to allocate developer time isn't new. Neither is the tension it creates between tech leaders and their business counterparts:  - The business demands “new hotness”: the features that customers will love, so marketing can promote and sales can sell. But they don’t understand why everything is taking so long.  - Engineers accuse the business side of not understanding the true costs and resources involved in quality feature development, and what’s the point of building new hotness if it’s slow, buggy, and unstable? Unsurprisingly, when we interviewed engineering leaders about how they are using AI in 2025, one of their greatest concerns was the constant pressure they feel from executives to leverage AI and move faster, despite very real risks and implementation challenges. The data backs up that concern. Uplevel's research across enterprise engineering teams found that AI adoption often increases KTLO time alongside new value work. AI-generated code moves fast into pipelines, and when testing and review infrastructure isn't ready to absorb the volume, maintenance load climbs. The teams seeing net gains from AI are typically the ones who had already invested in reducing KTLO before they scaled AI usage. There are natural trade-offs between short-term gains and long-term sustainability, and the outcomes of this tension can run the gamut. Shipping new features against business-imposed deadlines creates more debt as teams move on to delivering the next half-built project. But spending too much time on maintenance might mean a six-week rabbit hole of over-optimization that doesn’t deliver business value at all.  [](https://uplevelteam.com/customers/accolade) [ ##### How Accolade Meets Commitments Effectively with Engineering Intelligence ](https://uplevelteam.com/customers/accolade) Learn how Accolade met commitments, increased deployments to production, and increased deep work time with Uplevel engineering intelligence. ## The value DORA can't measure Functional organizations need to both fix bugs *and* deliver value, so it would seem that the obvious answer to doing more with less is just to work more efficiently. (Good luck telling that to your team.) When it comes to measuring engineering performance, leaders often rely on standard [DORA](https://dora.dev/) DevOps metrics. But efficiency and quality metrics [don’t tell the whole story](/blog/why-dora-metrics-are-only-part-of-the-equation). You can ship lots of perfect code all day without delivering anything of value to the business. Performance matters, but it assumes that you’ve already decided as an organization that you’re working on the right things.  There’s a critical difference between engineering performance (efficiency and quality) and engineering excellence[](/blog/engineering-excellence) (having the desired impact). Excellence requires optimizing across [four interconnected dimensions](/resources/engineering-kpis-wave): how teams work together, whether efforts align with business outcomes, sustainable delivery velocity, and environmental factors that enable or constrain productivity. KTLO allocation affects all four areas simultaneously. ## The hidden cost of poor KTLO allocation Poor KTLO allocation creates compounding costs that extend beyond technical debt. Teams spend increasing time on firefighting instead of planned work. Context switching between urgent fixes and feature delivery reduces both productivity and code quality. Worst of all, unclear allocation decisions erode trust between engineering and business stakeholders. According to DORA research, organizations that optimize KTLO allocation report [less unplanned work and significantly higher developer satisfaction scores](https://dora.dev/capabilities/well-being/). The key is treating allocation as a strategic capability, not an operational afterthought. And of course, AI complicates this equation even further. While AI unquestionably accelerates code generation, it can simultaneously increase maintenance overhead through quality issues or technical debt. Organizations need allocation strategies that account for AI's impact on both delivery speed and maintenance burden. ## Negotiations and agreements in KTLO As their accountability grows, engineering leaders need to do the hard work of defining and negotiating for the right allocation for their teams. It’s not easy, especially when business stakeholders don’t understand what it takes to build solid functionality or the value that a project to increase processing speed would bring.  I can’t speak to what will work for every business. But I *have* seen the success our customers have created and I can share what we’ve committed to in our organization.  ### Make time allocation transparent It starts here. Instead of relying on hunches, tech leaders need data-driven insights to reveal how time is being spent on a team level.  Say a team allocates only 11% of their time to KTLO activities, far less than other high-priority investment buckets such as platform globalization (29%) or new features (42%), and even less than the time spent in meetings and responding to Slack messages (18%). This is a great starting point for a conversation about a strategic plan for allocation. ### Choose the right framing for hard conversations The most effective engineering leaders approach KTLO allocation as a business capability discussion rather than a technical decision. Does it feel like [playing politics](/blog/engineering-culture-change)? Maybe, but the alternative is to keep engineering decisions separate from business decisions — and that keeps engineering work divorced from business value. Instead, strong engineering leaders help business stakeholders understand the systemic relationship between maintenance investment and delivery predictability. Take the current challenge of AI. Engineering leaders report that AI accelerates code generation while creating new quality and security concerns. Without clear KTLO allocation frameworks, teams may optimize for AI-assisted feature velocity while neglecting the maintenance work required to sustain that pace. "When you make these decisions, what are the impacts in engineering? What are you giving up? At the end of the day, the business does have to make trade-offs. But they need to understand what the cost of those trade-offs are, and I don't think they always do." Michelle Salvado former VP engineering @ Trellix ### Devote a Portion of Dev Time to Maintenance After gaining more visibility into how their teams are actually spending their time, many organizations set up agreements about [how much time to budget](https://medium.com/engineering-operations/a-framework-for-balancing-and-budgeting-engineering-resourcing-d0cce0e6911c) for KTLO. For example, an agreement might look like “for every new feature we ship, we spend 20% of our time making other features better.”  The goal here is to have transparency and an understanding that new features might take a little longer to deploy on average, but it’s a worthwhile investment not to create bigger problems down the line. ### Integrate KTLO into New Feature Delivery and On-Call Time At Uplevel, our VP of Engineering Chris Riccio builds KTLO work into business as usual. One approach is to dedicate one team member per week to incident response, during which they can support future on-call rotations by adding documentation or more [alerting and logging](https://thenewstack.io/improving-the-on-call-experience-with-alert-management/).  Another is to plan for a bit of maintenance in the components where teams are currently building new value. Adding time into the scope to manage tech debt allows teams to take care of potential problems without unnecessary context switching. For example, as we’re currently adding GitHub Actions as a data source for our platform, we might do a bit of refactoring in our GitHub data connector. Obviously there’s the potential for scope creep, so we agree that the debt needs to be “in the path” of the feature and any work needs to fall under the higher-order bit of delivering on time. It’s a combination of two good principles: the [Boy Scout Rule](https://www.oreilly.com/library/view/97-things-every/9780596809515/ch08.html) (leaving the code better than we find it) and not doing too many things at once. ## Making the Invisible Visible The irony here is that lack of organizational alignment feeds a vicious cycle that sinks both efficiency and effectiveness. To get back on track, engineering leaders call more meetings and demand more status updates. These take away time from delivering new value *and* KTLO. It’s not a matter of acting in bad faith, but a lack of visibility that drives the disconnect. You can’t understand what you can’t see, let alone even start to fix it with edicts like "reduce KTLO and increase value delivery." But as engineering leaders contribute more to org direction and business impact — and navigate new capabilities and risks with AI — clarity is the way through the gauntlet. ## How Uplevel Helps Engineering Leaders Manage KTLO KTLO allocation is a measurement problem before it's a negotiation problem. Engineering leaders who can show exactly where time goes — by team, by work type, by quarter — walk into business conversations with evidence instead of estimates. Uplevel's allocation analysis tracks how engineering time is distributed across new value work, tech debt, and KTLO activities, without requiring perfect Jira hygiene. ML classification handles the categorization automatically. The result is a continuous picture of where capacity is going and how that changes over time — including as AI adoption shifts the mix. For leaders navigating the AI pressure described above, that visibility matters more, not less. Knowing whether AI is reducing KTLO load or adding to it is a different question than knowing whether Copilot adoption is up. Uplevel tracks both. ## Frequently Asked Questions ##### What does KTLO stand for? KTLO stands for "keeping the lights on." In software engineering, it refers to the maintenance, support, and operational work that keeps existing systems running — bug fixes, infrastructure upkeep, dependency updates, and incident response. It is sometimes abbreviated as KLO. ##### What is a reasonable KTLO percentage for engineering teams? Most engineering teams target somewhere between 15% and 30% of total engineering time for KTLO activities, though the right number depends on system complexity, team size, and how much technical debt has accumulated. Teams with older codebases or recent rapid growth often run higher. The goal is a number the team can sustain without eroding delivery capacity for new work. ##### How does AI affect KTLO in software development? AI coding tools can accelerate feature development, but they also generate code that needs to be reviewed, tested, and maintained. For teams without mature CI/CD and testing infrastructure, this increases KTLO load rather than reducing it. Engineering leaders tracking AI impact need visibility into whether time savings from code generation are offset by new maintenance work downstream. ##### How do you measure KTLO time accurately? Accurate KTLO measurement requires categorizing engineering work by type — new value, tech debt, and operational maintenance — consistently over time. Most teams do this through a combination of issue tracking labels and manual tagging, though automated classification tools can reduce the effort significantly and produce more reliable data without depending on perfect ticket hygiene. ##### What is the difference between KTLO and technical debt? Technical debt is the accumulated cost of shortcuts and deferred decisions in the codebase. KTLO is the ongoing work required to keep systems operational and stable. The two overlap: high technical debt tends to increase KTLO load because fragile systems require more maintenance. Reducing technical debt is one of the most reliable ways to reduce KTLO over time. ##### How do engineering leaders justify KTLO time to business stakeholders? The most effective framing connects KTLO investment to delivery predictability. Teams that underinvest in maintenance spend more time in unplanned firefighting, which compresses the time available for feature work and makes timelines harder to forecast. Showing stakeholders the ratio of planned to unplanned work — and how that ratio changes when KTLO is adequately resourced — tends to land better than abstract arguments about technical health. Table of Contents - Playing time allocation Tetris - The value DORA can't measure - The hidden cost of poor KTLO allocation - Negotiations and agreements in KTLO - Making the Invisible Visible - How Uplevel Helps Engineering Leaders Manage KTLO - Frequently Asked Questions [](https://uplevelteam.com/blog/author/joe-levy) [ ### Joe Levy ](https://uplevelteam.com/blog/author/joe-levy) Joe Levy is CEO and co-founder at Uplevel, an engineering intelligence platform that helps enterprise tech leaders maximize efficiency, effectiveness, and team performance. Formerly at Microsoft and Accenture and a veteran of product, engineering, and go-to-market teams, Joe is passionate about giving software development organizations the visibility they need to make confident, reliable decisions. ## Skip the demo. Get real answers on how to maximize AI impact. Take our 10-minute StackUp diagnostic first. Get benchmarked insights on your AI trajectory, then talk to us about the results if it makes sense. [](https://uplevelteam.com/stackup) ## Related Resources on Engineering Alignment Engineering Alignment #### How Engineering Leaders Get Executive Buy-In Get executive buy-in on technical decisions by learning how to speak in the language your business stakeholders want to hear.  #### KTLO in Software Development: Best Practices for Leaders Allocating time for KTLO in software engineering is a challenge for engineering leaders. Here are some techniques we've seen succeed at Uplevel. #### How Braze Sustains Continuous Value Delivery Braze's data-backed, quantitative approach to allocating engineering resources --- ## Frequently Asked Questions ### What does KTLO stand for? KTLO stands for "keeping the lights on." In software engineering, it refers to the maintenance, support, and operational work that keeps existing systems running — bug fixes, infrastructure upkeep, dependency updates, and incident response. It is sometimes abbreviated as KLO. KTLO stands for "keeping the lights on." In software engineering, it refers to the maintenance, support, and operational work that keeps existing systems running — bug fixes, infrastructure upkeep, dependency updates, and incident response. It is sometimes abbreviated as KLO. What is a reasonable KTLO percentage for engineering teams? ### What is a reasonable KTLO percentage for engineering teams? Most engineering teams target somewhere between 15% and 30% of total engineering time for KTLO activities, though the right number depends on system complexity, team size, and how much technical debt has accumulated. Teams with older codebases or recent rapid growth often run higher. The goal is a number the team can sustain without eroding delivery capacity for new work. Most engineering teams target somewhere between 15% and 30% of total engineering time for KTLO activities, though the right number depends on system complexity, team size, and how much technical debt has accumulated. Teams with older codebases or recent rapid growth often run higher. The goal is a number the team can sustain without eroding delivery capacity for new work. How does AI affect KTLO in software development? ### How does AI affect KTLO in software development? AI coding tools can accelerate feature development, but they also generate code that needs to be reviewed, tested, and maintained. For teams without mature CI/CD and testing infrastructure, this increases KTLO load rather than reducing it. Engineering leaders tracking AI impact need visibility into whether time savings from code generation are offset by new maintenance work downstream. AI coding tools can accelerate feature development, but they also generate code that needs to be reviewed, tested, and maintained. For teams without mature CI/CD and testing infrastructure, this increases KTLO load rather than reducing it. Engineering leaders tracking AI impact need visibility into whether time savings from code generation are offset by new maintenance work downstream. How do you measure KTLO time accurately? ### How do you measure KTLO time accurately? Accurate KTLO measurement requires categorizing engineering work by type — new value, tech debt, and operational maintenance — consistently over time. Most teams do this through a combination of issue tracking labels and manual tagging, though automated classification tools can reduce the effort significantly and produce more reliable data without depending on perfect ticket hygiene. Accurate KTLO measurement requires categorizing engineering work by type — new value, tech debt, and operational maintenance — consistently over time. Most teams do this through a combination of issue tracking labels and manual tagging, though automated classification tools can reduce the effort significantly and produce more reliable data without depending on perfect ticket hygiene. What is the difference between KTLO and technical debt? ### What is the difference between KTLO and technical debt? Technical debt is the accumulated cost of shortcuts and deferred decisions in the codebase. KTLO is the ongoing work required to keep systems operational and stable. The two overlap: high technical debt tends to increase KTLO load because fragile systems require more maintenance. Reducing technical debt is one of the most reliable ways to reduce KTLO over time. Technical debt is the accumulated cost of shortcuts and deferred decisions in the codebase. KTLO is the ongoing work required to keep systems operational and stable. The two overlap: high technical debt tends to increase KTLO load because fragile systems require more maintenance. Reducing technical debt is one of the most reliable ways to reduce KTLO over time. How do engineering leaders justify KTLO time to business stakeholders? ### How do engineering leaders justify KTLO time to business stakeholders? The most effective framing connects KTLO investment to delivery predictability. Teams that underinvest in maintenance spend more time in unplanned firefighting, which compresses the time available for feature work and makes timelines harder to forecast. Showing stakeholders the ratio of planned to unplanned work — and how that ratio changes when KTLO is adequately resourced — tends to land better than abstract arguments about technical health. The most effective framing connects KTLO investment to delivery predictability. Teams that underinvest in maintenance spend more time in unplanned firefighting, which compresses the time available for feature work and makes timelines harder to forecast. Showing stakeholders the ratio of planned to unplanned work — and how that ratio changes when KTLO is adequately resourced — tends to land better than abstract arguments about technical health. --- ## About This Content **Source:** [What Is KTLO in Software Development? | Uplevel](https://uplevelteam.com/blog/ktlo-in-software-development) **Author:** Joe Levy **Published:** August 13, 2025 *This content is provided for informational purposes. Please visit the original source for the most up-to-date information.*