I used to invite *other teams* to my teams OKR meetings fairly often (maybe not every time, but at least a couple Qs out of the year) for this exact reason. Those teams were either dependent teams (teams we depended on outputs from, which were often *their* OKRs) or teams that depended on my team (our OKR was their input). You can overdo this but the resulting discussions were often interesting.
You've already convinced people that their P0s can't all be P0s. But now they're all trying to squeeze in at least a *little* work for the quarter – surely you can at least write a design doc, right!? Now you have a dozen needles to move and make no measurable progress on any of them
if this happens the OKR should be divided into (at least) 2 parts - the part you might do this Q and the rest. And... that bit should be prioritized like any other OKR.
One of the things i always found a little annoying about OKRs is that unlike backlog items, there's no real formality to "estimating the work" that one of them is. (ie. is this bigger than a breadbox or not). Which leads to the P0 that turns out to be *way* bigger than anyone expected and ends up 1/3rd done at the end of the Q. It seems like there should be a way of handling that situation when comparing OKRs for priority. Just saying "you can have 3 P0s" doesnt really cover it.
Here's a 9 min audio version of "Seven habits for effective OKR management" from Wednesday Wisdom converted using recast app.
https://app.letsrecast.ai/r/3a303c9f-abce-4c02-9856-3edf1efb9b70
Rule 6.
This is the thing.
I used to invite *other teams* to my teams OKR meetings fairly often (maybe not every time, but at least a couple Qs out of the year) for this exact reason. Those teams were either dependent teams (teams we depended on outputs from, which were often *their* OKRs) or teams that depended on my team (our OKR was their input). You can overdo this but the resulting discussions were often interesting.
Bonus exercise: OKR priority haggling, stage 2.
You've already convinced people that their P0s can't all be P0s. But now they're all trying to squeeze in at least a *little* work for the quarter – surely you can at least write a design doc, right!? Now you have a dozen needles to move and make no measurable progress on any of them
if this happens the OKR should be divided into (at least) 2 parts - the part you might do this Q and the rest. And... that bit should be prioritized like any other OKR.
One of the things i always found a little annoying about OKRs is that unlike backlog items, there's no real formality to "estimating the work" that one of them is. (ie. is this bigger than a breadbox or not). Which leads to the P0 that turns out to be *way* bigger than anyone expected and ends up 1/3rd done at the end of the Q. It seems like there should be a way of handling that situation when comparing OKRs for priority. Just saying "you can have 3 P0s" doesnt really cover it.