Prioritization is hard.
Living through this COVID-19 pandemic has allowed me time to think (*I am extremely grateful and fortunate that my pandemic experience is exponentially easier than others’*). Eventually I begin to think about work because I can only watch so much Netflix and eat so much food. I do think at least weekly about “my top issue right now” and I think that the most frequent issues boils down to competing or unclear priority. I’ve started to realize as I sit here trying to figure out a hobby and ruining recipes is that this pandemic is an extremely vivid display of prioritization.
Throughout history, humans have proven that the most effective way to prioritize, truly pushing the most important thing to the top of societal to do lists, is to do so via community (future post on social media? nope). The most visible and wide reaching examples are the priority shifts caused by war, which in some philosophical sense, can be classified as pandemics.
- Great Wall of China (Ming era)
- got frustrated looking for more examples from before the modern era
- Defense Production Act 1950 — talk about a prioritization tool!
- The Space Race and STEM programs
- Life right after September 11, 2001
For every development team I’ve been on, the issue of competing or unclear priorities is apparent at one point in time or all the time. Even in the case of this very real pandemic, issues in prioritization across the human race are clear.
My goal in writing this is to start a discussion around prioritization for development teams and optimizing product or engineering delivery, so I’ll start by clarifying my perspective.
Priority does imply position, rank, or order to things. In my experience on development teams, this notion of position has always become lost.
Prioritizing is the process or protocol things go through to uncover priority. Our brain does this a lot. Explicit or not, we prioritize constantly. We prioritize breathing.
In my experience on development teams, this process is varied. From complete obfuscation , to the “wild, wild west” of ad-hoc requests, and one time, straightforward! This process usually is in the form of cascading messages from executives, OKR slide decks from the Product Organization, or standups.
The process should vary, but the meaning of priority should not.
Most teams are using Scrum (probably incorrectly but that's a future post). If you’re using something else, I’ll assume most of you have this role, or some flavor of it. But it boils down to one individual who’s “accountable” for the output of prioritization…priority.
In my experience on development teams, this role is either unfilled, well intended but incapable or uninformed, engaged but misguided, or a RockStar-Superhero!
To summarize the above:
- Priority is misunderstood or misused
- Typical processes of prioritization mostly seem “distant”
- Product Owners are human
I think the most frequent issues I hear from or have experienced on development teams as an analyst, scrum master, delivery manager and people manager are variations of (in the context of that order):
- “Which one should I do first?”
- “We keep pushing down technical debt.”
- “We have too many things in process.”
- “I feel overwhelmed.”
All of these are traced back to the process of prioritization. If unchecked, these issues accumulate into negative outcomes for individuals, teams, organizations, and customers.
Questions…and maybe answers, stated as questions?
Can 2 things hold the same priority on a single team?
Priority implies rank. Two people can’t finish 1st place in a race. But a team has many people. Priorities can be spread to many so that ranks one, two and three can masquerade as one rank right? If you’re developing in a perfect engineering environment maybe. But no team is and never will be. Even if you are, as your system grows in complexity you will eventually be unable to do this due to effects of increasing dependencies, bottlenecks, information gaps, and unknowns.
What if priority is clear and work is broken down into independent tasks aligned correctly to priority? If they both have a rank and do not need further queuing, should they still hold a local priority? Are there known unknowns for outcomes? How well understood is your system? What does Rachel in Quality think? Lars in Operations?
What can be controlled in a prioritization process?
Did we deliver the right thing at the right time to the right people?
We know that the best processes are those that are generated from self organization (Darwin? Agile?). But in larger teams, departments and organizations, some level of guard rails are needed to manage complexity and its critical to manage variance against them to be competitive in an established market.
Information inputs to prioritization might be sales and product usage data, but it also might be a powerpoint from corporate. Either way, monitoring the quality and timing and of inputs here should be done. Living in the time of COVID-19, the need for a standard and quality controlled data collection mechanism is pretty clear to anyone watching the news. Why doesn’t the same apply to developing a world class application like you’re supposed to be doing?
Do you know how priority shifts affect your customers with each change? Your teams? Visualizing the delivery process(See kanban) in order to obtain data required to supplement the prioritization process is just as important as the shiny new idea in the boardroom.
How do you know what the right thing is or the right people are?
Is there a more effective human accountability approach?
Is the priority problem due to the one person being accountable for this process lacking knowledge, tools, or experience? Maybe. But can you fault that person when a development team divides itself into many individuals and functions? If a PO is working with three developers, each willing to grab a different priority item, there is no need for that PO to establish a prioritization process or protocol. Everything can start, therefore, “Here’s the list, in no particular order.” In what might have started as a psychological safe environment can quickly become one of fear because the team, scrum master, everyone has mismanaged expectations. What happens when you’re a PO and the delivery teams have organized into 3 or 5 teams? Are you still accountable for Team Z’s backlog? It's the legacy system portion of your new product by the way…
How does a bonus structure factor into this process? If I’m a PO and I am awarded with $15k if I get 2x users this year I might jump at every one-off feature request, swing back at every competitors’ features or prioritize what I think they lack, and double down on whatever my top sales people want. What did that annual OKR slidedeck say again?
I want to solve for the quotes listed in The Problem section.
I also want to get this published since its my first post and I told myself I’d do that tonight. So I’ll finish by saying I want to write more in depth and technically about possible solutions. However I think if you or I identify priority as a problem affecting us or our teams, I think we at least need to employ some fundamental principles and build out from there.
Prioritization via community yields the most favorable options. This is what a pandemic makes vividly clear. On development teams, an effective community is your user base, your organizational stakeholders and your full team. Get their objective input. Bonus principle: Most of the time, someone else has already solved your problem.
Make decisions when they are in your control to make. Again I think COVID-19 is teaching us a lesson here. In the longest bull market run in history, business had the most cash on hand, decided to prioritize returning cash to investors via stock buybacks as opposed to reinvesting in infrastructure, innovation, new models, etc to uncover new value for now or 10 years from now. Instead, now, the majority of firms have no cash on hand and little opportunity to launch anything “new.” Who’s going to buy it? This was supposed to tie back to technical debt. Oh well. Economic debt? That doesn’t make much sense but hopefully you catch my drift. Frequently prioritize your technical debt.
Limit priorities in progress to get more done, improve quality and ignite awesome teams. I’ll probably mention Dr. Deming in future post, and I’ll try to get technical with Little’s Law and process data.
Don’t let the problem linger. I’ve annoyed hundreds at this point because I always bring up the issue of prioritization. It's a hard process to change. Usually someone is being asked to give up power or authority. Get people to come to the table well intended and with ideas. Everyone has a solution to offer, good and bad. But letting a problem go uncommunicated and unmitigated is disastrous.
Again I write this to hopefully start discussions and very open to ideas and feedback. Thanks!