TBM 285: Shared Teams and Apples-to-Oranges Priorities

Here is one of the most common anti-patterns I see in product work.

Leadership dutifully converges on a few equally weighted priority “pillars”. The priority pillars don’t lend themselves to being prioritized against each other as stated (e.g., one relates to new revenue, the other to customer satisfaction, and another to reduce costs). Apples to Oranges. Different teams latch on to different priorities, but they all depend on teams that, in addition to serving those dependencies, also have work linked to top-level priorities (Team D in this diagram).

Every team is doing legitimately high-priority work. Yet the teams serving dependencies are left with a problem. Their options are:

Ruinous Pragmatism. You try to make everyone happy but end up making everyone mad at you (and losing trust in you) because you let everyone down. This becomes a wicked cycle of unrealistic commitments, dropping the ball, and eroding trust. Oh, and you also ignore your own priorities. Pros: You can do this for a couple of cycles before people lose trust, and it seems proactive. Cons: It almost never works.

Go Kind of Rogue. Make prioritization calls in a vacuum, avoid direct conflict, remain a bit aloof, and hedge your bets on counteracting disappointment with a good track record of shipping and achieving some of your own goals. Pros: You stay fast and effective and get to your goals. Cons: You are not inclusive and will likely build resentment in your team among certain patterns when you randomly decide they aren’t important.

Cage Match. Have their “customer” teams fight for their capacity by forcing some kind of sequenced queue or similar (if escalated, this could include a leader being the tie-breaker or prioritizing lists of projects). Pros: great for sequencing. Cons: you’re pegged as a “service” team because you’re hands-off, and the teams resent you for making them fight each other. Leaders resent having to be the tie-breaker. Teams just work around you.

Partnership & Global Priorities. Advocate for either an apples-to-apples prioritization scheme or for someone to prioritize the priorities so teams can autonomously make the call and say, “See, here are the force-ranked priorities” or “Well, the strategy talks about how to tie-break in these situations.” Pros: autonomous, empowering, and effective. Cons: Leaders resent you for forcing them to prioritize the priorities. Why can’t you just deal with it on a case-by-case basis?

Partnership and Global Priorities are the ideal (IMHO), with Cage Match as a close second, but they are both hard to pull off. Realistically, most shared teams do a mix of all of these. 

Another interesting thing starts to happen. If a team can’t force a shared team to focus on their thing, or if those teams are impossibly slow to help, they often just work around other teams and finish whatever they can get done autonomously. Go Really Rogue. This leads to a dynamic whereby global output doesn’t match priorities, and people start second-guessing the whole system. At the same time, everyone points at those teams and says, “See, why can’t you show initiative and ship like Team X? They take matters into their own hands!”

In product work, we typically think of shared platforms and enabling teams when we think of dependencies. Realistically, however, it can also happen with GTM teams. Marketing and Customer Support are great examples of teams that 1) enable releases and 2) have their own goals and mapped priorities.

So, if you help multiple teams, what can you do about it?

In the current climate, teams are having a tough time addressing this. No one wants to be seen as obstructionist and be part of the next round of layoffs. At the same time, ruinous pragmatism quickly backfires. Partnership might be tough between understaffed groups that have competing priorities. 

I think the answer is probably Cage Match, for now. You must defend your capacity at all costs and ensure you can move work across your Kanban board. You can’t afford to shoulder tons of WIP, and leadership will seek evidence that you can get things done. If you have some flow, you can make a case that work further down the queue will not be too far from work starting, ultimately delivering value.

Ideally, once things stabilize, you can move to more partnerships and clear decision/prioritization heuristics to enable more autonomous sequencing.