Prioritizing engineering work-items: A real-life knapsack problem

Image by DALL-E

One of the most popular, and frequently applied, optimization problems is the knapsack problem, which states the following:

Given a set of items, each with a weight and a value, determine which items to include in the collection so that the total weight is less than or equal to a given limit and the total value is as large as possible. Source: Wikipedia

A common application of this problem is in resource allocation, “where the decision-makers have to choose from a set of non-divisible projects or tasks under a fixed budget or time constraint, respectively” Source: Wikipedia

The particular resource allocation problem I am referring to in software engineering is allocating resources to your R&D organization. This resource allocation problem is that of  building your product roadmap. There is, however, a class of other work-items that contend with your roadmap that are often not allocated or down-prioritized: engineering work-items.

Let’s walk through an example.

Consider an R&D organization that has 4 software development teams. The assignment of roadmap items to the teams is mapped below. 

This assignment leads to two questions.

1. Why were these features prioritized over others? Said otherwise, does this allocation yield the largest total value possible (in the words of the knapsack problem)

2. What about non-roadmap items? The canonical examples include engineering specific work e.g. tech debt, increasing test coverage of legacy code and more. These are all non-customer facing items, and never make it on a roadmap.

There is natural tension between both of these, especially with resource allocation. The first is concerned with work that is customer facing - product features, that allow you to target more customers, increasing your market share and so on. They are business drivers and are decided on by the product management organization.

The second is an internal concern, with investments that aren’t necessarily customer facing. Because these investments aren’t customer facing, they tend to be down-prioritized in favor of roadmap items.

I argue that this is a mistake and that they need to be weighed against roadmap items too. The items that fall into that bucket should be part of the resource allocation problem. How does one do that then? The answer lies in the knapsack problem.

There are two key levers in the knapsack problem: limit and value. Limit is the capacity of the engineering organization, or how much work they can do in a period of time. The second, is the perceived value of work assigned to these teams. In software, both of these are at best empirical observations with a heavy dose of subjectivity. However, both of these levers are critical in allocating resources across both product features and internal engineering concerns.

Adjust the weights

One of the challenges with trying to allocate resources to internal engineering concerns that I have observed, is the lack of perceived value they provide. That is a crucial mistake. Engineering work-items must provide some value, otherwise why do them? Consider, a common task of refactoring legacy code. The value that this work can provide is twofold. First, refactored code should make it easier to build upon, meaning it should increase the velocity of building features using this code. Second, better factored code should increase its testability, which in turn reduces support tickets and increases CSAT. These are all business drivers. 

The main mistake when evaluating these internal engineering work-items is they are not championed as business drivers. They are and they must. It is only when you do that these items can be easily weighed and traded-off against other product features. Therefore, as an engineering leader you must be able to elevate and advocate these work items in terms of value to the business. 

Adjust the limits

Under this model you reduce the capacity available to the product features and allocate a fixed subset to engineering work items. In the example I gave earlier, rather than have 4 feature teams, you simply allocate 3 of those to product work and maintain one for internal engineering work items. I am not a fan of this approach, as it gives the impression that the engineering team as a “bye” and is unable to articulate why investments they advocate for matter, and matter to the business. 

A practical, hybrid approach

The approach that I found that works best is a hybrid approach in which some portion of resources is allocated towards engineering work items whilst also maintaining that these are prioritized according to business impact. The natural time, and thus resources, to allocate for some engineering work-items is when team transition between projects. In the roadmap diagram above, teams do not roll from one feature into the next immediately. There’s usually a transitionary period, on the order of a few weeks. This transitionary period is a great point to introduce prioritized engineering work. It allows the teams to get a different product - and code perspective - and give them the opportunity to work on non-product roadmap items.

That approach doesn’t work for large work items that will require longer than this transitionary period. Hence, there will be times when an entire team or more need to be allocated towards engineering work items. These, like their product roadmap counterparts, should be prioritized according to their impact to the business.

Under this hybrid approach, you should be able to slot relatively small work items during the transitionary period and allocate larger resources (time and people) to larger work-items.

Putting it all together

The focus of this post was in highlighting the perceived lower priority of engineering work items and how to elevate those to the same level as feature work. This however, doesn’t make the prioritization and resource allocation problem easier. All it does it elevate more work to be prioritized and assigned resources too. Previously, I wrote a blog on how to gamify this process, or at least make it collaborative between product and engineering. I have used this approach a few times and it works pretty well.

Things of interest, I am reading now

OnlyCFO

wrote an excellent piece on employee stock options. I highly encourage anyone interested in joining a startup to read it. A few years ago, I also wrote (albeit less eloquent than this article), a similar article on IPO Dreams

This week’s “bombshell” was Amazon Prime Video (finally) realizing that serverless isn’t the most cost effective to build a scalable service 😱

Source: Prime Video Labs