Is it a prioritization issue? Or more like lack of transparency?
Sean is a Program Manager in a big corporation technology team, and as such he has the challenge to take strategic program engineering developments flow through the organization. Practically speaking, that means coordinating the work that might often happen across dozens of separated software engineering teams, which might be spread across many different technical units. Each of those technical units have their own priorities and need to serve several sources of demand.
The context of that complexity is often to be in what may seem like a never ending effort to attempt to align priorities across the board. It comes with a lot of transactional costs for coordination. And although there are regular processes in place, with a quarterly cadence where those priorities are attempted to be aligned, reality too often hits as execution start, delays in initial commitments on dependencies slip over (as priorities evolve within the separate units and teams, as they perhaps should…), and what not. The outcome is to be set for quite long lead times, really feeling like things move over here veeeeeryyy slooowwwlyyy.
I bet most people would appreciate and empathize with that - poor, Sean… I even bet that many people experience and struggle in organizational contexts that resembles a lot, or at least largely, that. And too often that is pointed out and portrayed as a prioritization issue.
If only we could ever agree across all the relevant stakeholders what our priorities are… Guess what - if you dare to ask at the highest level, that is precisely what you will likely hear senior leadership talking.
How better did we get this time around in clarifying our priorities!
They will tap in their own shoulders. And maybe indeed they did take the effort, and at the top level it is quite clear. But the proof is always on the pudding of execution. With that, I don't mean to say it is unwillingness from teams to collaborate - that is not where the problems tend to be. It's a matter of "system" (more like in an ecological term than as in a machine, to be clear).
And I would reframe it as rather a matter of transparency. Or lack thereof…
As in not clear what is the sort of selection criteria. How do you make sure your demands (dependencies from other teams) are in the queue for being pulled for an eventual commitment. What are the rules of engagement with that team and their processes?
But also unclarity on scheduling, and therefore know when something can be started.
What about how does the sequencing look like? How can I know by when, with how much time in advance, my demand typically (like based on fairly predictable lead time distribution patterns which are either positioned as service level agreements or at least expectations) would need to be started so that it can be done by the time I expect it.
And finally, what are the underlying rules in terms of urgency of treatment (or by its technical term: class of service) after starting, so that I know things can be sort of short-tracked if we are running out of time and there is no possible compromise in timing.
It does turn out that those are, essentially, more accurate aspects and nuances of what priority means. But in a much more concrete basis, not an abstract definition of whether something is going to make the cut (or not) in a too often fairly arbitrary basis - which is what most commonly is treated as prioritization.
The point I am making is that it all starts with transparency. With clarity on the rules of the game, or explicit policies. Also, from the perspective of work visualization - so that everyone is seeing the same thing, and all the relevant levels needed for operational coordination, but also strategy execution. So that relatively simplifying and federated (i.e., distributed/delegated to the teams) decision-making can be unlocked - such as, default selection rules that would lean towards doing first what is needed to finish portfolio level work that is closer to be delivered towards customers/users.
I fully appreciate this may sound idealistic, and I know that’s much easier said than done. That doesn’t make it impossible, though. And it can become quite practical in the sense of unloading cognitive load for those that need to coordinate work across, so that they can focus on the true exceptions and critical dependencies that truly matter, while knowing that the vast majority can be dealt with sensible default setting (based on system thinking nudged behaviors with clear and simple processes).