TL;DR: neither are a solution on their own. Whenever you have more than one team (in which case Global effectively equals Local) you need both.
This post comes as a train of thought after reading and responding briefly to Wolfram Mueller on LinkedIn, with a post that “all local priority schemes lead to wrong decisions”.
Please stop using local priority methods that only look at a single team or project.
[…] Local priorities are almost always fatal for overall performance. You can only prioritize at the main constraint, and only top management can do that effectively, since they own the company’s P&L. Yes, forget about this “local decision stuff” if it comes to the constraint then each decision is P&L relevant.
My quick response, got a bit long-winded – because of course there is more nuance here and the binary/bombastic advice above leaves out some important things worth considering.
There’s an interesting paradox here worth exploring: 1. I would agree that understanding global P&L impacts and constraints are super important, and that senior leaders are often (but not always) best placed to figure those out. 2. At the same time, as Donald Reinertsen says, “all prioritisation is local” – so it’s worth understanding how your communication of those organisation-wide concerns manifest in your particular context at the various local optimisation points.
Overall, I’d say you can’t expect a senior leader to figure out all of the tradeoffs across what is usually a hugely complex system and determine the local options, order of attack and how to respond as information arrives. Most larger orgs that I’ve worked in have an extremely lossy information transfer process that means senior leaders never have a pixel perfect picture of the “now”, and they definitely don’t have fast enough feedback loops.
I’ve written previously about how to effectively combine a global prioritisation and the local, in an attempt to optimise both of those as best we can in a complex system – using Cost of Delay as the link between the two.
This Global vs Local prioritisation issue gets harder the more teams you have, of course, because it is actually a communication and information flow problem at its heart. If you could have instant feedback loops with no loss of information between individuals, then the translation of global prioritisation into locally relevant – well, then prioritisation would be simple. It’s not though. Feedback loops, about risks, tradeoffs in the design, what works better or worse and even progress are slow and prone to misunderstanding or miscommunication.
It’s also affected by your org design, and how your teams or squads might be arranged around the tech and what they have the skills to change. A set of 10 teams that can all ship changes to every part of the tech in very small reversible steps that can flow from idea to learning very fast? I’ve never seen that in practice – although I have pushed a lot of organisations in that direction, because dependencies are one of the primary areas of friction for you to quickly deliver and discover what works and what doesn’t. So, of course, you have to take account of that. Team Topologies is a good starting point for at least thinking about the options, and how you might change things to improve the speed and reduce dependencies.
I do agree that senior leaders have an important role to play. But I’d say it’s less about a grand “central planning” function – like most PMOs try to do – and more like recognising that the primary function of senior leaders is in the effective communication of the Cost of Delay of various opportunities – so that the local prioritisation can take account of this – and to take your hands off the steering wheel and let the local representatives (i.e. the Product folks) do what they are best placed to do.
Senior leaders also need to understand the tradeoffs of different org designs, explain those to the team, and make it clear what it is that the org is trying to optimise for. Is it faster learning? Is it predictability (because you have some hard external deadlines that are set in stone)? Is it risk reduction over the long term or the shorter term? Are you breaking new ground with lots of unknowns at the customer end of the process, so you’re trying to shorten that particular feedback loop so you don’t waste lots of time and energy running faster in the wrong direction? Are you just delivering “fast follower” fairly well-understood changes and filling out obvious product gaps? Are you carrying a boatload of technical risks, and need to rework key components as quickly and safely as possible? Each of these would suggest slightly different setups, with different tradeoffs and ways to manage flow and priorities between global and local. That’s what I’d suggest senior leaders need to be focused on.
The last point I wanted to add, is that prioritisation at the strategic/global level is generally something I’d say should change gradually, not suddenly, and should be done rarely. Reorienting your teams around new strategic goals takes time, and you really want to avoid the whiplash of constantly changing priorities. At the local level, they’re MUCH closer to knowing whether a particular seam of value has been largely tapped out, and when it’s time to move on to another seam of value. They also have better understanding of whether an experiment has run long enough to have sufficient data to figure out whether it’s working or not. That’s not something that senior leaders should inject themselves into. This is what I was meaning when drawing the analogy of Pete Burling behind the wheel of an America’s Cup yacht. You have to trust the team out on the water, give them the wheel and let them figure out. Doing that gives you results like this.
