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.)
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.
Accolade increases deployments to production by 205%
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 DevOps metrics. But efficiency and quality metrics don’t tell the whole story. 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 (having the desired impact). Excellence requires optimizing across four interconnected dimensions: 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. The key is treating allocation as a strategic capability, not an operational afterthought.
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? 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.
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 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.
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 (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, clarity is the way through the gauntlet.
Ready to Learn More?
See how Uplevel's time allocation model works to categorize KTLO work into the right buckets automatically.
