For a long time, I had very naive ideas about prioritization. Here’s what I’ve learned over the years.
1. Unless you are a tiny startup, your company is designed to do multiple high-priority things at once. The argument, “Well, if everything is high priority, nothing is high priority,” almost never works (while rational). The 🐘 in the room is that the mix of high-priority things has changed, and the org design is no longer fit for purpose.
What seems rational to you—oh, obviously that team is overwhelmed and we need to set priorities—is, behind the scenes, “Crap, we got the budget wrong for that group. Anyone want to contribute? No? Hmmm. Surely they are inefficient and can juggle more than one thing, right?” See below.
2. Most senior execs know that the plans will change. They know that by March, there will be a new set of priorities. So they focus on budgets, not priorities. So when you see lackluster strategies and vague priorities, remember that there is a whole other prioritization activity that centers around the allocation of money, how people get bonuses, very back-of-the-napkin revenue attribution models, etc.
3. Humans, in general, are not great at building a mental model for capacity. Capacity in software is hard. People aren’t fungible. The architecture is what it is. You can’t have huge teams. You are building the factory (to meet the needs of a strategy) AND the factory is building “the product.” Oh, it isn’t a factory: it is more like gardening.
This is important because our mental models for what we are prioritizing (e.g., focus, capacity, typing, bandwidth, etc.) are often all over the place.
4. Most companies are not progressive when it comes to thoughtful re-orgs, org redesign, reallocating capacity, etc. The simple thinking is: “If we stop doing X, then we should let those people go because they fit in this cell on the spreadsheet.” People too heavily couple the finance spreadsheets with one-row-per-person, and the (most often useless and made-up) % allocations to things. This means that basic things like having priorities and reducing work in progress are fraught with very justified fears around layoffs.
To some, a pristine list of force-ranked priorities looks like heaven. FINALLY, we can make decisions. To others, it is NOT GOOD. This is why efforts to visualize WIP often turn into Game of Thrones.
There’s a silver lining with all this!
If you are aware of these tendencies, you can figure out approaches to prioritization that can nudge the org in the right direction. Knowing that the theoretically pristine force-ranked list of efforts is likely not possible, you can devise other strategies like building more realistic models with finance and being more open to “everything in high priority” yet focusing on the actual conflicts/trade-off decisions, etc.
And embrace products like Runway and DoubleLoop that engage people in tangible discussions about how $s flow into outcomes and then back into your core models.
I’ll grant that a useful, single, stable, force-ranked list is unlikely to ever emerge — but then leaders need to guide teams in how to make tradeoffs between conflicting priorities. Is “security” more important than a data locality project with a deadline? You shouldn’t need to go to the CEO to get the answer. I like the idea that investment decisions are a viable replacement for static priority lists — but only if the teams then have agency to own their priorities.
It’s also worth considering the impact of priorities constantly *changing* — if the big priority last month was data locality and now loljk we’re not doing that after all, leadership needs to accept that there will be wasted work and switching costs.
Budgeting in its essence has nothing to do with re-prioritization.
Budgeting needs to decide on the bucket of investments. That’s it. No scope.
Re-prioritization needs to be done at the level of product teams running constant experimentation and incremental delivery.
The cost of delay is often the confounding variable here.
brilliant points!
1.) strategic priorities tend to change faster than the structure of the tactically executing organization itself.
2.) There are different kinds of priorities – strategic, tactical, and operational. for better or worse, these constrain each other and compete for resources and capacity.
3.) there are many flavors of capacity. this usually gets boiled down to “how many 40 hr work weeks do we have in the org?” but in reality, there is a mental cost to context switching, an emotional cost to uncertainty, etc.
4.) there will always be a tension (perceived or real) between concrete priorities and the imperative for nimbleness.
This tracks with my experience. Orgs do focus more on budgets as those must be set by date x (whereas priorities can wait and many orgs do know they will shift).
But, this lack of a clear ‘stack-ranked’ list, and the fact that there is generally no brake on starting new work without finishing existing work, means that teams are forced into context-switching and trying to figure out the priorities themselves. Or you start seeing how the fundamental power politics of the org work as people seek to get their own work through…
We can’t be too purist in our thinking here. It is a complex puzzle and we can’t always plan or schedule our way out of it. Dynamic prioritisation is hard if work items are large. And it’s not all items that need to be prioritised in this way – the top items are generally labelled in some way (‘strategic’ or some such tag) and bulldoze everything else. Its trying to gracefully determine what of the other work gets done without it turning into a Game of Thrones scenario.
What we don’t see, because of this connection between people and initiatives as part of the budgeting process, is orgs that actually have enough (or any capacity) to absorb the amount of change in work and priorities that happens every year.
I have to disagree with para 1. Your statement about doing multiple high-priority things at once seems a bit of a strawman – I think most people realize that the larger a company is, the more high-priority things it can do at once. The problems arise when this capacity is not well understood, and when there’s a lack of ability or will to firmly say “no” to this capacity being exceeded. Jumping straight to “fix the org design” without addressing these factors first, seems premature.
The money quote —> “If you are aware of these tendencies, you can figure out approaches to prioritization that can nudge the org in the right direction. Knowing that the theoretically pristine force-ranked list of efforts is likely not possible, you can devise other strategies like building more realistic models with finance and being more open to “everything in high priority” yet focusing on the actual conflicts/trade-off decisions, etc.” It’s a very human art.
John Cutler, the problem is that people think in terms of budgets for projects, not products. We all know that products have a longer life cycle than projects (or at least that’s the goal :-). Only if you think in longer periods of time does it make sense to make changes in the organization (development and business!). This means that you actually have to identify the product(s) first and then allocate budgets for them.
And I agree with Alexey Krivitsky 🌈: Prioritizing what to develop and deliver first should be separate from budgeting. Otherwise you’re back to the old pattern (my wallet is bigger than yours).
At some point reality asserts itself which looks like – you must deliver all this because we are not incentivized to hear reality before the facts assert themselves, followed by you’ve failed to deliver all this, followed by a retrospective ‘why did you not tell us the reality on the ground’ …? The reality is people prefer reality later than sooner. There are not many brave enough to be soldiers on the reality front line. It is dangerous there.
To view or add a comment, sign in