Prioritization. Whose Job Is It Anyway?
Before we worry about prioritization, let’s first examine its root word, priority.
Dictionary.com says it’s a noun which is:
the state or quality of being earlier in time, occurrence, etc.
the right to precede others in order, rank, privilege, etc.; precedence.
the right to take precedence in obtaining certain supplies, services, facilities, etc., especially during a shortage.
something given special attention.
For the purposes of this article, we’re going to go with definitions one and two, which are about prime concerns and the order in which they are placed.
So who in your organization is responsible for naming and ranking the most important things? Some titles that come to mind are Portfolio Manager, Program Director or Manager, Product Intake Director, Product Manager, and Product Owner, among many others. All work with a variety of executive managers, customers, and other stakeholders (hopefully) to determine what’s now and what’s next. All get paid to look at the data (hopefully) and customer needs (hopefully) and create grand lists and spreadsheets of all of the work and the order in which to do it. And all begin working on the next list before they hit send for the email containing the last list.
This activity is usually followed by the question, “Which version of the priority list are you working from?” In the meantime, teams are either left in the lurch waiting to get the most up-to-date version of the list, or, even worse, they do a bunch of work against a priority list that was outdated before they ever received it.
Sound familiar? Sound frustrating? Ok, so why do we do it?
There are a host of organizational dysfunctions that come to mind, but there’s one that stands out for me, and that’s prioritization as a function of title or role. Sure anyone with a c-suite title or with a director or manager role can and should have the prerogative to delineate priorities, but, just as with leadership, if your organization is relying solely on situational authority to determine priorities, you’ll never rise above the frustrating scenario outlined above.
But why?
Empowerment and intelligence. Not the empowerment theater we see so often:
Boss: I’m empowering you to do this thing. You are free to do anything that I approve to get it done.
Employee: …
And not the intelligence of smarts or IQ, but the intelligence that all of your employees have about their jobs, your customers, and how things really get done within your organization. They know what happens day in and day out. They are best equipped to make decisions about how to get the job done.
Knowledge workers themselves are best placed to make decisions about how to perform their work.
~Peter Drucker
What Peter was talking about is the empowerment and intelligence of decentralized decision making and delegated authority, two things necessary for agile ways of working. In fact, decentralized decision making is what’s behind the fifth principle of the Agile Manifesto for Software Development:
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.What Does This Have to Do with Prioritization?
When we apply decentralized decision making and delegated authority to prioritization, it becomes apparent that prioritization is a task for everyone, not just those with the rank and privilege of title.
Democratizing prioritization doesn’t mean that everyone gets a say in every decision that’s made. That, of course, would bring your organization’s decision making to a stand still. It does, however, mean that priority decisions are best made with the input of the people who will be doing the work.
How you do that in your organization is up to you, but here are a few concepts that may help decentralize your prioritization efforts:
Short Feedback Loops
Whether it comes directly from your customers or from product teams who have access to customers and product data, feedback is key to making quality priority decisions. What comes next is best informed by how what was previously done is received. The primacy of that feedback is greatly reduced when it has to run up a chain of command before anything can be done about it. By the time a decision gets back down to a team, you’ve run the risk of that decision becoming irrelevant.
Reduce Complexity
The more complex your organizational systems, the less likely it will be able to decentralize prioritization. Heavily siloed or matrixed organizations depend more on hierarchical structures than self-organizing, independent teams for decision making. Breaking down silos and complicated matrices of reporting will not only enable but require decentralized decision making.
Work in Small Batches
Large-scale, big bang planning and delivery are very risky, and high risk typical requires more centralized decision making. If your organization is making only a few but costly or risky priority decisions, then that’s a sign that you are working in big batches. Small batches are almost always less risky. They cost less. They require less time. They can also usually be adapted or walked back. Small batches enable reduced complexity which enables shorter feedback loops which enables decentralized prioritization.
Reduce Work in Progress (WIP)
Too much WIP is a problem that plagues more companies than most other organizational dysfunctions. When there is too much work to do all the time, decision making defaults to those with the loudest voice who are usually those with rank and privilege. There simply is no time for those doing the work to do anything other than what the boss says is next. The conundrum here is that only someone with authority can safely tell teams to work on fewer things. Enabling directors and line managers to tell their teams what not to work on will free those teams up to participate in deciding what to work on and in what order by using the knowledge they’ve gained by doing the work and interacting with customers.
These concepts aren’t just my opinion. Many agile frameworks, including Scrum, XP, and SAFe, directly address the need for these and other practices that enable decentralized decision making. The Lean Startup movement is built upon the concepts of short feedback loops and decreased complexity in decision making.
I hope this post has shown the value of prioritization as a team sport. If you want to work fast and deliver fast, then you need more than just a few anointed people in your organization to help determine what’s now and what’s next.
