Engineering Leader’s Guide: Tech Debt vs Product Roadmap (How High-Performing Teams Make the Tradeoff)

Sometimes our product glasses can cause us to neglect the basics

A common complaint between engineering and product teams is where to prioritize tech debt? Product teams want to ship features, and engineering teams may feel pressure to ship too fast and incur debt. Thus, they want to know when they'll be able to "pay down" some of this debt.

The broader issue is when you do infrastructure work and when you do product work.

First, let's all get on the same page about how you ought to be doing product work.

How to Prioritize Product Work

Prioritizing product work is surprisingly easy, so long as you have access to two key sources of information: an estimate of the value of a project and an estimate of the effort of a project.

I know a lot of product folks are probably screaming about how, yes, finally someone agrees that those damned engineers need to give estimates.

But let ye without sin cast the first stone. Are you doing value estimates? Do you have any idea how much any particular feature is worth?

How Most Product Work is Prioritized

A lot of smaller shops work in the following way: the founder or other big important person says, "this is the next priority," or worse, "this is the roadmap." And that's that.

There is no reason for effort estimates here, because they won't change anything, and generating them takes effort. Estimates for effort in this sort of static "I know best" roadmap are used almost solely to beat engineers over the head with. If they estimate too long, the boss bullies them into committing to something smaller. And when they do estimate something smaller, suddenly the estimate becomes a deadline that we "absolutely cannot miss."

There's no use for a product department in this sort of organization. If you are a product person and this is how priorities are done in your org, congrats, you're just a hired gun to scream at engineers for someone else.

Why Estimates are Hard

Let's say you are lucky and avoided the above scenario. "How am I supposed to know how much money anything makes?!" you might say.

You don't have to. You certainly don't have to get it exactly right. Engineers don't know how long something will take either. Maybe this is your cue to understand how hard the estimation problem is, rather than constantly complaining that engineers are so bad at it.

Talk to your sales folks, get an idea of what clients are asking for, how much "money" they might be willing to pay (These are always wildly inflated, but they're still useful!)

Talk to marketing, talk to client success. Yes, talk to the C-levels who have a more strategic view. Go to trade shows. Absorb what's important and what's not.

Understand the product development cycle and Net Present Value — you won't get the full value of a project up front; we all know that. Revenue grows over time.

These are the mental models to make a best guess. And just like engineering, the next step is to measure how well your best guess did.

Very few of you are actually estimating the value of any project. Even fewer are tracking what past projects made! You're flying blind! Business is not that hard of a problem!

Ultimately, you do not need a perfect idea of what a feature might be worth, but the methods above can help you get a ballpark figure. All you actually need is an ordering of which projects are likely more valuable than others.

In engineering, at this high level, we often use "T-shirt sizes" to create a rough ordering. XL, L, M, and S are your options.

You don't have to know that Project X will net $3.4MM over its lifetime.

You don't have to know that Project X is strictly more valuable than Project Y.

You just have to know that Project X is likely an XL value, and Project Y is likely an L value.

So yeah, have conversations with stakeholders. Get monetary guesses and use financial methods. Track your accuracy and work to improve. But ultimately, you don't need to be perfect for this to work. You just need a rough ranking of what is more valuable than what. All the other analysis is justification for why you put it in the bucket you did.

And finally: if you find out you put something in the wrong bucket... then FUCKING CHANGE THE BUCKET! It isn't the end of the world to miscategorize something. You might even change the bucket two weeks into a project when discovery has shown this isn't an XL project, it's an L project. And that change might nix the project, at least in the short term.

That's good. That isn't failure. The measure of a product manager (and you can use this as a KPI) is:

• The value they generate per engineering unit of effort

• How accurate are their estimates of value

Nuking a project that won't deliver big bucks so you can start on a project that will, that's solid product thinking.

Putting it All Together

You get your T-shirt sizes of value together, and engineering goes over the same list and gets their T-shirt sizes of effort. Now, your prioritized backlog is dividing value by effort. This is equivalent to your ROI estimate.

That is how you should prioritize all things. Always try to turn any decision into an estimate of ROI.

How to Value Infrastructure Work

Now that we've gotten "how to prioritize product work" out of the way, we can start looking at how to fit infrastructure work into this same system.

We'll want an ROI estimate as the output. That will allow us to compare infrastructure and product projects directly.

We need the numerator and denominator in the same units. Effort is trivial here. The problem is actually how to estimate value. Value for product is future revenue. What is value for infrastructure?

It's NOT Cost Savings!

Most tech companies are trying to grow revenue. Growing revenue and cutting costs are diametrically opposed strategies that are incompatible. It's the equivalent of saying you're going to be a brand leader with a massive advertising budget while also focusing on a particular client niche. It's one or the other, buddy. Big sales budgets to build trust with specific clients compete for dollars against big advertising budgets to throw leaflets out of airplanes. You can't do both. (To reiterate, the business is not a hard problem. Why do you keep making it a hard problem?)

If you value your infrastructure work for its cost savings, first of all, it will rarely compete with projected revenue growth, because revenue growth is so much larger than cost savings. So you'll under-prioritize infrastructure work. And second, poorly executed cost savings will often kneecap revenue growth.

Cost savings reduce unneeded resources. It looks for efficiencies — more local output per unit of local input. It nearly always undercounts hits to revenue (switching to a cheaper vendor, for instance, might piss off your customers, but that is never included in the cost-savings estimate!)

Revenue growth often utilizes unneeded resources to find new things to sell. It looks for effectiveness — more global output per unit of global input.

What is it then?

If not cost savings, what do we use as the numerator? It has to be directly comparable to the value from our product calculations. A lot of folks assume cost savings, because you can convert dollars to dollars.

The value of any particular infrastructure project is future value. Infrastructure is an investment that pays dividends in productivity. In other words, an infrastructure project needs to be valued by how much cheaper it makes all future product projects. And that's an easy comparison to make. Do you want this product project prioritized today, or this infrastructure project that will enable two product projects in a year?

Value infrastructure projects in terms of developer productivity. And developer productivity can be turned right back into value by assuming you'll get your average running value per unit of effort going forward.

Infrastructure Work: 3 Ways

Top Down: The Architecture Group

Let's dive into a specific example of how you can roll this out concretely. This tactic is also the easiest to understand and trust.

Step 1. Product goes through the current brainstormed list of ideas, and guesses at a T-shirt size of value.

Step 2. Engineering goes through the same list and guesses at the T-shirt sizes of effort.

Step 3. Prioritize the backlog by Value over Effort. Assign out tasks. Ideally, you're doing your XL value for your S effort projects.

Step 4. Another round of engineering review. In this case, they look at your XL value for M effort projects. For each one, they're brainstorming what architectural improvements might turn that M effort into an S effort.

Step 5. After generating that list of infrastructure ideas, they look for patterns. Perhaps introducing a new tool would shrink 4 or 5 XL Value/M effort projects into S effort projects.

If you pursue any of these ideas, it changes the priority list. Remember, we're going after the XL value for S efforts first. And we can value all those projects and even estimate how long it will take by measuring. Thus, if we throw an infrastructure project into the mix that makes many things cheaper, we can easily model a new possible future backlog enabled by that infrastructure change.

Each infra project proposed generates a new possible future backlog. And those backlogs can all be compared! That's how you get your value estimate. It unlocks new XL value for S effort, and you can add it all up and assign that value to the infra project (albeit discounted into the future). Remember, practice your NPV calculations.

This tactic is the easiest to justify any particular value. It's also one of the easiest to get up and going quickly, and it flows very directly with your product process. In software terms, this is "profile-guided optimization" -- it identifies revenue-generation bottlenecks and prioritizes them.

It also works recursively. Any list of infra projects can be valued by how much faster they might make future product projects. But you can go one step further, and for every infra project, you might again find patterns that would make those projects faster. This naturally breaks large projects into smaller ones, while capturing value along the way. Maybe before you add a new tool, you discover that upgrading your versions of other key tools is both required and beneficial in and of itself.

The downside is that the list of ideas to turn M efforts into S efforts may run dry. You can, of course, go up the chain into L efforts into M efforts, but that's the equivalent of just accepting slower growth. If a product project has an infra project that will speed it up, but that infra project only speeds up that one product project, then we're really just splitting a single project into two. Multiple product projects will use a good infra project. And we also want to assume that at least some of these infra projects themselves will be S effort, otherwise, they're probably not worth it. Thus, this well goes dry quickly.

Beyond brainstorming good product ideas, the only way to ensure growth is to continue improving developer productivity. And while the architecture group can get many of the best ideas, it is a potentially limited resource.

We need other ways to keep growing.

Bottoms Up: DevEx

DevEx is a more advanced technique. In this, instead of your top engineers brainstorming infra projects that can potentially speed up future products, your product team helps brainstorm infra projects to speed up developers now.

The benefit is the same, increased productivity, but the methods are different.

In the DevEx approach, you create an internal team of developers. They are still built like a product team. But their client isn't your external clients; they're your internal developers. They use product skills like interviews, surveys, timing studies, ethnography, and other research methods to identify what is slowing developers down, and they use design thinking to come up with ways to fix it.

They have engineers on their team. Remember, this is like any other product team.

So they can test tools, build reusable code, and suggest process or organizational changes as potential solutions.

They're harder to measure, though. Ideally, by looking at a people-oriented breakdown of what's slowing down the org rather than a purely product/infra-focused view, they find a lot of "cross-cutting concerns" that your architecture group will miss.

Each of their projects may yield lower productivity than the architecture approach. But their projects will be more general in application. They won't speed up "just these three future products" by moving an M effort to an S effort. They'll speed up all future projects by 1-2% per cycle.

That adds up.

They complement architecture teams well by identifying and addressing different sources of developer productivity.

The main bottleneck in a good DevEx team will be the quality of the product manager you have, just like the main bottleneck in the Architecture group will be the quality of the engineer(s) you can sit in the group. You can take any current product team and flex them into a DevEx team, either for a short stint or permanently. But your success there will depend entirely on how well that product manager can switch clients.

Software-wise, DevEx is like a new global compiler optimization being rolled out. It speeds things up a little. And over time, they add up.

The downside is now the missing middle. With the architects finding big new codebases to develop and the DevEx team introducing new tools and processes to improve engagement and productivity, all the little code changes that are too small for the architects to notice and too tactical for the DevEx team to focus on get ignored.

Middle Out: "Second Seashell"

To tackle these, I introduce the "Second Seashell" of work.

I allude to the "Three Seashells" throughout this blog, my newsletter, and my coaching sessions. It's a method I developed based on Dan Pink's book, "Drive." It's a way to ensure team members get a sense of purpose, autonomy, and mastery — what people seek in a good, fulfilling job beyond extrinsic motivators.

The first seashell looks to provide purpose, and primarily relates to how you manage your product roadmap and product process.

The third seashell looks to provide mastery, and is about how you handle training, coaching, expertise, and promotions.

The second seashell is how you provide a sense of autonomy. We'll get into it now.

There are a few key insights that drive the second seashell pattern that hit these "small, tactical" changes across dozens of code bases that your Architecture team and DevEx team will not pick up.

One Team One Project

We try to limit the number of product projects per cross-functional team to one. This makes things easy to estimate, predict, and understand. Adding more projects to a team is just putting more cars on the highway. It might look like you're doing more work, but all you've really done is create a traffic jam.

Sticking to one project might create some slack. Ideally, you fill that slack with swarming. Pair idle devs with busy devs. Over time, this will naturally build your skill sets towards the local bottleneck.

But even this isn't perfect. There's overhead to good swarming. This is where I talk about a "brick and mortar" metaphor. Your product teams can be the bricks in your strategy, but trying to fill every hour of every day with product work is impossible to do well and micro-managey as hell.

You're going to have some leftover slack. Second seashell work is a standing order to fill that slack. Instead of trying to centrally plan every hour of every day, you let the developer fill in the rest. This is the mortar that sticks the bricks together.

The Customer is the Developer

What is something an individual developer is qualified to both prioritize (they know the value) and execute themselves (they know how to do it)? Because, with the second seashell, you can't assume a team is available to work. These are individuals (partly why it exercises autonomy). They are the spare hours of spare days while the team is knocking out their main projects. These devs' availability won't all align, and you can't assume they will.

Turns out these devs know exactly what bugs them in the codebase and are often equipped to fix them.

Second seashell is refactoring time. It doesn't require central planning. A centrally planned roadmap of refactoring isn't going to be that much better than a decentralized emergent plan, and it will be worth less once you account for the crazy amounts of overhead it takes to manage every single last hour.

Second seashell is not developers doing whatever they want. It's still focused on the firm's goals, just in terms of how tech debt may be holding them back. By empowering developers to handle issues themselves during downtime, they can subvert (in a good way) the priorities of the Architecture and DevEx teams. That is empowering: to go and immediately resolve their problems without waiting for permission.

The types of tasks a developer can do during second seashell time are precisely the ones that fall through the cracks of the Architecture and DevEx approaches. And the resources required to do second seashell are... well, free. It's too expensive to try and schedule this time, and it creates goodwill and engagement to just give it back to devs, with a loose mission to spruce the place up.

You can do better here by spreading product and design thinking. The more an individual developer understands how to think like a product manager, the more effective they'll be all around. But it will, in particular, make them more effective at second seashell, as they'll be less prone to gold-plating something and more likely to diagnose the real problem and solution.

The second seashell philosophy can be expanded into a complete code ownership/stewardship system and linked to your promotion and performance review process. That's beyond the scope of what we're talking about here, but suffice it to say, there are levels of maturity you can pursue even with encouraging individual autonomy.

By giving autonomy, the work pays for itself. It's "free real estate." You can either tell someone what to do, which you have already done for the product roadmap, and use all those company resources. Or let them pursue something they want to, which they'll bring their own resources to the problem (in terms of engagement). If you aren't providing some autonomy, you're leaving productivity on the table.

(The main reason people don't want to do this is that they can't stand the idea of not controlling/authorizing every single item of work. But that's toxic, and the topic of many other blog posts.)

The downside of second seashell work is that it can't take on anything that requires coordination. Many cross-cutting concerns won't be touched as they're too large. But picking up trash along the roadway? That's a perfect second seashell.

You Can Use All Three

These three approaches don't rely on each other. You can roll out any particular one at any particular time.

In mature flat organizations full of trust, the easiest place to start might be second seashell. In formal organizations that have more defined hierarchies, the architecture group may sound more familiar. In product-heavy organizations — such as those that largely outsource engineering to contractors — DevEx is paradoxically a good choice. (Though you might have an uphill sell on why you want to make your contractors more effective, the selling point here is that the internal skills you have are product-oriented, and so treating their productivity as a product problem fits you.)

They also go together.

Having folks rotate through a DevEx team experience will make them better at second seashell. Using your most effective second-seashell types (e.g., code ownership and tracking responsibilities) can identify candidates for an Architecture group.

How Do You Handle Infrastructure Projects?

If you want help diagnosing and prioritizing your product + infrastructure roadmap using this framework, email me at john@guildmasterconsulting.com.

I offer a free first session where we dive straight into your backlog—no sales pitch, no pressure. Exactly how I work with my long-term clients.

(Introverted? Happy to work with you in writing as well.)