Engineering effectiveness is reaching a turning point.
Under scrutiny and pressure to do more with less, engineering leaders in 2025 face a tough challenge: ship more features, deliver more business value, reduce technical debt, and keep everything running — and do it all yesterday.
One such contender for time and resources is 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?
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). To achieve the latter, what comes before performance — both in importance and in sequence — is transparency and alignment.
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.
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.
