KTLO in Software Development: Best Practices for Leaders

Engineering effectiveness is reaching a watershed moment. 

The rise of advanced dev automation reflects a demand for more code as legacy enterprise companies wake up to find that even they create software now. But despite engineering’s transition from “IT department” to key business differentiator, the era of blank-check tech budgets is over. Every company is realizing that software is a critical driver of business growth, and with great opportunity comes great accountability. 

Facing scrutiny and pressure to do more with less, engineering leaders find themselves in a tough spot in 2024: ship more features, deliver more business value, pay down technical debt, and keep the lights on — and do it all yesterday. 

Playing Time Allocation Tetris

Over my three-ish decades of working with engineering teams, I can testify that the question of how to allocate developer time between KTLO/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 and erodes developer experience 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. 

The Value DORA Can't Measure

Functional organizations need to do both types of work, 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 software delivery metrics like DORA’s lead time, deployment frequency, MTTR, and change failure rate. 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. 

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. 

While I can’t speak to what will work for every business, I’ve 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, 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 KTLO and Tech Debt

After gaining more visibility into how their teams are actually spending their time, many organizations we work with 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 has worked out a solution that 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 KTLO 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 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. 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.