Figure out if non-blockers are still important

Categorizing non-blocking work for long term stability and velocity

In order to effectively prioritize work, we need to know if it's a blocker or a non-blocker, but we can't stop there. We need to further understand if our non-blockers have a long term or architectural impact on our blocking work. We also need to understand whether those impacts should or shouldn't be addressed today. This post is a look at categorizing non-blockers along strategic, organizational, and architectural dimensions in order to make better decisions today that will help us tomorrow. Deprioritization is a decision, not a wish, so let's choose wisely.

#blog #work

When prioritizing work, we need to make a few high level distinctions.

First, there is work that must be done to achieve the goal of the project. This work is tautologically required and will be completed before we can call the project complete. These are blockers.

Blockers can also take the form of things that feel tangential or that we wish we could avoid doing in order to achieve the goal. For instance, we need to update a widget to a new version of a dependency because that version is the only one that has the functionality we need. This may include other changes (e.g., the color of the widget) that are ancillary to our purpose but end up being in our critical path to completing the project.

Then there is the rest of the work that gets categorized as non-blockers. This work isn't required for us to complete the project. It's tempting to just deprioritize all of this work and only do the required work. Directionally, this is a good attitude, but it can cause problems in the long term. So how should we handle non-blockers? I find that we need to categorize the work across strategic, organizational, and architectural dimensions before we can act accordingly.

First, we ask if the work is strategically or existentially significant. Strategic non-blockers¹ are tasks that would become a problem or a blocker at a later time. This kind of work feels risky to delay working on. For example, if we're a company that processes a lot of payments and has an integration with a third-party payment processor, it would be strategically — and potentially existentially — irresponsible to put off updating our integration (SDK, API calls, etc.) with that payment processor. One day our integration will fail and there will be a fire drill trying to write new integration code to restore the system.

One way of figuring out if the work is a strategic non-blocker is to ask whether it must be done eventually (for various definitions of "must" and "eventually"). If the answer is no, then it's not a strategic non-blocker and we can stop right here. Non-strategic, non-blocking work shouldn't be worked on as part of our project and we can safely deprioritize it for now. Note that this doesn't mean that it'll never be worked on, just that we can put it off and continue with our focus on the task at hand. If the work must be done eventually or is categorized as strategic for other reasons, then we need to continue with the categorization process to see how to handle it.

We must work on what matters and nothing matters more than existential threats. Non-blocking, existential work is obviously strategically significant, but there are other kinds of significant, non-blocking work that are not existential.

The next dimension is whether the work is organizationally significant. The goal here is to determine whether this strategic non-blocker will starve The Mission. Big, hard, unclear, important problems can be starved out by small, well-understood, important problems, but this can cause long-term problems for the organization. For instance, will this work impact the likelihood that other blocking or existential work gets done in the long term? We can easily fall into the trap of preening or snacking, but even more insidiously, focusing on quick wins over deep work. Non-blockers can be locally rational choices that globally destroy focus. There are times when partially solving one problem can be more valuable than fully solving another. Organizational significance affects our throughput and momentum. Throughput and momentum in turn affect our sustainability, our runway, our existence. This is second-order significant work. If your non-blocker falls in this category, it may or may not be worthwhile to do as part of the project you're currently working on, but it is important that it's prioritized to be done.

Moving on, even if our strategic non-blocker is not organizationally significant, it could still be important to track, prioritize, or accomplish. This area is more nuanced and why I wanted to write this post in the first place. The next dimension we'll examine is whether the work is architecturally significant.

Architectural significance can be measured in many ways, but the way I prefer to think about it is whether the current choice will constrain our choices for critical, existential, blocking work in the future. Will this work unblock others? Even if this non-blocking work is not critical to solve the problem at hand, it could become a decision that determines the shape of the system in the future. Going back to our example company with lots of payment transactions as an example, maybe skipping this non-blocker would cause us to be unable to offer multiple third-party payment processor options for our customers in the future, locking us into only using that one integration.

Not doing the non-blocking work can lock you into an architecture later. You should usually spend the time to figure out what it would look like to solve this problem. You don't always have to follow through and solve the problem right now, but spending that time ensures you're not stuck with something bad because you didn't make the choice now. This gives us the benefit of knowing if the work we are doing should be adjusted to be compatible with the deprioritized work.

On the other hand, I'm a big believer that we can change, we should optimize for change, and we can have nice things. How many times have we been told "you aren't going to need it"? So how do we balance that? This feels like a whole topic on its own so I won't spend too much time expounding on it today. One simple thought here is that we can avoid all or nothing thinking. Perhaps an edge case would be catastrophic to encounter but would take a lot of effort to solve generally for all consumers, but changing that bad outcome from a catastrophe to a nuisance is only a small amount of effort. Again, think about partial solutions and their value against full ones.

Deprioritization is a decision, not a wish

Now that we know what we should deprioritize and why, we need to know how to handle deprioritized work. We’ve all been part of organizations that had a mile-long backlog of work that was ostensibly deprioritized now in order to be worked on later, but that later never comes. We want to avoid that. When you deprioritize work, you are explicitly agreeing to the impact of what happens when that work is not done. This could be a low probability catastrophic outcome or regular sustained annoyances. It could be as simple as a feature that someone wants but doesn't get to have. No matter what, we should make explicit recorded decisions about work we do and don't do. Make these official positions instead of implicit lack of decision. You are not saying, "we're going to put our heads in the sand for now" and later treat it as a miss or a fire-drill when it happens. Remember, deprioritization is a decision, not a wish.