TBM 234: Maintenance, KTLO, and BAU

I've always been bothered by how teams use words and phrases like maintenance, keeping the lights on (KTLO), and business as usual. I get what they mean, but there always seems to be a stigma around this work.

This is problematic because work in this category is often the highest leverage/value work a team might tackle.

"Maintenance"

When we maintain a car—oil changes, tire rotations, etc.—we aim to keep the car running smoothly and safely. Even the best-designed and constructed car will deteriorate and become unsafe to drive without regular maintenance. Maintenance costs money, but you're lowering the overall cost of owning the vehicle in the long run, and hopefully increasing the car's resale value.

When we maintain a car, we don't normally fix bugs, apply patches, optimize performance, check for compatibility, remove features, refactor, and incorporate user feedback. Why? Car maintenance revolves around physical wear and tear, degradation of materials over time, and the occasional replacement of parts with a limited lifespan. These actions don't "fix" or "improve" the car but rather preserve its current state and prolong its effective lifespan.

Car "bugs" involve manufacturer recalls and waiting for the next version of the car.

Gardening

In a sense, software is much more like a garden than a mechanical entity like a car. We plant the initial seeds (start designing and building), water and nurture it (make updates and enhance features), and periodically have to prune (refactor) and weed (remove bugs and vulnerabilities). A product requires constant attention to grow and adapt to its environment (user needs, technological changes, and market trends). It's an ongoing process of growth, adaptation, and care.

Applicable concepts: seeding, sowing, weeding, watering, pruning, cultivation, composting, harvesting, hardening off, propagating, rotating, aeration, grafting, trellising, thinning, etc.

Words and Buckets

But the words we use in software can carry the legacy weight of physical products like cars and factories.

In software, we use terms like "maintenance," "keep the lights on" (KTLO), and "business as usual." And differentiate this from work that is considered "innovative," "strategic," "value-added," or "forward-looking." This differentiation often stems from a perceived dichotomy between routine operations that ensure stability and creative endeavors that drive future value.

• Routine operations that ensure stability preserve the status quo, manage risk, and address immediate operational needs. The system runs without interruptions, bugs are fixed, performance issues are addressed, and security vulnerabilities are patched. The focus: reliability and "meeting expectations."

• Efforts that drive future value include new features, new technologies, enhancing the product, expanding capabilities, growth, user acquisition, and capturing new revenue streams.

Teams routinely try to manage the "mix" between these categories—putting them in discreet buckets and mandating % allocations. The simple balancing-act logic goes something like this:

"Balancing KTLO tasks with innovation is like juggling short-term necessities and long-term ambitions. Too much focus on today, and we might miss tomorrow's opportunities. But neglect the basics, and there might not be a tomorrow for our product."

Fair enough. The challenge is that these aren't discreet buckets, yet the words we use (and buckets we use) tend to reinforce unhelpful simplicity on what is way more nuanced.

Consider how:

• A well-maintained codebase can be a huge force multiplier for innovation.

• A string of "minor improvements" can make a product super sticky and a joy to use

• KTLO can be either extremely low leverage (the equivalent of restarting a machine) or extremely high leverage (automating away routine tasks for a whole company)

• Shiny new products and features get everyone excited but frequently fall flat. New revenue can be very expensive—there are many ways to make a quarter.

You just can't fit this into a simple model.

Finance & New Stuff

Oversimplified buckets have very serious financial and accounting implications. Most conspicuously, companies capitalize "new stuff" or "major enhancements" and recognize those efforts as an asset on the balance sheet. 

Team A makes dozens of small enhancements over the year (and responds to feedback and iterates). Team A's net impact may be far greater than Team B, who pitches a big-bang, 12-month flashy "project". Yet Team B will have better luck capitalizing their work. There's a huge incentive around premature convergence and success theater. Everyone wants to be a "profit center".

Before you know it, there is a stigma around the percentage of capacity going to the arbitrary maintenance or KTLO bucket. High percentage = bad, low percentage = good. The simplification misses tons of potentially valuable nuance.

Finance tends to find less tangible (and longer materializing) benefits more challenging because these benefits are harder to quantify, predict, and incorporate into financial models. Due to this challenge, there is a tendency to over-index on short-term, easily quantifiable metrics and ignore long-term value creation, strategic potential, and intangible assets.

This isn't finance's fault. It boils down to having a solid product strategy and a compelling, financially grounded model. 

Suggestions…

So what would a better model look like that didn't (in many cases) inadvertently marginalize certain types of work or create perverse incentives that adversely impact the future success of the team and product? What would it need to accommodate or surface?

This is not an exhaustive list of dimensions (or a truly serious attempt at a model), but the first factors that come to mind:

Reactive ←→ Shaping

• Reactive: Immediate and driven by current needs, problems, or unexpected demands.

• Responsive: While still reacting to the present, there's an element of using past experience to guide present action, with a touch of foresight to predict very short-term future needs.

• Proactive: Preemptive, anticipating potential issues and addressing them before they become actual problems, aiming to prevent foreseeable issues.

• Shaping: Beyond just anticipation, influencing and dictating the future landscape. Creating or changing future conditions to align with a desired state.

Mitigative ←→ Exponential

• Mitigative: Slowing or mitigating decline, degradation, or loss and reducing negative effects or deterioration rates.

• Additive: Linear growth, where results are seen in straightforward additions. Every new unit of effort contributes a predictable and constant increment to the outcome.

• Multiplicative: Each unit of effort multiplies (compounds) the previous results.

• Exponential: Network effects, nonlinear dynamics, and reinforcing feedback loops.

Degradation ←→ Transformation

• Degradation: Accepting a decline or wear of the current state, system, or product. It recognizes that some elements can erode, become obsolete, or fade without immediate intervention. Not doing anything is a choice.

• Preservation: Maintain the status quo. The current state, system, or product remains functional and consistent.

• Adaptation: Modifying or tweaking the existing system, product, or process based on feedback, changing conditions, or environmental shifts. Evolving in response to current demands while retaining the core identity.

• Transformation: Radical change. Complete overhauls, pivoting, or introducing new paradigms that might render the original state or product obsolete.

Direct Impact ←→ Indirect Impact

• Direct: Immediate and tangible Impact on revenue or costs.

• Tangible: Don't have an immediate effect, but benefits can be seen in the short to medium term and are closely tied to specific financial outcomes.

• Deferred: Benefits require more steps or a longer time frame to translate to financial gains or losses yet still have a clear path to impacting the bottom line.

• Indirect: Activities that influence the bottom line in more intangible or longer-term ways, such as learning, dynamic capabilities, employee morale, etc.

We could probably throw a couple more in to enhance this model, including value curves, bet portfolios, some of the questions here, the risks mentioned here, and leverage and benefit types.

The vital point is that we deal with a continuum, not well-bounded categorizations.

Try this now. Look at work that currently falls under "maintenance" or "keeping the lights on". Using my categories above, or your own categories, categorize the work. Compare work that is highly reactive, mitigative, and preservation-oriented (bordering on degradation) with work that is proactive, multiplicative, and adaptive, but that has deferred or indirect impact. Ask yourself, "What might we work on to reduce the amount of low-leverage work we must do?"

Going back to an image I posted recently, how do you differentiate low leverage work with “immediate” impact on revenue, with high leverage work to protect revenue, reduce costs, and avoid costs (that tends to be indirect or deferred)?

Or… how do you avoid this? It’s a similar idea…