In a small software business with a single unified engineering team, it can be very challenging to categorize the work being done.

I was recently challenged to quantify my team’s capacity for “strategic roadmap” vs. everything else we need to do. The first problem: what’s “strategic?” I found it easiest to work from the opposite direction. If we can filter out everything that isn’t in service to the product-defined roadmap, we’ll see it more clearly.

The first step was filtering out work that clearly wasn’t part of the roadmap because it was a different type of work. I called this “non-roadmap” and there’s 2 types. The first is “outside requests” that come from somewhere other than Product (like Support, Success, or Sales). The second is pure “maintenance” which I narrowly define as updating a dependency (libraries, platforms, deprecated APIs) or non-product component (like CI or a specific environment, e.g. updating a Docker container). Since we use Jira, I used ticket types to clearly define and separate these in a way that worked for us.

But what about “everything else” engineering does, like bugs or incident response?

The second step was filtering out “remedial” work. Some folks call this “engineering roadmap” but I don’t like that framing since it sounds like engineering is using its prerogative, when this work is actually forced by business needs. Like non-roadmap, I think there are 2 types of remedial work, too: customer experience remedies, and engineering remedies. The former are things like fixes to visual shortcomings, UX challenges, or accessibility improvements. The latter are fixes to security flaws, incident responses, compliance needs, feature defects, adding retroactive test coverage, and addressing observability challenges. Since we use Jira, we created a custom “Deficiency” dropdown with these values to track & filter them.

What’s left? Strategic roadmap. We can put this into 2 buckets as well. First, feature work, which is anything with value to the customer. Second, quality assurance work, which is anything enabling feature work to be done safely and expeditiously.

But what about refactoring code or writing tests as you code? That’s strategic roadmap, because it’s quality assurance! You’re doing those things in service to the business objectives, not because you felt a certain way about the code (or at least, I hope so). The biggest trap you could possible set for yourself in measuring strategic roadmap capacity is to separate the work to refine a system (so that it can continue be managed & built atop by the existing team at a similar or better pace) from value you are delivering to the customer. It’s the same problem! You have to deliver value and maintain capacity in harmony or you risk scuttling the business.

The leading cause of legacy code is developer stress. Developers, placed under pressure to deliver a solution on an unrealistic timeframe or budget, pushed to the limit, produce code that eventually becomes legacy code. These developers often don’t intend to create legacy code; they genuinely wish to solve the problem at hand, and hope to provide a reasonable, rational solution to whatever problem they’ve been given.

—Sarah Savage

Don’t separate safety from your strategy.

Looking at it as a rubric can make it a little clearer:

Having these 3 buckets instead of just 2 (roadmap vs not) makes the rationale a little clearer and the capacity measurement more nuanced, which leads to more constructive conversations about capacity. “Why can’t you execute on the strategic roadmap faster?” is an impossible question if you can’t look at the individual forces pushing you away from that work and enumerate the tradeoffs that would come from not doing it.

Here’s the summary outline:

1. Non-Roadmap
   • Non-product requests: Support escalations, sales requests, data requests.
   • Maintenance: Updates to dependencies (libraries, WP, plugins, external platforms & APIs) and non-app components (CI, server env, localhost).
2. Remedial Roadmap
   • Customer experience remedy: Visual, UX, or accessibility refinement.
   • Engineering remedy: Feature defects, security flaws, incident response, compliance, observability, & retroactive tests.
3. Strategic Roadmap
   • Features: Adding value directly for the customer.
   • Quality assurance work: Safety measures tied to delivery, like refactoring and TDD.

I found it very helpful to find the patterns and cycles to how my team works by using these categories and hope you’re able to get similar insights from it.