How much should we invest in maintenance versus features to keep our technical debt under control?

Some variation of this questions come up in many of our discussions with CTOs and VPs of Engineering, and for good reasons. There’s a tension between building new things and technical sustainably, and it’s part of an engineering manager’s mission to find the balance appropriate balance for their context.

We often see companies allocating a fixed percentage of the team’s capacity to (loosely defined) “technical work”. While this approach is straightforward and sensible, it begs the question of the right level of allocation. We also often see companies working in chunks, alternating between periods of intense features development and periods of “cleanup”. This approach tends to be harder on engineers, and is much more prone to perpetually delaying technical work.

In this post we’ll explore a practical approach to balancing features work and technical sustainability, and how Echoes can help you on this journey.

A practical approach to managing technical debt

The business case for technical work

Technical maintenance work is opaque to business stakeholders who perceive these efforts as having no observable effects to anyone but the engineers. Therefore, the first key point about technical debt is to collectively recognize it as a business concern. The directly observable consequences of a high level of debt are a high time to market and a low quality of deliverables, which is not something that any company wants, and which should be communicated as such.

Having framed the problem as a business concern, how do we now scope and prioritize technical work? The approach we recommend is to treat your technical standards as any other desirable business outcome. However, just like any other desirable business outcomes, there’s only so much we can do and there’s a balance to be found between the efforts and their expected benefits.

Scoping technical work

Technical maintenance work is also perceived as a bottomless pit at which we could throw an infinite amount of engineering resources. And to be fair, this is mostly true: there’s no limit to how much things could be improved, better designed, or made more performant.

This is where metrics come in handy. The State of DevOps research program and the Accelerate book have given us a solid starting point for measuring software delivery performance. Accelerate notably suggests four well known metrics: lead time, deployment frequency, mean time to restore, and change fail percentage.

Metrics help us draw the line of what’s desirable for us as an engineering organization. It turns maintenance work from the perceived bottomless pit into the efforts we must invest to preserve the standards of time to market and quality that are appropriate for our team and for our business.

Setting the bar

Setting the appropriate bar is not a trivial thing to do. It depends, among other things, on the company’s stage, the team’s scope, and the engineering culture you want to have. This could be the topic of an entire post of its own, and for the purpose of this recipe we’ll limit ourselves to this shameful shortcut: there is no “one size fits all”.

• You can’t set the same expectations for greenfield projects and teams in charge of long-lived production code.

• You shouldn’t set the same expectations in a startup than in a large enterprise running a widely adopted product.

• Your criteria will depend on who you want to be as an engineering organizations. Some massively successful companies ship early unstable products and test what works. Other massively successful companies ship perfectly polished products less often.

How Echoes can help you manage technical work

1. Model technical merits as a desirable outcomes

Echoes let’s you define the outcomes that matter to you as a company. As a starting point, Echoes suggests the following:

• Customer value: the end-user visible changes intended to create customer value.

• Risk mitigation: changes intended at mitigating risks.

• Throughput: changes intended at preserving our own ability to evolve the software.

Echoes generate matching labels on all of your GitHub or GitLab repositories. Those labels should be used by engineers to tag pull requests with their intent. In the context of this post, we can tag technical work with the echoes/intent: throughput label.

This expresses that the corresponding changes are meant to preserve our software delivery standards. Tagging a pull request with labels takes seconds and can be easily changed at any time.

Echoes strength here is how engineer-friendly it is: it provides an effortless way to connect work to purpose, without having to file meta-work. Echoes additionally supports initiatives to describe scoped efforts that typically span across multiple weeks or months and across multiple teams. For example, an initiative could represent a migration effort or the decommissioning of a unreliable service, all while capturing that the purpose of the initiative is to contribute to your throughput. Initiatives get their own dedicated label (e.g., echoes/initiative: replatforming), therefore making tagging even more straightforward for engineers.

2. Measure efforts invested in technical work

Echoes labels are used to surface the reality of efforts of engineers at the team level, and will reveal how much efforts are invested into preserving your throughput, on a week to week, sprint to sprint, or month to month basis.

Additionally you’ll be able to visualize easily how each teams allocate their efforts into throughput.

What makes Echoes special here is that:

• Echoes surfaces the reality of the teams’ efforts. Companies sometimes attempt to leverage the content of roadmap documents or ticketing systems to analyze the activity, however a significant amount of technical work falls into the “invisible efforts” necessary to keep the lights on while not being tracked anywhere.

• Echoes lets you aggregate efforts across teams, regardless of their development process and their choice of tools, and regardless of the size and complexity of the organization.

3. Connecting efforts to observable metrics

Understanding how much efforts we spend into throughput is one aspect of the answer, but the other one if of course how much we should spend. This is where confronting efforts to observable metrics will help you.

Echoes lets you connect desired outcomes to observable results of your choice: in this case, we can use the builtin metric of lead time and associate it to our “throughput” outcome. The strength of Echoes here is that it doesn’t consider efforts and metrics in isolation, but examines how the two are connected to reveal our impact. There’s a lot more we could say about metrics and custom metrics here, but we’ll keep it simple for the purpose of this post.

Conclusion

We hope this post has inspired you to experiment with new ways of managing technical debt. As with most things worth doing, sustainable development is better framed as a desirable business outcome onto which you can set thresholds appropriate for your particular context. Echoes is your ideal companion to follow and fine tune how to prioritize technical work continuously before it’s too late.