How to Plan for Maintenance 🛠️

The best strategies including cycling, swim lanes, the boy scout rule, backlogs, and more.

One of the most important duties of any engineering team is to spend their time and effort on the right things.

So, in an ideal world, you would pull all the possible tasks, calculate their cost, their value, and address them in descending order based on their ROI.

In the real world, though, this doesn’t happen.

It doesn’t happen because, in product & engineering, there exist radically different types of work: think of a big feature vs a large refactor, or a small product improvement vs updating a dependency. For many of these, figuring out the precise value or cost beforehand is tricky. Also, they may just bring different types of value (e.g. more revenues vs more productivity), so the playing field is not even.

Maintenance tasks are the ones that suffer the most from this mismatch. They are extremely valuable in the long run, but they can also be utterly technical and hard to grasp by PMs.

So, in the most successful companies I know, maintenance is usually addressed in very specific ways, to protect it and make sure people actually do it.

This article covers the best strategies to perform maintenance in engineering teams.

It includes real-world examples from the teams at Product Hunt, Swarmia, and Codacy, and more ideas from yours truly.

Here is what we will cover:

• ❓ What is maintenance? — let’s talk of size and urgency.

• 🏅 Boy Scout Rule — a cultural staple for handling everyday tasks.

• 🔄 Cycling — assigning people to maintenance with rotating processes.

• 🏊‍♀️ Swimlanes — allocating fixed time to maintenance, separated by product dev.

• 👷 Dedicated teams — having a permanent team for it.

• 📋 Tracking tasks — on the need and perils of backlogs.

Let’s dive in!