AWS Cloud Enterprise Strategy Blog

Should You Prioritize?

Railroad Crossing

Sometimes an idea becomes so ingrained in conventional wisdom, such an embedded assumption in everything we do, that it demands to be questioned. Think about how often you hear someone in a meeting say, “We need to prioritize,” or ask, “Is this a priority?” When something goes wrong, it may be blamed on a failure to prioritize. When an IT team can’t accommodate all the work other parts of the business demand, it asks business leaders to prioritize. The term priorities is a fixture of discussions that range from the high-level (“We have to set our company’s strategic priorities”) to coarse-grained tactical (“We have to prioritize our investments”) to the fine-grained (“We have to groom our backlog based on our priorities”).

It is telling that prioritization seems difficult for everyone—there is something unnatural about it.

Part of the problem is that the meaning of the word priority has changed. When it was first coined in the fourteenth century from the Old French priorite, based on the Latin prior, it meant the “state of being earlier (than something else).” In other words, it referred to time, not importance. Only in the 1900s did it begin to take on the meaning of requiring immediate attention. [1]

The plural form, priorities, is a recent addition to the English language. It was coined in the 1900s and was rarely used until the 1940s. Until then, it was clear that one could only have a single priority because only one thing could be most important. The verb prioritize is a recent creation, first noted around the 1972 presidential election as an awkward piece of political speech.

Most of us instinctively define priorities as the set of things most important to a company, but the truth is that we rarely use the word that way today. Its meaning has shifted yet again in a way we are reluctant to acknowledge.

The Real Meaning of Prioritization Today

Strangely, today we use prioritization to divide the work we will and will not do. When a new work item is proposed, someone will ask, “Is that really a priority?” The assumption is that if it is not a priority, it should not be done. A priority is no longer the thing that must be done prior to other things or even the most important thing—it is one of the only things that should be done. That’s why we need the plural form—if not for priorities, we would only do one thing!

In today’s usage, priorities are a subset of all the ranked needs of the organization—prioritizing means making a list of potential work or investments, putting them in order of importance, then taking the top three, six, or a dozen of them and labeling them the priorities. Those are the ones that the organization will invest in.

Why has the meaning shifted this way? I think it has to do with managers and leaders living in an environment of constant belt-tightening, where they feel they must prove they are spending as little as possible. There is no way they can spend less than by investing only in the priorities, the “must-dos.” No matter its origin, this shift has created a dynamic in which priorities become a list of all we plan to do—the “priorities” themselves don’t have a priority order but are all equally important. Weird, huh?

I recently reviewed the strategic plans of two companies. One of them listed eleven priorities. Why so many? It became clear that they were trying to include everything they needed to do to run the business. The second strategic plan had only four priorities, but they were all vague, along the lines of “Strive for operational excellence” and “Deliver for our customers.” The priorities were meant to include everything, making sure anything they chose to do could be mapped to a formalized priority.

These “prioritizations” communicate nothing about priority.

Critical (Odd) Assumption of Prioritizing 1: Fixed Capacity

A central assumption of prioritization is that we’re working with a fixed capacity. We must prioritize because there are limits on what we can do. Presumably the list of candidates for prioritization only includes investments that we expect to have a good return (otherwise they wouldn’t be candidates)—yet we must select only a subset for execution. Built into the idea of prioritization is an intention to leave value on the table, to incur opportunity costs. Capacity is set (somehow), and work is derived from it, rather than capacity being set based on the opportunities available for earning returns.

IT departments have long been challenged by this assumption. IT solicits or accepts demand for its services across the enterprise, thereby developing a list of requested work for prioritization. Because this demand always exceeds its capacity, they must choose a subset, which means saying no to some demands. Since the subset it declines to address includes work that would benefit the company, it is certain to displease parts of the organization and give the feeling that IT is slow and unresponsive.

People in an organization tend to have a lot of good ideas. If you tell them that capacity is limited, and they must prioritize, it’s natural for them to declare all their good ideas to be priorities because they know that only priorities will be addressed. We’re in a vicious circle here: if priorities are the only things that will be done, then every idea that adds value is a “priority.”

The truth is that there are many things an organization must do, even though they are not priorities. Especially in the IT world, keeping the company operating requires considerable bandwidth; limiting the work to “priorities” begins a death spiral and adds risk to a company’s operations. The act of prioritizing itself adds waste. Technologists may see the point of this metaphor: if you have too little computer memory, eventually the CPU spends all its time swapping applications in and out of memory, flailing uselessly. IT winds up spending effort on demand management and governance that could be spent on creation.

The idea that we must funnel down our work based on capacity implies that we are not in an equilibrium state. If we can’t do the things that generate value, then we need to add capacity. Or perhaps there is something broken about how we identify candidates for prioritization. The idea that a company should work with restricted capacity might come from an analogy with cash management; a company only has a fixed amount of cash to work with, so it can only make investments with the cash available. But that is only in the short term—a company’s growth plan must address its cash needs. Cash constraints don’t destroy business value in a well-managed company. Somehow, maintaining a permanent constraint on IT resources seems different.

In any case, IT must take responsibility for doing everything the company needs, not just the priorities.

Critical (Odd) Assumption of Prioritizing 2: Known Opportunities

A second assumption of prioritization is that we make decisions about a given list of investment opportunities. We ask, “Of the following list of candidates for prioritization, how should we rank them, and where should we draw the cutoff line of which ones to address?” But in today’s fast-changing and uncertain environment, we constantly encounter new opportunities and challenges that make potential investments rise or fall in importance.

Agile frameworks like Scrum try to manage these changes by creating a backlog of work and frequently reprioritizing, or refining, it. But perhaps this confuses prioritization with project management. Scrum (arguably) juggles granular, individual work items that are given through some process of requirement elicitation rather than working backward from an organizational priority. It essentially formalizes the idea that prioritization means ranking and subsetting. Sure, we can groom the backlog and reprioritize it, but for our burndown to be useful, we need to more or less know the universe of work upfront. We can add to it, but that will have consequences.

The mental model here is one of independent, siloed business units, each with its own needs, that must be ranked by a central IT organization. Each silo has its own priorities, and the central IT organization has different priorities because it is “central.” This creates a framework of competing priorities that must be adjudicated to produce winners and losers. Predictably, it elicits constant calls that IT become “better aligned” with “the business.”

Critical (Odd) Assumption of Prioritizing 3: Rigorous Methodology

The third assumption is that there is a rational, rigorous way to order a diverse list of different types of investments, presumably by return on investment (ROI). But as I have argued in my book The Art of Business Value, ROI does not effectively serve this purpose. Prioritization of IT work based on ROI—sorry to say this, my former business school professors—will destroy value. I’ve become even more convinced of this as the importance of ESG has increased; stakeholders often value things that don’t always maximize ROI.

Thinking Differently About Priorities

The first step in unwinding this confusion is to separate the concepts of strategy, priority, and workload management. Strategy is not a list of priorities; it is a small set of principles that leaders determine to drive their company’s unique approach to its market. At any given moment, there is a single priority—the thing that leaders want employees to focus on while implementing strategy. But the priority (singular) is not the total work the company needs to execute. Execution is high bandwidth—many things need to be done in parallel. Today we form employees into autonomous teams that take full ownership over their domains (they “run what they build”)—an excellent organizational structure for parallelizing activities.

Although the three concepts are distinct, they are part of a continuous whole. A different approach to workload management begins with senior management laying out a strategy and then moving directly to work designed to accomplish that strategy. There is no list of initiatives solicited from across the organization needing to be prioritized. Initiatives follow organically from high-level strategy. There is one priority: the initiative that will be done first. If the strategic imperative is growth, then the initiative most likely to cause the desired growth is the one pursued. That doesn’t mean no other initiatives are pursued, just that the strategic one takes priority when there is a conflict of resources.

This is just a train of thought based on the constant chatter I hear about setting priorities. I hope it’s useful.

—Mark

[1] Online Etymology Dictionary https://www.etymonline.com/search?q=priority

Mark Schwartz

Mark Schwartz

Mark Schwartz is an Enterprise Strategist at Amazon Web Services and the author of The Art of Business Value and A Seat at the Table: IT Leadership in the Age of Agility. Before joining AWS he was the CIO of US Citizenship and Immigration Service (part of the Department of Homeland Security), CIO of Intrax, and CEO of Auctiva. He has an MBA from Wharton, a BS in Computer Science from Yale, and an MA in Philosophy from Yale.