Hi John. This post really spoke to me. I’d love to talk to you about what we are doing with AgendaScope and strategic execution. We directly tackle prioritisation but are still thinking through how priorities connect to each other. Be great to get your view.
As a starter for 10. We handle prioritisation of agenda items using scores across 3 factors to produce a priority agenda. It’s quite difficult in our system to not end up with “this is actually more important, even if only slightly more so, than this”. I see a key problem in this situation as being that people don’t have enough resolution (or will) to put one in front of the other. But you can’t have two #1 priorities.
Nice to have some language to talk about these choices. I want to share that I've found 'choosing by advantages' useful to get to apples-to-apples comparisons, which can help on most cases. The essence of the approach is to avoid lists of pros and cons, instead restating each con as an advantage for the competing idea(s). Proper intro here - https://www.youtube.com/watch?v=W9bQ5mkxRI4
I definitely recognise this anti-pattern from my experience in internal products. As well as resource contention I've seen that sometimes the cost of going rogue is an architectural one: proliferation of features and integrations that make the enterprise even more tangly. It creates technical debt. And then some poor team then has responsibility for trying to untangle it. Or a data team has to make sense of a tangly data model. Definitely needs an architectural roadmap view to inform the prioritisation.
“Really Going Rogue” is particularly dangerous, for the reasons you shared. It is often the path of least resistance that is celebrated in the moment, but it’s damage tends to play out over the long-term (as local optima solutions proliferate)
I need to reflect on this a bit more, but I can't help feeling this connects with the thinking of Team Topologies and team interaction modes. Along the lines of...
Ruinous pragmatism - is like an anti pattern of X-as-a-service - consumption of the service but without clear team APIs or service expectations. "we'll do our best, but we have quite a lot of other stuff on at the moment"
Go Rogue - is like an anti pattern of facilitation or collaboration. "we know we should work with them but it's too hard so we'll just do our own thing"
Cage Match - a positive pattern of X-as-a-service but with very clear (possibly strict or even restrictive) rulesets (Team APIs?) around how teams must justify their demand (e.g. biggest benefit justification goes to the top of the list)
Partnership - Positive patterns of facilitation and collaboration modes with clear escalation when needed.
The fundamental problem is in the diagram. Eliminate the dependency for goal delivery so A, B, and C can deliver autonomously and nobody has to enter any cage matches. Changing the structure may require a different type of hard decision from leaders, which may be simpler or more difficult to put in place depending on your situation. But you can also take "adverse possession" and empower them directly without permission.
My current client has attempted to create partnership by embedding someone from Team D with the "customer" teams to eliminate dependency and help them become autonomous. But they haven't taken the "hard decision" to trust that individual to make the right judgements, and instead continue to do what they've always done. Consequently they remain stuck at ruinous pragmatism.
If you reduce the dependency by embedding then you aren't resolving the conflicting priorities at leadership level, but making it easier to autonomously make progress on all of them at execution level. And if you're already embedding, why not go whole hog and eliminate the dependency altogether? (Of course the anti-pattern Cameron describes of "embed, but not really" is doomed to failure anyway.)
If a team have flow (stable system, thin-tail lead time distribution) and good understanding of their capacity to deliver (understand their lead time distribution and key indications on service delivery, like typical lead time [mode to median], 85th percentile for high confidence), then you can at least have a way to set expectations. Then indeed it can become a game on how you get the sequence by which you should pull work to your system somehow.
Spot on article. Can totally relate with it. The cons are deal breakers. I believe the only option is as someone pointed below to eliminate the core problem, this is the dependency with an internal team by reducing it to the bare minimum even at the risk of having duplication of code, features, storage etc. Not an "optimal" architecture... but then product teams are faster and independent. Its a trade off.
Hi John. This post really spoke to me. I’d love to talk to you about what we are doing with AgendaScope and strategic execution. We directly tackle prioritisation but are still thinking through how priorities connect to each other. Be great to get your view.
Connect on LinkedIn?
As a starter for 10. We handle prioritisation of agenda items using scores across 3 factors to produce a priority agenda. It’s quite difficult in our system to not end up with “this is actually more important, even if only slightly more so, than this”. I see a key problem in this situation as being that people don’t have enough resolution (or will) to put one in front of the other. But you can’t have two #1 priorities.
> But you can’t have two #1 priorities.
Customers' solution: Create a new priority above #1
Result: Multiple conflicting above-#1 priority projects
Nice to have some language to talk about these choices. I want to share that I've found 'choosing by advantages' useful to get to apples-to-apples comparisons, which can help on most cases. The essence of the approach is to avoid lists of pros and cons, instead restating each con as an advantage for the competing idea(s). Proper intro here - https://www.youtube.com/watch?v=W9bQ5mkxRI4
I definitely recognise this anti-pattern from my experience in internal products. As well as resource contention I've seen that sometimes the cost of going rogue is an architectural one: proliferation of features and integrations that make the enterprise even more tangly. It creates technical debt. And then some poor team then has responsibility for trying to untangle it. Or a data team has to make sense of a tangly data model. Definitely needs an architectural roadmap view to inform the prioritisation.
“Really Going Rogue” is particularly dangerous, for the reasons you shared. It is often the path of least resistance that is celebrated in the moment, but it’s damage tends to play out over the long-term (as local optima solutions proliferate)
I need to reflect on this a bit more, but I can't help feeling this connects with the thinking of Team Topologies and team interaction modes. Along the lines of...
Ruinous pragmatism - is like an anti pattern of X-as-a-service - consumption of the service but without clear team APIs or service expectations. "we'll do our best, but we have quite a lot of other stuff on at the moment"
Go Rogue - is like an anti pattern of facilitation or collaboration. "we know we should work with them but it's too hard so we'll just do our own thing"
Cage Match - a positive pattern of X-as-a-service but with very clear (possibly strict or even restrictive) rulesets (Team APIs?) around how teams must justify their demand (e.g. biggest benefit justification goes to the top of the list)
Partnership - Positive patterns of facilitation and collaboration modes with clear escalation when needed.
The fundamental problem is in the diagram. Eliminate the dependency for goal delivery so A, B, and C can deliver autonomously and nobody has to enter any cage matches. Changing the structure may require a different type of hard decision from leaders, which may be simpler or more difficult to put in place depending on your situation. But you can also take "adverse possession" and empower them directly without permission.
For me, that's the Partnership route.
My current client has attempted to create partnership by embedding someone from Team D with the "customer" teams to eliminate dependency and help them become autonomous. But they haven't taken the "hard decision" to trust that individual to make the right judgements, and instead continue to do what they've always done. Consequently they remain stuck at ruinous pragmatism.
If you reduce the dependency by embedding then you aren't resolving the conflicting priorities at leadership level, but making it easier to autonomously make progress on all of them at execution level. And if you're already embedding, why not go whole hog and eliminate the dependency altogether? (Of course the anti-pattern Cameron describes of "embed, but not really" is doomed to failure anyway.)
100%!
If a team have flow (stable system, thin-tail lead time distribution) and good understanding of their capacity to deliver (understand their lead time distribution and key indications on service delivery, like typical lead time [mode to median], 85th percentile for high confidence), then you can at least have a way to set expectations. Then indeed it can become a game on how you get the sequence by which you should pull work to your system somehow.
Spot on article. Can totally relate with it. The cons are deal breakers. I believe the only option is as someone pointed below to eliminate the core problem, this is the dependency with an internal team by reducing it to the bare minimum even at the risk of having duplication of code, features, storage etc. Not an "optimal" architecture... but then product teams are faster and independent. Its a trade off.