A question that occupies many tech executives is the proper time allocation in their teams for tasks that are not trivial feature development. Fixing bugs, handling technical debt, making architectural changes, creating new tooling (which I’ll group under “non-feature work” in this article). These are all vitally important for a growing team to stay productive and not slow down. However, it sometimes ends up being a constant struggle where Engineering has to fight for every day spent on these, or do these things on top of the regular work—regularly burning the midnight oil.

In these series of articles, I will cover some of the approaches I’ve helped my clients implement over the years, as well as provide some vision about creating a mythical creature—a remarkable engineering team. First, in this part, let’s start by reviewing some common and failed approaches I’ve seen as well as my assumptions for the steps ahead.

Bad Patterns

One of the most common ways I’ve seen for attempting to allocate time for non-feature work is to claim a certain percentage of every sprint that’s for the team’s allocation. That means that, for example, every sprint has 30% of the person-hours allocated to non-feature work. Thus, two backlogs are being managed. 70% of the work is directed by Product, and the rest is up for the team to handle.

It’s better than not allocating time for non-feature work at all, but using this approach for too long often has suboptimal results. The main reasons are:

• Every team is different. Assuming all teams in your organization should use the same X% of the time for non-feature work is wrong.
• Every sprint is different. Maintaining the same X% as a team grows, changes focus, goes through a pandemic, is also wrong. This is an example of how groups come to live with stale velocity.
• Low impact work gets scheduled simply because there’s time to use, and no one wants to let go of “budget” in fear of creating a precedent. And so, your team might spend time fixing bugs that have been laying in Jira for months without no one caring.
• Quality becomes something only Engineering is responsible for. I’ve witnessed childish arguments between Engineering and Product about whether a particular bug should be counted as part of Engineering’s sprint time or Product’s.
  

Another similar approach is to create a “platform” team that’s in charge of at least some of the non-feature work, like handling debt and making architectural changes. Instead of allocating X% of each team’s sprint, a whole team is taken out of the “pool” that’s available for Product. It might comprise more senior staff and regarded as some sort of an architecture team hybrid. I’ve seen a lot of these and was part of one such team in the past. While at first glance, it might sound like a good idea, this often has bad long term effects on the entire organization.

The new team becomes the “sexy” that many want to move to. Since that team is responsible for tackling tech debt, quality soon deteriorates at the rest of the teams. Not being able to invest time in improving their own systems, the other teams lose their sense of empowerment and thus take less ownership of the product. All in all, these kinds of teams are rarely the right set up.

Assumptions

My assumptions for each such change initiative consist of the following:

• Every organization is different, and within it, every team is different.
• Flexibility is a must.
• Tech debt must be handled, but tech capital is even more critical.
• Rather than running away from Product, you should work together.
• Work should always be impact-driven.
  

In the next part (or parts), I will drill into practical ways of dealing non-feature work in a manner that’s consistent with these assumptions and beliefs.

Update: The next part is now available here.