How to Prioritise “Engineering Work” in Product Teams

Are you an engineer battling to prioritise technical improvements in a product roadmap?

There are several things we could do. We could brush up our negotiation skills. We could develop the capability to valuate technical improvements in terms of business KPIs to make a better case for them. But neither of these ideas address the root of the problem: should we even have to prioritise between technical and product improvements in the first place?

Before we answer that, let’s start by defining the two types of work. We’ll call them “feature work” and “engineering work”.

• Feature work is like a customer order, i.e. it is work requested for by a customer. It changes the behaviour of a system.
• Engineering work on the other hand does not change the behaviour of a system. It is no less important though. Neglect of engineering work will eventually slow down feature work.

Yes, that is right. Engineering work is not fancy, fun work that engineers want to do. It is a requirement to keep the system productive. Engineering work comes in various forms, e.g. technical debt, refactoring and technology upgrades.

Now that know what each form of work is…

How do we prioritise between feature and engineering work?

Well, we don’t.

For the most part, we bake in the time required for engineering work into feature work. A few analogies to illustrate why:

1. A surgeon does not ask their patients if they should put on surgical gear. The act of putting on the gear is a part of the surgery itself.
2. A manufacturer does not ask their customers whether machines should be oiled or serviced. These procedures are accounted for in the production schedule.
3. A chauffeur does not ask their passengers whether to fill the tank or clean up. Maintenance of the vehicle is baked into the service being offered.

Why don’t these professionals ask their customers whether to put on safety gear or keep their tools and machines in tip-top shape? Because they know better. They are the “professionals” after all.

We too are professionals. We don’t need to negotiate the writing of a test or refactoring of a piece of code. Our objective always remains feature work, where engineering work is often a means to it. In fact, engineering work would not exist if not for feature work. If we accept this symbiotic relationship, it becomes clear that it is futile to compare one against the other. They are simply meant to co-exist.

So where does engineering work go on a product roadmap?

Whether it’s a roadmap, a work-board, a backlog or a set of goals, we should stop attempting to stack rank or prioritise engineering work against feature work. The sole purpose of the board is to track and prioritise what the customer wants. Engineering work is an implied part of it all.

This does not mean that we stop tracking engineering work, such as technical debt, when tracking would be beneficial. We can do that elsewhere. We just don’t want to mix up it up with feature work and end up prioritising between them.

There can be exceptions though…

What if engineering work is going to impede our ability to do feature work?

When a piece of engineering work is larger than usual, we can add a placeholder in our roadmap to indicate why we won’t be able to take on our usual volume of feature work.

In the example of the manufacturing factory, this could be a machine replacement that is not routine. While the machine is being replaced, a lower intake of customer orders is expected, therefore a placeholder for “machine replacement” is placed on the order list to indicate reduced capacity for customer orders.

For us, this could be major architectural rework that significantly reduces our capacity to do feature work.

Keep in mind, instances of engineering work appearing on feature prioritisation boards should be the exception, not the rule.

Disclaimer:

Bazaar Technologies believes in sharing knowledge and freedom of expression, and it encourages it’s colleagues and friends to share knowledge, experiences and opinions in written form on it’s medium publication, in a hope that some people across the globe might find the content helpful. However the content shared in this post and other posts on this medium publication mostly describe and highlight the opinions of the authors, which might or might not be the actual and official perspective of Bazaar Technologies.