Don't Categorize, Prioritize!

Introduction

When I begin an advising engagement with a client, one of the first things I try to understand is what their top priorities are as an organization. This seems like an obvious step, but there is a subtle difference between what most people say are priorities, and what they actually do when they think they’re setting priorities. This is because people say they prioritize, but they actually categorize.

When most people think of prioritizing, they group things into categories such as important, urgent level 1, urgent level 2, blocker, Q3, and so on. It’s likely that they include multiple items in those categories. In other words, they cluster tasks instead of prioritizing tasks.

To truly prioritize a set of tasks or initiatives, you assign each one an importance score such that the scores are monotonic. The key point here is that no two items can share the same importance. Another way to consider prioritization is that we are forming a strict total order on the tasks to be completed.

What this means is that no two items can have the same importance. Ever.

A priortization forms a strict ordering, and can therefore be used as a work queue. You simply focus on the most important thing until it is completed, and then move on to the next most important thing. This removes any ambiguity about which objectives need attention in an organization, and enhances unity of effort.

Why is prioritization instead of general categorization so important? Prioritization provides three major advantages:

1. Clear objectives and importance
2. Unity of effort
3. Focus

I start emphasizing having a clear order of priorities very early in my engagements. This helps to both clarify and obtain mutual understanding with my clients, and to start helping them to think in terms of priorities instead of sets of tasks that all must be accomplished. Most people who don’t realize they’re not actually prioritizing tasks experience bewilderment and frustration when team performance seems to be lacking.

Executives and other high-level leaders have a lot of difficulty with setting clear priorities because of the abstracted view they have of the work being done. If you’re a leader, you might be responsible for five different teams. From your perspective, you might then feel you can work on five things in parallel, and thus up to five things can all share the same priority. This is false, because it assumes there are no dependencies of any kind between the areas of work being done, which is almost never true in practice.

What we’re really talking about in this case is a teams-version of Amdahl’s law.

Amdahl’s law for leaders

Amdahl’s law as applied to parallel work allows you to calculate the speedup that can be obtained from paralellizing tasks, instead of doing them one-by-one. Many people familiar with this concept often still forget that not all tasks are embarrasingly parallel, and therefore you have to account for the dependencies in these calculations.

In other words, you can work on tasks in parallel, but you’ll only achieve a speedup on the tasks that are completely isolated from all other tasks. If you have ten tasks, and three of them are totally independent of all others (including each other), then even having ten teams work on those ten tasks will only enable them to be finished about 40% more quickly! Too few leaders consider this.

Additionally, having pieces of work that are completely isolated from all other pieces of work is almost never the case in software development. It’s something people have tried to work around with a variety of technical solutions, most recently microservices. (You can read more about my stance on that in, spoiler alert, Enough with the Microservices!) Microservices usually don’t solve problems of dependencies across teams as well as, or in the ways that, people hope.

Clear objectives and importance

If you want teams to be able to work well together, they have to know which areas of work are more important. This is covered in more detail in Three Things your People Need To Know and Command and Control.

Assigning labels or categories to tasks might be useful as an initial clustering step, when there are a large number of things to be done and the ordering among the entire set of items is not yet clear. Unfortunately, many executives stop after the clustering is complete. They feel their work is done, but in fact it has only started. Leaders need to finish the job, and make sure that every task, item, objective, initiative, or place where effort is focused, is clearly ranked among the other possible places to focus effort. If you do not do this, then as a leader you are not giving people the guidance and context necessary for them to be productive.

Unity of effort

When you think in terms of a queue (priorities) instead of buckets (categories), people immediately understand which things are more important and which are less important. This is critical in software projects because it is often the case that parts of the system are dependent and therefore cannot be worked on in isolation. This is related to the concept of Essential Complexity as defined by Fred Brooks in “No Silver Bullet”. Speaking of which, you have made “No Silver Bullet” required reading in your teams, right?

Since it is inevitable that some work will be spread across teams, it is also the case that the teams need to know who is working on the most important thing so that they can subordinate their work if the need arises. In a high-performing technology department, teams do not exist in vacuums and must support each other. In order to do this, everyone needs to have a very clear understanding of what the most important priority for the company/team is right now. Otherwise, people on a team may not have incentive to stop what they are doing and help another team.

Also, as a preemptive comment, having dependencies between teams is not a demonstration of poor technical leadership. Having too much dependency between teams can be, and we should always seek to minimize such dependencies to the extent which we can, but we cannot rid ourselves of them entirely.

Since dependencies between teams will always exist, and support will always be required, having clear priorities is essential if you want to have unity of effort among your software teams.

Focus

Especially in the growth-stage companies I typically work with, there is no time to spend working on non-essential features or functionality. The company and market are growing rapidly, and the development teams are potentially understaffed. For these and many other reasons, one of the most important commodities that startups have is focus.

If you want people and teams to be focused on company priorities, then those priorities must be set and clearly communicated. People make many small decisions throughout the day about how to allocate their time and effort. They also have to constantly decide whether to allocate their effort and attention to what they’re currently working on, or drop their current task to handle a request for assistance from their colleague. These many small decisions tax an individual team member’s focus.

If the entire company does not understand the priorities, how the priorities are allocated to the teams, and what part of a particular priority they are working on at that moment, it’s difficult or impossible for team members to make a rational decision about where to place their focus. Priority-driven focus, on the other hand, can dramatically increase a team’s output.

Common question: I have five teams, can’t I have five tasks of the same priority?

In summary, no. You can work on multiple things at once, but that doesn’t mean each one has the same priority. The point is that one thing must be understood to be more important than all others.

Consider the following. If there are two teams working on two different priorities, and they need support from another part of the organization, which one gets the support first? Clearly it should be the team working on the higher priority objective. However, as is often the case in struggling startups, all objectives are categorized as important or urgent or high priority and therefore it is literally impossible for supporting teams to distinguish how to allocate their time and energy.

Also, refer back to the section on Amdahl’s law above. Even if you allocated your five objectives to five teams, you won’t get the speedup you’re hoping for unless all five objectives are completely independent of each other (hint: they never are).

Conclusion

When planning work for yourself and your teams, are you really assigning priorities to the work, or are you just grouping things together into categories? This is a critical difference that a lot of startup leaders don’t fully appreciate, and one that absolutely must be addressed as the company is scaling.

Without a clear understanding of what the priorities are, the people in your company and on your team(s) will not be able to prioritize their own work. This leads to more confusion, slower delivery, and frustration on the part of the employees.

If you want to increase your output and make sure your teams are working together in a mutually-supportive way, you must prioritize tasks. Customers don’t care about how many projects you start, or how many you have running in parallel, they only care how many you deliver to them. If you can truly prioritize your work, then, as one of my great mentors Marco Melas is fond of saying, you can “Stop starting, and start finishing!”