So far, all companies I've seen that use OKRs operate something like this:
Start of quarter -
Management: We need to increase X.
Dev: Okay, here's how I'll break that down... (key results)
One month later -
Management: Everything's changed... Y is the top priority now!
Dev: Okay, that means we should focus on fozbuzzles.
One month later -
Management: Oh, man, what we really need to focus on is Z!
Dev: Alright, we can do that if we de-emphasize X and Y. Let's get Z done!
End of quarter -
Management: You didn't meet any any of your OKRs other than Z!
Dev: ...but you told me to drop X and Y...
Honestly, I've never seen an OKR that was relevant by the end of a quarter... We finish them or not, but the objectives are always wildly different every few months and priorities change.
Frankly, the start-of-quarter OKR system is incredibly disheartening... None of my major accomplishments or the primary focus of my work ever winds up being recorded, as only the items set at the first of the quarter are evaluated.
I've worked at other places (outside of tech) where the emphasis was on recording what you worked on and why at the _end_ of the quarter. In my experience, it's smoother for everyone. I'm a bit surprised at the focus on quarterly, pre-set OKRs in tech... It seems like a more adaptive process would be better for everyone.
> Honestly, I've never seen an OKR that was relevant by the end of a quarter... We finish them or not, but the objectives are always wildly different every few months and priorities change.
I think there are two types of priorities, "fires" and "nice to haves".
Fires are high priority, unpredictable, and often need to be solved quickly. This is things like "our databases crash every morning" or "our AWS bill is too high and going to put us out of business".
Nice to haves can still be needed, but they tend to take a back seat when a fire happens. Additionally, their priority tends to be much more subjective. This is things like "Our build process takes too long" or "our deploy process has too many manual step which leads to human error".
OKRs tend not to last a full quarter because any tasks/priorities that you can schedule and make fit nicely into a 3 month period are "nice to have"s. I'm not saying they don't matter, but the timeline to get them done doesn't really matter so things get delayed or moved around.
On the flip side, you can't schedule fires and you usually can't delay them either. The things that actually important enough that they can't get delayed tend not to fit the OKR framework.
Start of quarter - Management: We need to increase X. Dev: Okay, here's how I'll break that down... (key results)
One month later - Management: Everything's changed... Y is the top priority now! Dev: Okay, that means we should focus on fozbuzzles.
One month later - Management: Oh, man, what we really need to focus on is Z! Dev: Alright, we can do that if we de-emphasize X and Y. Let's get Z done!
End of quarter - Management: You didn't meet any any of your OKRs other than Z! Dev: ...but you told me to drop X and Y...
Honestly, I've never seen an OKR that was relevant by the end of a quarter... We finish them or not, but the objectives are always wildly different every few months and priorities change.
Frankly, the start-of-quarter OKR system is incredibly disheartening... None of my major accomplishments or the primary focus of my work ever winds up being recorded, as only the items set at the first of the quarter are evaluated.
I've worked at other places (outside of tech) where the emphasis was on recording what you worked on and why at the _end_ of the quarter. In my experience, it's smoother for everyone. I'm a bit surprised at the focus on quarterly, pre-set OKRs in tech... It seems like a more adaptive process would be better for everyone.