They're fine enough for aligning the work of few related teams, but OKRs suck when forced on individuals as the focus for regularly scheduled performance evaluations.
Does anyone have examples of "good" OKRs for a developer / individual contributor worth sharing? Typical guidance I've seen is either generic to the point of uselessness or else involves numbers that are just completely outside the control of anyone in my role. The alternatives amount to one for one copies of Jira epics, which are too susceptible to the whims of product management or else personal growth stuff which is the first thing dropped when crunch time comes knocking. The obligation to write individual OKRs feels like providing a list of reasons to deny promotions when plans inevitably change over the course of an evaluation period. It's as if it were all smoke and mirrors for management to justify whatever it is they already wanted to do with you.
"They’re hard, but sold as something that everyone should do, so everyone does them poorly, and most people don’t see any value as a result."
OKRs are inane management fad. OKRs are "hard" because Objectives are vague and Key Results are vague leading to vague definitions of success and arbitrary flag planting.
Any management concept that is simultaneously so hard that no one does it right, but yet everyone is doing it is proof in point how valueless it truly is. Of course, when compensation, bonuses, and kudos are tied to OKR, people will keep doing them, as hard or as vague as they might be.
"Good OKRs tell a story about what is important, they help you inspire people to think about why they are working on what they’re working on, and I think they carry a bit of energy that comes from seeing how it all fits together in a succinct form."
My experience was with them being imposed by mid level tech managers who went to a conference, read half a book or had a consultant whispered in their ear.
They didn't know what a good OKR looked like, but know the one your proposed isn't what they want. Keep iterating until everyone gets fatigued and you eventually settle on a set of OKRs everyone hates. Then priorities move enough that none of it matters by the time you planned to measure.
OKRs were used for pivoting Intel from being a memory company to a processor company in a super short time frame. I believe they were quite successful.
Yes, this is the problem with things like OKR and OGSM.
People write up incredibly vague examples to protect imagined IP, or a bunch of counterexamples.
Rarely do you see anyone public a set of "this is what good looks like".
I don't think line workers on assembly lines have much exposure to OKRs.
OKRs are entirely about creative work and have seen success at tech companies that take management seriously.
The problem is that throughout the industry most managers were promoted into those positions without any training for being good at something else entirely. So even if they want to care, they generally have no idea where to begin. Self help books about business "heroes?" Focus on more metrics because they're something to show? Just focus on coding because that's what got them the promo? Et al.
In my dysfunctional organization we spend half of every quarter planning OKRs for the next.
First we have to collect all of the O's from top down and adjacent team blockers. Then we have to craft measurable KRs. Engineers are usually involved to size the effort of each. Then we need to make sure the total size maps to our bandwidth. We spend weeks prioritizing, and negotiating, pushing back up and to the side the work we can't take, and organizing cross-team dependencies to refine them to the final prioritized set.
At this point engineers have been dragged far into the planning process for sizing and have been thrashed by hearing glimmers of a chance to work on project X only to find out it's de-prioritized for project Y and now they have to size that effort instead.
The PMs will remind you if there isn't a number or a binary-sounding deliverable in every KR, and will hound you about getting a baseline and building the measurement tooling if there isn't one available. Sometimes making something measurable means instrumenting A/B tests, building dashboards, or instrumenting some metric capture. If it can't be measured, it can't be done in the OKR framework.
Once we begin the actual work In the glorious 4-week period where we aren't planning our next quarter OKRs, we're meeting daily and weekly to report progress at different levels. It's exhausting. This is where a lot of blatant funny business occurs with how folks measure and report progress that destroys the whole process.
I think on paper OKRs sound logical. Concrete goals and measurable deliverables are good. In practice it's a huge time suck and far less actual progress is made. It's a toilsome framework and a drain on morale. The only folks who seem to like OKRs are upper-management and PMs who are so detached from actual work that it's the only way they can feel like things are happening.
as0301|3 years ago
sdiupIGPWEfh|3 years ago
sdiupIGPWEfh|3 years ago
rexreed|3 years ago
OKRs are inane management fad. OKRs are "hard" because Objectives are vague and Key Results are vague leading to vague definitions of success and arbitrary flag planting.
Any management concept that is simultaneously so hard that no one does it right, but yet everyone is doing it is proof in point how valueless it truly is. Of course, when compensation, bonuses, and kudos are tied to OKR, people will keep doing them, as hard or as vague as they might be.
"Good OKRs tell a story about what is important, they help you inspire people to think about why they are working on what they’re working on, and I think they carry a bit of energy that comes from seeing how it all fits together in a succinct form."
That sounds more like a mission statement to me.
steveBK123|3 years ago
They didn't know what a good OKR looked like, but know the one your proposed isn't what they want. Keep iterating until everyone gets fatigued and you eventually settle on a set of OKRs everyone hates. Then priorities move enough that none of it matters by the time you planned to measure.
bennine|3 years ago
They are helpful because they align effort and energy, top to bottom, in the direction most relevant for the business.
It goes without saying that if the organizational OKRs are messed up, then it’s messed up all the way to the bottom.
xiphias2|3 years ago
OKRs were used for pivoting Intel from being a memory company to a processor company in a super short time frame. I believe they were quite successful.
devnulll|3 years ago
ratg13|3 years ago
steveBK123|3 years ago
Rarely do you see anyone public a set of "this is what good looks like".
jl2718|3 years ago
Creative work is not an assembly line. You can't predict the effort, and you can't control the outcome.
drewcoo|3 years ago
OKRs are entirely about creative work and have seen success at tech companies that take management seriously.
The problem is that throughout the industry most managers were promoted into those positions without any training for being good at something else entirely. So even if they want to care, they generally have no idea where to begin. Self help books about business "heroes?" Focus on more metrics because they're something to show? Just focus on coding because that's what got them the promo? Et al.
Hippocrates|3 years ago
First we have to collect all of the O's from top down and adjacent team blockers. Then we have to craft measurable KRs. Engineers are usually involved to size the effort of each. Then we need to make sure the total size maps to our bandwidth. We spend weeks prioritizing, and negotiating, pushing back up and to the side the work we can't take, and organizing cross-team dependencies to refine them to the final prioritized set.
At this point engineers have been dragged far into the planning process for sizing and have been thrashed by hearing glimmers of a chance to work on project X only to find out it's de-prioritized for project Y and now they have to size that effort instead.
The PMs will remind you if there isn't a number or a binary-sounding deliverable in every KR, and will hound you about getting a baseline and building the measurement tooling if there isn't one available. Sometimes making something measurable means instrumenting A/B tests, building dashboards, or instrumenting some metric capture. If it can't be measured, it can't be done in the OKR framework.
Once we begin the actual work In the glorious 4-week period where we aren't planning our next quarter OKRs, we're meeting daily and weekly to report progress at different levels. It's exhausting. This is where a lot of blatant funny business occurs with how folks measure and report progress that destroys the whole process.
I think on paper OKRs sound logical. Concrete goals and measurable deliverables are good. In practice it's a huge time suck and far less actual progress is made. It's a toilsome framework and a drain on morale. The only folks who seem to like OKRs are upper-management and PMs who are so detached from actual work that it's the only way they can feel like things are happening.
hbrn|3 years ago
What is the objective that you're trying to achieve with OKRs?
How are you going to measure success (remember, you have to measure outcomes, not outputs)?
For a methodology that is all about metrics, it is almost impossible to measure.