Engineering effectiveness is reaching a turning point.
Under scrutiny and pressure to do more with less, engineering leaders in 2024 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) refers to "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.
Over my three-ish decades of working with engineering teams, I can testify that the question of how to allocate developer time between tech debt and new value 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 inherent 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.
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 effectiveness (having the desired impact). To achieve the latter, what comes before performance — both in importance and in sequence — is transparency and alignment.
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.
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, 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.
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.
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.
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 that 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.