Thoughts on OKRs(joeblu.com)
joeblu.com
Thoughts on OKRs
https://joeblu.com/blog/2022_05_okrs/
178 comments
Every time I've seen it tried (over and over again in the span of a 30-year career), the "goals" are based on whatever the priority/flavor-of-the month happens to be when goal-setting is announced. I've never seen those priorities last an entire year, but I have been called to account for why I didn't personally meet the goals that I was pressured into setting "for myself" even though the priorities shifted over the course of the year.
I worked at Google and been on teams where OKRs are used very ineffectively. Since then, I've read one thing that really changed the way I think about "goals" and could alleviate the problem you mention here. It's called the product strategy stack:
https://review.firstround.com/set-non-goals-and-build-a-prod...
If you have time, listen to the podcast. This is really the most comprehensive treatment I have seen related to OKRs and goal setting. Basically, goals are the last thing you consider. What is often missing is the high levels of the stack clearly articulated such that the goals make sense and measure progress towards a strategic outcome:
"Our strategy is to increase revenue by 5%’ or ‘Increase retention by 10%.’ That’s not a strategy, that’s a goal. It’s great if you can achieve that goal, but only if it’s actually part of a larger strategy that the company is trying to advance,” Mehta says.
“I often see teams get into a mode where they’re just doing anything and everything to move the goal, without actually realizing they’re headed in the wrong direction from a strategic standpoint to create long-term value.” "
https://review.firstround.com/set-non-goals-and-build-a-prod...
If you have time, listen to the podcast. This is really the most comprehensive treatment I have seen related to OKRs and goal setting. Basically, goals are the last thing you consider. What is often missing is the high levels of the stack clearly articulated such that the goals make sense and measure progress towards a strategic outcome:
"Our strategy is to increase revenue by 5%’ or ‘Increase retention by 10%.’ That’s not a strategy, that’s a goal. It’s great if you can achieve that goal, but only if it’s actually part of a larger strategy that the company is trying to advance,” Mehta says.
“I often see teams get into a mode where they’re just doing anything and everything to move the goal, without actually realizing they’re headed in the wrong direction from a strategic standpoint to create long-term value.” "
One of the downfalls of OKRs is that in many cases the true objective for people and/or teams is not something that can be mentioned without being unspeakably impolite. For example, the political goal "I as CTO want my department to grow by N FTEs so that I will gain in prestige compared to my peers in the C-suite" is definitely not something you will ever see on an OKR sheet but is definitely something that happens. On the other end of the influence spectrum, "I want to learn technology X because it will look good on my resume when I job-hop in a year from now" is also something you can't really use as a reason in a corporate setting but still definitely something that happens all the time.
If you cannot start from the real Objectives and have to make up fake ones, determining effective Key Results to go with them is bound to lead to confusion.
If you cannot start from the real Objectives and have to make up fake ones, determining effective Key Results to go with them is bound to lead to confusion.
This hidden agenda issue can be very problematic, as you say it might be self-evident based on watching people leave that they've gone somewhere else for the "better" tech stack but you'll unlikely to get anyone to admit to it, unless you're working somewhere progressive and/or with a progressive manager etc.
My last place we intentionally didn't use K8s but we were upfront with our team and hires (it was almost one of the first things I mentioned when recruiting) along with the reasoning.
But unless people are honest about their motives, and this is something that has to cascade down from the top, you'll get all sorts of sabotaging behaviour, especially if OKRs are imposed from the top and not bought into/negotiated across the org.
This gets worse when (due to human psychology and fast brain/slow brain traits, with the slow brain backing up the knee jerk fast brain) goals like the ones you mention are hidden (in shadow - see Jung). Or as mentioned in other comments you get the whole Economics externalisation problem when all sorts of 2nd and 3rd order+ goals (like team/org cohesion, fixing technical debt, taking ownership of incidents/problems or going the extra mile) which aren't in any of the OKRs get gamed out of the system because no-one's tracking them. This would be fine if the OKRs are light touch guides and not excuses to stick everything else on the bonfire. i.e. OKRs are in service and not master.
I'm not sure how you mitigate this other than hiring people aligned with company values/goals/action who are less likely to just be (understandably because it's a jungle out there) maximising their pay and the modernity of the tech stacks they know and foster a culture of co-operation not competition.
My last place we intentionally didn't use K8s but we were upfront with our team and hires (it was almost one of the first things I mentioned when recruiting) along with the reasoning.
But unless people are honest about their motives, and this is something that has to cascade down from the top, you'll get all sorts of sabotaging behaviour, especially if OKRs are imposed from the top and not bought into/negotiated across the org.
This gets worse when (due to human psychology and fast brain/slow brain traits, with the slow brain backing up the knee jerk fast brain) goals like the ones you mention are hidden (in shadow - see Jung). Or as mentioned in other comments you get the whole Economics externalisation problem when all sorts of 2nd and 3rd order+ goals (like team/org cohesion, fixing technical debt, taking ownership of incidents/problems or going the extra mile) which aren't in any of the OKRs get gamed out of the system because no-one's tracking them. This would be fine if the OKRs are light touch guides and not excuses to stick everything else on the bonfire. i.e. OKRs are in service and not master.
I'm not sure how you mitigate this other than hiring people aligned with company values/goals/action who are less likely to just be (understandably because it's a jungle out there) maximising their pay and the modernity of the tech stacks they know and foster a culture of co-operation not competition.
> I'm not sure how you mitigate this other than hiring people aligned with company values/goals/action who are less likely to just be (understandably because it's a jungle out there) maximising their pay and the modernity of the tech stacks they know and foster a culture of co-operation not competition.
I’m not sure it’s possible to grow beyond a small group of people and actually maintain that. People would need to feel some significant ownership in the company and you can’t spread a meaningful amount ownership across hundreds or thousands of people. And that’s after the investors and execs take their cut
I’m not sure it’s possible to grow beyond a small group of people and actually maintain that. People would need to feel some significant ownership in the company and you can’t spread a meaningful amount ownership across hundreds or thousands of people. And that’s after the investors and execs take their cut
That's an interesting angle, which I guess would tie in with
1) Nassim Taleb's Skin in the Game concept [1] which would seem to be analagous in some sense to creating community,
2) but sabotaged by a general (lack of) friction in people's ability to move jobs (I'm averaging about 2 years now per company, down from 4-5 years around 20 years ago) and this isn't seen as a negative.
3) This obviously can create large internal friction, especially when every new person brings new challenges (or fads) to the strategic direction such that you can spend more time changing (tooling or process or organisation structure) than actually doing real work.
4) As mentioned in a recent post here, this tendency to pay market rate for new hires, but not to pay market rates to more productive people already working for you also exacerbates this, but everyone just shrugs and plays the game because no-one's invested enough in the process to challenge it (or those that are and do just get labelled as awkward).
So it's interesting the "fetish" for OKRs in many spaces that can make people look good, but how often do they actually track the actual "costly" actions like
a) perpetual people leaving -> hiring -> training/getting up to speed cycles
b) or number of hours wasted in meetings or context switching due to interruptions or
c) deciding to outsource something you've just spent 9 months insourcing to a different company than the original one you insourced from at great financial/opportunity cost (assuming they even succeed and it doesn't take 3 attempts) etc.?
d) Let's rewrite everything in new tool X I need on my CV because you won't pay me market rate so I'm now looking after myself...
Without surfacing these costs, how can you make effective decisions???
[1] - https://www.youtube.com/watch?v=chKZ5BVxTfY
2) but sabotaged by a general (lack of) friction in people's ability to move jobs (I'm averaging about 2 years now per company, down from 4-5 years around 20 years ago) and this isn't seen as a negative.
3) This obviously can create large internal friction, especially when every new person brings new challenges (or fads) to the strategic direction such that you can spend more time changing (tooling or process or organisation structure) than actually doing real work.
4) As mentioned in a recent post here, this tendency to pay market rate for new hires, but not to pay market rates to more productive people already working for you also exacerbates this, but everyone just shrugs and plays the game because no-one's invested enough in the process to challenge it (or those that are and do just get labelled as awkward).
So it's interesting the "fetish" for OKRs in many spaces that can make people look good, but how often do they actually track the actual "costly" actions like
a) perpetual people leaving -> hiring -> training/getting up to speed cycles
b) or number of hours wasted in meetings or context switching due to interruptions or
c) deciding to outsource something you've just spent 9 months insourcing to a different company than the original one you insourced from at great financial/opportunity cost (assuming they even succeed and it doesn't take 3 attempts) etc.?
d) Let's rewrite everything in new tool X I need on my CV because you won't pay me market rate so I'm now looking after myself...
Without surfacing these costs, how can you make effective decisions???
[1] - https://www.youtube.com/watch?v=chKZ5BVxTfY
Speaking for the devil -- that's going to happen anyway, but OKRs will force to put that into a framework, to come up with a reasonably looking excuse to do that. Better with excuse than without, no?
> in many cases the true objective for people and/or teams is not something that can be mentioned without being unspeakably impolite
At the individual contributor level the manager is always pushing for “personal OKRs” too
And I’ve never been able to be honest or “authentic” about that
Nobody could ever explain if it was professional development goals, extra responsibility or goals within the company or coding project, or actual personal. Other ICs would be excited to write their actual personal.
At the individual contributor level the manager is always pushing for “personal OKRs” too
And I’ve never been able to be honest or “authentic” about that
Nobody could ever explain if it was professional development goals, extra responsibility or goals within the company or coding project, or actual personal. Other ICs would be excited to write their actual personal.
I totally hate that bullshit. The last time I ran into this "personal goal setting" nonsense was at a company where I wasn't planning on staying around very long. You could say it was rather challenging to be authentic.
What kind of goals did you choose, that time?
I just told them what they wanted to hear, like "promoting knowledge sharing through brown bag sessions" with no intention of ever doing it.
Ok :-) I wonder if team/department goals would have been more fun in your case
I was unhappy there after the first month, so any sort of goals would've been pointless. Don't get me wrong, I did decent work and would receive excellent reviews / praise for it, I just didn't like the culture / environment.
The honest truth: I didn't have any goals, and still really don't. I just wanted good, interesting work to do during these dark times (pandemic, etc), with as few interruptions as possible.
The honest truth: I didn't have any goals, and still really don't. I just wanted good, interesting work to do during these dark times (pandemic, etc), with as few interruptions as possible.
It's funny.
When it comes to personal development, side projects, etc. I have had times when I was very interested in setting specific goals and other times when I really didn't want to.
When it comes to personal development, side projects, etc. I have had times when I was very interested in setting specific goals and other times when I really didn't want to.
Whenever someone asks that question I tell them my personal goal is to make more money. Ironically this sometimes leads to productive conversations.
This is the dream response for any manager. I am the opposite and cared very little about making more money. I was more interested to reduce my life's operational expenses to get more out of the money I was already making. I got bounced around from manager to manager because of this. Nobody knew how to get me to do anything.
“I want to make more money” is an easy thing for a manager at a not-failing company to handle because it is so concrete and concretely deliverable.
> If you cannot start from the real Objectives and have to make up fake ones
The more you understand the real motivation of people the harder it gets to take business goals and decisions seriously.
The more you understand the real motivation of people the harder it gets to take business goals and decisions seriously.
It's like with most things in life.
If you want to become fitter, don't think "I want to lose 10kg of weight", think about finding a sport which you like and healthy food which you enjoy eating.
Your belly might not disappear 100%, but you will feel better, and you are in for the long run.
If you want to become fitter, don't think "I want to lose 10kg of weight", think about finding a sport which you like and healthy food which you enjoy eating.
Your belly might not disappear 100%, but you will feel better, and you are in for the long run.
Specifically, eating sources of ecdysteroids like Spinach, Quinoa, Masal Root, etc. These are anabolic but do not have any androgenic side effects like conventional steroids.
The Popeye spinach meme is real.
I suppose if you come from a culture that eats insects you could also get a large amount of these compounds.
https://en.wikipedia.org/wiki/Ecdysteroid
The Popeye spinach meme is real.
I suppose if you come from a culture that eats insects you could also get a large amount of these compounds.
https://en.wikipedia.org/wiki/Ecdysteroid
Eating spinach is generally good, but don't go overboard with it. For one, it's got the highest concentration of oxalic acid amongst green vegetables, and high concentrations of that can lead to kidney stones.
I don't know what would be considered too much spinach, personally I include it in my salads but not as the base (usually that's romaine for me), and sometimes Sautee some to go with eggs for breakfast, but I don't get it every grocery trip.
https://www.livestrong.com/article/529555-what-are-the-effec...
I don't know what would be considered too much spinach, personally I include it in my salads but not as the base (usually that's romaine for me), and sometimes Sautee some to go with eggs for breakfast, but I don't get it every grocery trip.
https://www.livestrong.com/article/529555-what-are-the-effec...
I’ll bite. Are you suggesting that those foods you mentioned have anabolic effects analogous to exogenous steroids?
I'm not suggesting, I'm stating.
Thanks for this. I recently left an otherwise awesome job mostly because of OKRs. I am still trying to articulate why.
I'm going to correct you, because it's relevant. Mehta says, "but only if it is actually accretive to the strategy." I think the accretive is important here, because one of my observations on how we were doing it wrong was that there were no stated goals for security against the company as a whole. This made it seem like each teams' OKRs were a chaotic free-for-all. Intuitively, the goals for security as a whole should be based on the overall needs of the company, divided up across the appropriate teams. These teams will have the tribal knowledge to write the best roadmap, determine who will own the workflow that the project generates on completion and generally know how to scope each task.
Going to listen to the podcast now. Maybe I will have more to say after. Cheers.
I'm going to correct you, because it's relevant. Mehta says, "but only if it is actually accretive to the strategy." I think the accretive is important here, because one of my observations on how we were doing it wrong was that there were no stated goals for security against the company as a whole. This made it seem like each teams' OKRs were a chaotic free-for-all. Intuitively, the goals for security as a whole should be based on the overall needs of the company, divided up across the appropriate teams. These teams will have the tribal knowledge to write the best roadmap, determine who will own the workflow that the project generates on completion and generally know how to scope each task.
Going to listen to the podcast now. Maybe I will have more to say after. Cheers.
What you are describing is the opposite of agile, and also flies in the face of devops, so it's really hard to sell it in today's management culture. However, I've never seen agile or devops development processes work. I only work on big systems with year-plus timespans.
I can imagine those processes working well for lean, piecemeal teams (like refreshing frontend site cosmetics once a year, or pumping out contract work every few weeks), or for technology-lean consumer startups building an MVP they plan to throw away once they have market fit.
When I've seen project management work well, it's always been of the form (all these bullet points are mandatory, in my experience):
- The goal for the product for the next 3-24 months is clearly articulated.
- Each sub-team's 1-6 month goals are clearly articulated.
- ICs produce a list of projects that should take one IC about a month, and that, if completed, will meet the sub-team's goal (deadline requirements are ignored during this part of planning).
- Is "Number of projects / number of ICs" significantly less than the number of months to the deadline?
- If No, this sub-team won't be able to ship, so adjust the scope, the resources, or the deadline.
- Compensation is based on the performance of the product group, not the sub-teams. Somewhere between 1-10% of new hires end up being let go within 6 months. Hiring is never perfect, and firing people less bad for morale than having people sitting around being dead weight.
Number of months varies depending on project maturity, business needs, and scope of the changes. Anything past 24 months is best done in a graduate program, not a company.
I can imagine those processes working well for lean, piecemeal teams (like refreshing frontend site cosmetics once a year, or pumping out contract work every few weeks), or for technology-lean consumer startups building an MVP they plan to throw away once they have market fit.
When I've seen project management work well, it's always been of the form (all these bullet points are mandatory, in my experience):
- The goal for the product for the next 3-24 months is clearly articulated.
- Each sub-team's 1-6 month goals are clearly articulated.
- ICs produce a list of projects that should take one IC about a month, and that, if completed, will meet the sub-team's goal (deadline requirements are ignored during this part of planning).
- Is "Number of projects / number of ICs" significantly less than the number of months to the deadline?
- If No, this sub-team won't be able to ship, so adjust the scope, the resources, or the deadline.
- Compensation is based on the performance of the product group, not the sub-teams. Somewhere between 1-10% of new hires end up being let go within 6 months. Hiring is never perfect, and firing people less bad for morale than having people sitting around being dead weight.
Number of months varies depending on project maturity, business needs, and scope of the changes. Anything past 24 months is best done in a graduate program, not a company.
Yes - ICs have tasks, not okrs. The tasks can be intended to impact a higher-level kr which defines progress of an O and that O MUST be connected the strategy of the company or it is a crap/BS O.
Honestly, what I'm hearing in this podcast is that front line teams end up with OKRs that don't anchor into any strategic product vision. I agree, OKRs should be able to trace down. Since OKRs are supposed to cascade down, this failure falls squarely on upper management, for either failing to provide and communicate a strategy, or for failing to demand that recursively itemized OKRs actually trace up to the holistic vision.
And as always, there is no process substitute for adequate management.
And as always, there is no process substitute for adequate management.
> “I often see teams get into a mode where they’re just doing anything and everything to move the goal, without actually realizing they’re headed in the wrong direction from a strategic standpoint to create long-term value.”
I see this all the time. Everyone is so focused on the "KR" that they know nothing about the "O". I want my teams to be bought into the overall Objective well before we start thinking about objective measures of progress and/or success.
I see this all the time. Everyone is so focused on the "KR" that they know nothing about the "O". I want my teams to be bought into the overall Objective well before we start thinking about objective measures of progress and/or success.
That is sad. Hope you are doing something to fix that. Sounds like people are just randomly doing stuff even though they took time to define okrs. Why define okrs in first place if just doing random stuff? Seems like a leadership issue. If you see the problem, address it. Lead or leave.
Oh yeah, I'm definitely on top of it and it's one of the constant themes of my discussions with my managers and skip-level reports. I very much start with making sure we're all clear on "why" before we even think about "what". When people know "why", they're able to contribute much more effectively and bring their own ideas and creativity to bear.
Goal setting is like other techniques in management.
The quality movement went terribly wrong when the motivation became "We want to have an ISO 20022 sign in front of the factory" as opposed to "we want to crush the competition". See
https://en.wikipedia.org/wiki/The_Goal_%28novel%29
Probably the best phrase of that novel is "There is only one goal".
I worked at an AI startup which was struggling to balance the long term needs of developing a technologically advanced product and the short term needs of delivering projects to major corporations.
I saw the adoption of OKRs to be the beginning of the end of my time there because instead of carefully teasing apart what goals were necessary to realize their strategy everybody was told that they needed to list 20 or 30 goals, simply to list 20 or 30 goals.
Not too long after I left the CEO announced that he was proud that the company had been acquired by a major athletic footware manufacturer. My hot take was "that's incredible!" because "incredible" was the CEO's favorite adjective, but really I told people all along that one of our engagements, if it fully realized its potential, would generate enough value for a customer that they'd see it as a bargain to buy the company.
So of course this just makes people even more scatterbrained than they were before and worse yet it's rocket fuel for the psychopaths and narcissists in your organization because they are geniuses at playing that kind of game and they will use it to make themselves look good while making hard working people who are more interested in doing work and realizing the strategy look bad.
The quality movement went terribly wrong when the motivation became "We want to have an ISO 20022 sign in front of the factory" as opposed to "we want to crush the competition". See
https://en.wikipedia.org/wiki/The_Goal_%28novel%29
Probably the best phrase of that novel is "There is only one goal".
I worked at an AI startup which was struggling to balance the long term needs of developing a technologically advanced product and the short term needs of delivering projects to major corporations.
I saw the adoption of OKRs to be the beginning of the end of my time there because instead of carefully teasing apart what goals were necessary to realize their strategy everybody was told that they needed to list 20 or 30 goals, simply to list 20 or 30 goals.
Not too long after I left the CEO announced that he was proud that the company had been acquired by a major athletic footware manufacturer. My hot take was "that's incredible!" because "incredible" was the CEO's favorite adjective, but really I told people all along that one of our engagements, if it fully realized its potential, would generate enough value for a customer that they'd see it as a bargain to buy the company.
So of course this just makes people even more scatterbrained than they were before and worse yet it's rocket fuel for the psychopaths and narcissists in your organization because they are geniuses at playing that kind of game and they will use it to make themselves look good while making hard working people who are more interested in doing work and realizing the strategy look bad.
I worked at a smallish (~20 employees, at the time) agency that hard pretty good management overall, but one day decided to do OKRs. I assume one of the owners read a book or attended a talk or something.
But we had no historical metrics on... anything, really, related to software development or design. Nothing that'd be useful for quarterly goals, anyway. "Close X tickets" or "make X commits" are famously shit measurements. We did client work, so we couldn't just try to decrease load times on one of our own products, or something like that.
Having nothing meaningful to use for OKRs related to our actual jobs, developers & designers just latched on to sales & marketing projects and set our OKRs for those. Video views are relatively easy to measure. Sales funnel stuff's easy to measure. "Net promoter score". All that shit. The goal-setting for OKRs strongly favored sales & marketing, for whom measuring stuff was already a lot of what they did.
I'm not sure that's what they were aiming for, but it's what they got. I hope it was at least kinda useful for the company.
But we had no historical metrics on... anything, really, related to software development or design. Nothing that'd be useful for quarterly goals, anyway. "Close X tickets" or "make X commits" are famously shit measurements. We did client work, so we couldn't just try to decrease load times on one of our own products, or something like that.
Having nothing meaningful to use for OKRs related to our actual jobs, developers & designers just latched on to sales & marketing projects and set our OKRs for those. Video views are relatively easy to measure. Sales funnel stuff's easy to measure. "Net promoter score". All that shit. The goal-setting for OKRs strongly favored sales & marketing, for whom measuring stuff was already a lot of what they did.
I'm not sure that's what they were aiming for, but it's what they got. I hope it was at least kinda useful for the company.
NPS, specifically, is a hard metric to set an objective against. You can never really separate the stuff you did to your software from all the rest of the stuff that happened to your company.
And yeah, using tickets as a success metric is gonna produce some incredibly awful behavior as people learn to game the system.
Good OKRs are not easy. It’s very hard to come up with good key results that incentivize the right behavior while actually measuring progress towards the goal. It takes quite a lot of skill to do that properly.
To me the most important part of OKR’s isn’t really the metrics… it’s the understanding that the team has been tasked with solving some problem without being told how to solve it. The team itself gets to own the solutions that drive the metric. Done correctly it lets everybody on the team take ownership of the product they are working on. It is far better than just being a feature factory that cranks out whatever sales or upper management thinks is a good solution.
And yeah, using tickets as a success metric is gonna produce some incredibly awful behavior as people learn to game the system.
Good OKRs are not easy. It’s very hard to come up with good key results that incentivize the right behavior while actually measuring progress towards the goal. It takes quite a lot of skill to do that properly.
To me the most important part of OKR’s isn’t really the metrics… it’s the understanding that the team has been tasked with solving some problem without being told how to solve it. The team itself gets to own the solutions that drive the metric. Done correctly it lets everybody on the team take ownership of the product they are working on. It is far better than just being a feature factory that cranks out whatever sales or upper management thinks is a good solution.
Okrs are very hard to define when either or both of the following occur:
1- you don’t know your business
2- you are not competent
I find #1 is more prevalent as most people are competent but I might be a bit generous in that assessment.
I find #1 is more prevalent as most people are competent but I might be a bit generous in that assessment.
> called to account for why I didn't personally meet the goals that I was pressured into setting "for myself"
This is one of the most hostile things an employer can do to a person. I don't want them involved in my personal growth -- fuck allllll of that. I will grow when and how I want to, if I even want to.
IME this never-ending push for continual improvement discourages me when I inevitably fail to meet goals they want me to want.
I want to say "just leave me alone I'm speedrunning to early retirement" but that'll just get me in more trouble.
This is one of the most hostile things an employer can do to a person. I don't want them involved in my personal growth -- fuck allllll of that. I will grow when and how I want to, if I even want to.
IME this never-ending push for continual improvement discourages me when I inevitably fail to meet goals they want me to want.
I want to say "just leave me alone I'm speedrunning to early retirement" but that'll just get me in more trouble.
I've been so busy at work I haven't had time to "define" my Q1 goals...it's Q2. I grow my skillset by doing my job well and attending trainings, I appreciate the idea of goals but they seem to set themselves.
Annually, we're supposed to cut-n-paste several goals from a long list of mgmt approved blurbs. They are either hard-to-measure or metrics that I cannot really control. Whateva.
Copy and paste is the opposite of how okrs are intended to work. But traditional annual goal-setting models do cascade.
Unfortunately Doerr presented a football team example in a pathetic attempt to explain how okrs cascade directly.
Because of this, okrs have been done poorly at so many orgs. Sadly, okrs software companies saw the simple computation from set theory to make krs be children of higher level objectives so they could make cool visual maps illustrating how okrs connect.
So, yeah, I feel you, “Whateva”
Unfortunately Doerr presented a football team example in a pathetic attempt to explain how okrs cascade directly.
Because of this, okrs have been done poorly at so many orgs. Sadly, okrs software companies saw the simple computation from set theory to make krs be children of higher level objectives so they could make cool visual maps illustrating how okrs connect.
So, yeah, I feel you, “Whateva”
I've only ever seen OKRs attempt to be used by ineffective management who want to reduce everything, people included, to a number.
I think a lot of people's introduction to OKRs is John Doerr's book "Measure What Matters". That's where I learned about them.
The book explains how Andy Grove introduced the practice at Intel and it was very effective. The book seems to attribute the success to the practice itself and seems to say "if you adopt OKRs, you will succeed like Intel did".
I suspect that this success is misattributed. I suspect that Andy Grove was probably an excellent manager and I think he could have succeeded with something other than OKRs. I think he understood that what was really important was to get everybody across the organization to focus on essentially one big goal. He needed to make sure that everybody was pulling in the same direction and together, and OKRs provided a tool to do that.
When my organization decided to implement OKRs, my question to my peers was "who is our Andy Grove?"
If the people implementing OKRs focus too much on the practice and not enough on the motivation, I think you just end up with cargo-culting. The setting and tracking of KRs becomes the objective. So people treat it like busywork because OKRs don't really seem to matter - they just gets in the way of the "important" stuff.
As one of my coworkers says, the title of the book is "Measure What Matters", but it's too easy to slide into "What Is Measured Is What Matters".
The book explains how Andy Grove introduced the practice at Intel and it was very effective. The book seems to attribute the success to the practice itself and seems to say "if you adopt OKRs, you will succeed like Intel did".
I suspect that this success is misattributed. I suspect that Andy Grove was probably an excellent manager and I think he could have succeeded with something other than OKRs. I think he understood that what was really important was to get everybody across the organization to focus on essentially one big goal. He needed to make sure that everybody was pulling in the same direction and together, and OKRs provided a tool to do that.
When my organization decided to implement OKRs, my question to my peers was "who is our Andy Grove?"
If the people implementing OKRs focus too much on the practice and not enough on the motivation, I think you just end up with cargo-culting. The setting and tracking of KRs becomes the objective. So people treat it like busywork because OKRs don't really seem to matter - they just gets in the way of the "important" stuff.
As one of my coworkers says, the title of the book is "Measure What Matters", but it's too easy to slide into "What Is Measured Is What Matters".
> I think he understood that what was really important was to get everybody across the organization to focus on essentially one big goal.
I think “focus” is the keyword and am very glad to see this pointed out.
The company I’m at has gone into OKRs thinking that it’ll be some magical, productivity unlocking tool. However, when multiple people asked what the company strategy was and what we were planning to focus on, the response was that they (C-suite leaders) wanted to continue tackling every opportunity. That they think having OKRs will lead to the same workforce being able to tackle more things. It was really weird to try and write OKRs where literally any measurable outcome could be considered success. It wasn’t a surprise when I read the OKRs for other teams and orgs and saw everyone rowing in different directions ¯\_(ツ)_/¯
I think “focus” is the keyword and am very glad to see this pointed out.
The company I’m at has gone into OKRs thinking that it’ll be some magical, productivity unlocking tool. However, when multiple people asked what the company strategy was and what we were planning to focus on, the response was that they (C-suite leaders) wanted to continue tackling every opportunity. That they think having OKRs will lead to the same workforce being able to tackle more things. It was really weird to try and write OKRs where literally any measurable outcome could be considered success. It wasn’t a surprise when I read the OKRs for other teams and orgs and saw everyone rowing in different directions ¯\_(ツ)_/¯
This was the biggest struggle we had with OKRs, rocks, EOS, etc...
Goals != Strategy and that took a while to realize.
I wish I read Good Strategy Bad Strategy and The 7 Powers first.
Goals != Strategy and that took a while to realize.
I wish I read Good Strategy Bad Strategy and The 7 Powers first.
Measure what matters is a sales book attempting to convince leaders to implement okrs.
It offers no value to anyone trying to actually deploy okrs in a given organization or team.
But hey, it does fire up execs!
It offers no value to anyone trying to actually deploy okrs in a given organization or team.
But hey, it does fire up execs!
Andy Grove wrote High Output Management, which is well worth a read.
Yeah, he was a pretty smart guy.
Thanks for the recommendation!
You touch on a really good point. Ime it’s easy to set decent KRs but Os are usually pulled out of rear bottom. No process whatsoever just on a whim of upper management. The result is they quickly realize Os weren’t good and flip flopping on goals starts after which this whole thing quickly unravels
I used OKRs on several teams to varying degrees at Google. Not a fan. Here are my complaints:
1. It makes organizations slow and inflexible. I used to joke that as soon as another team was involved in something you needed to do it would probably take a quarter. why? Well what you wanted probably wasn't on this quarter's OKRs so it would be an uphill battle to get them to do it. You'd have to argue about getting it into next quarter's OKRs;
2. OKRs can be structured in such a way that you can grade quite well while having achieved absolutely nothing;
3. Teams can be held to different standards. Some get easy OKRs. Some get harder OKRs. So it's still subject to the political-perception problems inherent in such organizations;
5. It is largely for show for upper management. I've been in 2 hour planning meetings where a bunch of teams speak for 2 minutes about what they're working on. This might be useful for directors+ but is really a waste of the time of 50-100 other people. This is a problem with status meetings too;
6. Even grading OKRs can be subjective and political. I recall one famous example where someone (cough Vic cough) said they had a goal of 100M users. They actually only got to 10M. Grade? 0.7.
There was a running meme at Google about feedback that went something like this: This project would've failed without this person. It failed anyway but it definitely would've without this person.
I like this meme because it illustrates how the same set of facts can be used to argue how someone did a good job or a bad job and the difference between the two is whether or not the org likes them. The same set of facts can be summarized as "this probject failed to ship" and "we failed fast, learned a lot and will take those learnings into future projects".
OKRs suffer from exactly those same problems.
1. It makes organizations slow and inflexible. I used to joke that as soon as another team was involved in something you needed to do it would probably take a quarter. why? Well what you wanted probably wasn't on this quarter's OKRs so it would be an uphill battle to get them to do it. You'd have to argue about getting it into next quarter's OKRs;
2. OKRs can be structured in such a way that you can grade quite well while having achieved absolutely nothing;
3. Teams can be held to different standards. Some get easy OKRs. Some get harder OKRs. So it's still subject to the political-perception problems inherent in such organizations;
5. It is largely for show for upper management. I've been in 2 hour planning meetings where a bunch of teams speak for 2 minutes about what they're working on. This might be useful for directors+ but is really a waste of the time of 50-100 other people. This is a problem with status meetings too;
6. Even grading OKRs can be subjective and political. I recall one famous example where someone (cough Vic cough) said they had a goal of 100M users. They actually only got to 10M. Grade? 0.7.
There was a running meme at Google about feedback that went something like this: This project would've failed without this person. It failed anyway but it definitely would've without this person.
I like this meme because it illustrates how the same set of facts can be used to argue how someone did a good job or a bad job and the difference between the two is whether or not the org likes them. The same set of facts can be summarized as "this probject failed to ship" and "we failed fast, learned a lot and will take those learnings into future projects".
OKRs suffer from exactly those same problems.
> what you wanted probably wasn't on this quarter's OKRs so it would be an uphill battle to get them to do it
Everywhere I've ever worked - OKRs or DPMs or Goals or whatever you want to call them or not - I've had a set of work that's assigned to me via JIRA tickets or Bugzilla tickets or some kind of ticket tracking system, and I've also had a constant deluge of co-workers asking for my help with something or other. The longer I work there, the greater the deluge of both requests for help and volume of work assigned. Every day I've ever come into work in my life (besides the one-two month "honeymoon period" when I start a new job), I have to decide between ignoring my coworkers pleas for help or slipping the deadlines on the individual tasks assigned to me.
Over the course of the past three decades, I've tried both ways - first, focusing on my assigned tasks and second, dropping everything every time I get a request for help. I've found that, overall, the second way works best. I have to constantly apologize for constantly missing deadlines, but if I keep turning away coworkers, not being enough of a "team player" shows up as a nastier mark in my performance reviews than always being behind on tasks.
Everywhere I've ever worked - OKRs or DPMs or Goals or whatever you want to call them or not - I've had a set of work that's assigned to me via JIRA tickets or Bugzilla tickets or some kind of ticket tracking system, and I've also had a constant deluge of co-workers asking for my help with something or other. The longer I work there, the greater the deluge of both requests for help and volume of work assigned. Every day I've ever come into work in my life (besides the one-two month "honeymoon period" when I start a new job), I have to decide between ignoring my coworkers pleas for help or slipping the deadlines on the individual tasks assigned to me.
Over the course of the past three decades, I've tried both ways - first, focusing on my assigned tasks and second, dropping everything every time I get a request for help. I've found that, overall, the second way works best. I have to constantly apologize for constantly missing deadlines, but if I keep turning away coworkers, not being enough of a "team player" shows up as a nastier mark in my performance reviews than always being behind on tasks.
One way I deal with this is having co-workers also create tickets if they need help with something. That way I can still be a team player but there is also documentation about how much I helped which is otherwise hard to quantify.
I've tried that approach, too - for the most part, the blowback is the same as just ignoring them or even telling them to go away. Sadly, success is and always will be 10% ability and 90% how much people like you.
> 1. It makes organizations slow and inflexible. I used to joke that as soon as another team was involved in something you needed to do it would probably take a quarter. why? Well what you wanted probably wasn't on this quarter's OKRs so it would be an uphill battle to get them to do it. You'd have to argue about getting it into next quarter's OKRs;
This. It's not a joke either. At a previous job, we wanted to use the G Suite API to access calendar data from GCP, but that required help from the Info Sec and Cloud teams (we didn't have the right permissions to do it ourselves). We got push back for asking for help because it wasn't in those teams' OKRs. So we effectively gave up for an entire quarter and then some.
Even so, how does one write an OKR for a scenario like this? Objective: be able to access GSuite API from tool Foobar so it knows about everyone's availability. Key result: Umm, can complete a feature everyone wants?
This. It's not a joke either. At a previous job, we wanted to use the G Suite API to access calendar data from GCP, but that required help from the Info Sec and Cloud teams (we didn't have the right permissions to do it ourselves). We got push back for asking for help because it wasn't in those teams' OKRs. So we effectively gave up for an entire quarter and then some.
Even so, how does one write an OKR for a scenario like this? Objective: be able to access GSuite API from tool Foobar so it knows about everyone's availability. Key result: Umm, can complete a feature everyone wants?
But this does reveal an organizational problem right; either the security teams have it right and their current work is more important, in which case maybe they are under-staffed and need more slack. Or maybe they failed to add a KR for “perform timely security review” if that is a service that they provide to the org. If you’re blocked, you should be able to raise this up and learn something as an org.
Or maybe the KRs are correct as written, but the security teams have it wrong and their KRs should be deprioritized only favor of delivering yours. When KRs clash you need to have a conversation and resolve the conflict in the way that maximizes value for the business.
Ultimately prioritization of work always involves trade-offs, and there needs to be some mechanism for handling these. No system can handle 100% of cases without adding human judgement.
To me it seems the pathology in your example is that everyone was just sticking to the KRs, instead of coming to the best business outcome (and if your request was not prioritized, you should be able to understand the reasoning used to decide that). I can see how OKRs could be used as a shield to hide from those difficult conversations, but it’s not clear to me that they necessarily make things worse; if you didn’t have OKRs maybe your teams would be finding other ways to avoid working on things that they don’t want to help with.
Or maybe the KRs are correct as written, but the security teams have it wrong and their KRs should be deprioritized only favor of delivering yours. When KRs clash you need to have a conversation and resolve the conflict in the way that maximizes value for the business.
Ultimately prioritization of work always involves trade-offs, and there needs to be some mechanism for handling these. No system can handle 100% of cases without adding human judgement.
To me it seems the pathology in your example is that everyone was just sticking to the KRs, instead of coming to the best business outcome (and if your request was not prioritized, you should be able to understand the reasoning used to decide that). I can see how OKRs could be used as a shield to hide from those difficult conversations, but it’s not clear to me that they necessarily make things worse; if you didn’t have OKRs maybe your teams would be finding other ways to avoid working on things that they don’t want to help with.
Putting this in a separate reply as it's a separate train of thought.
> Even so, how does one write an OKR for a scenario like this? Objective: be able to access GSuite API from tool Foobar so it knows about everyone's availability. Key result: Umm, can complete a feature everyone wants?
The key thing about an objective is that it is a high-level goal. You've written the implementation into the O, which is a bit of an anti-pattern.
It's a bit hard to extrapolate exactly what the context was for your feature, but let's say your team owns an internal tool that orchestrates a business ops system that manages a task queue for "agents"; say "review these potential fraud cases that the system flagged".
As this is an existing system that you're trying to improve, not a new product, your team's objective for the Q might be attacking the main stakeholder-facing pain point with "Improve response time for manual review tasks". A KR that measures this might be "P50 latency for handling fraud reviews is reduced from 5d to 1d". (This formulation gives you a progress bar -- "0% complete" is >=5d, "100% complete" is <= 1d. You can easily build a dashboard for this, which is the holy grail for KRs.)
Now, based on the observation that most of your significant delays for this process are due to tasks being scheduled on agents that are on vacation, an initiative that you propose to progress the KR is to add calendar-awareness to your service's scheduling process. But, there are a bunch of possible initiatives that could move the needle here, and so as a team you get together and figure out which are going to have the best bang-for-buck.
Formulating the OKRs like this gives the team freedom to figure out exactly how they are going to solve the problem, while also communicating to the rest of the org what you're working on (and giving the org a chance to say "isn't <other objective> way more important?". And turning the implementation into a precise KR gives you the opportunity to discuss with stakeholders whether P50 is really the metric they care about, or if the business would be better served with P99 or some other way of measuring things. These metric discussions can be annoying, but at their best they can uncover subtle differences in expectations.
Note -- this is quite process-heavy; you wouldn't go into this much detail with a two-pizza-team startup! But if your team is dedicated to this internal tool in a company of tens of teams, then this level of detail might make sense for you.
> Even so, how does one write an OKR for a scenario like this? Objective: be able to access GSuite API from tool Foobar so it knows about everyone's availability. Key result: Umm, can complete a feature everyone wants?
The key thing about an objective is that it is a high-level goal. You've written the implementation into the O, which is a bit of an anti-pattern.
It's a bit hard to extrapolate exactly what the context was for your feature, but let's say your team owns an internal tool that orchestrates a business ops system that manages a task queue for "agents"; say "review these potential fraud cases that the system flagged".
As this is an existing system that you're trying to improve, not a new product, your team's objective for the Q might be attacking the main stakeholder-facing pain point with "Improve response time for manual review tasks". A KR that measures this might be "P50 latency for handling fraud reviews is reduced from 5d to 1d". (This formulation gives you a progress bar -- "0% complete" is >=5d, "100% complete" is <= 1d. You can easily build a dashboard for this, which is the holy grail for KRs.)
Now, based on the observation that most of your significant delays for this process are due to tasks being scheduled on agents that are on vacation, an initiative that you propose to progress the KR is to add calendar-awareness to your service's scheduling process. But, there are a bunch of possible initiatives that could move the needle here, and so as a team you get together and figure out which are going to have the best bang-for-buck.
Formulating the OKRs like this gives the team freedom to figure out exactly how they are going to solve the problem, while also communicating to the rest of the org what you're working on (and giving the org a chance to say "isn't <other objective> way more important?". And turning the implementation into a precise KR gives you the opportunity to discuss with stakeholders whether P50 is really the metric they care about, or if the business would be better served with P99 or some other way of measuring things. These metric discussions can be annoying, but at their best they can uncover subtle differences in expectations.
Note -- this is quite process-heavy; you wouldn't go into this much detail with a two-pizza-team startup! But if your team is dedicated to this internal tool in a company of tens of teams, then this level of detail might make sense for you.
What's worse is when that team gets around to it next quarter, and then in their research process they realize another team needs to be involved, etc. Eventually you have a two-week project that doesn't get delivered for a year.
For sure #1 is a big problem. But are OKRs causing this, or are the big companies that are using OKRs just fundamentally slow and inflexible? (In other words, are OKRs a symptom rather than a cause?) Thinking about how to coordinate 100k engineers, the trade-offs are pretty brutal. Startup-style “move fast, break stuff” simply doesn’t scale well.
I’d like to see some case studies here. Anyone got examples they like? I hear patio11 talking about Stripe a lot, and he says stuff like “could we deliver something faster?” which I think gets at an urgency for results, interested how they coordinate the layers and orgs.
I think it’s plausible that OKRs forestall agility and innovation as-used. But (at risk of invoking the “no true Scotsman” argument), maybe these companies are just doing OKRs wrong? OKRs are supposed to be abstract enough that you can change your plan if something better comes along. So if your KR is tightly coupled to a particular implementation then you can’t pivot in the face of new information. A quarter is a long planning horizon for small/medium sized companies! But if your KR is loosely-coupled, then it leaves room for new approaches. This balance is hard! The maximally-loose O/KR for many companies is just “succeed/increase share price by X% QoQ”. This doesn’t give you any direction.
I think at their best OKRs provide bi-directional information flow; both giving a way to make output from the lower levels more legible to the upper levels, while also making the objectives, desires, priorities of the upper levels more legible to the lower levels. I think any replacement has to achieve both of these things too.
I’d like to see some case studies here. Anyone got examples they like? I hear patio11 talking about Stripe a lot, and he says stuff like “could we deliver something faster?” which I think gets at an urgency for results, interested how they coordinate the layers and orgs.
I think it’s plausible that OKRs forestall agility and innovation as-used. But (at risk of invoking the “no true Scotsman” argument), maybe these companies are just doing OKRs wrong? OKRs are supposed to be abstract enough that you can change your plan if something better comes along. So if your KR is tightly coupled to a particular implementation then you can’t pivot in the face of new information. A quarter is a long planning horizon for small/medium sized companies! But if your KR is loosely-coupled, then it leaves room for new approaches. This balance is hard! The maximally-loose O/KR for many companies is just “succeed/increase share price by X% QoQ”. This doesn’t give you any direction.
I think at their best OKRs provide bi-directional information flow; both giving a way to make output from the lower levels more legible to the upper levels, while also making the objectives, desires, priorities of the upper levels more legible to the lower levels. I think any replacement has to achieve both of these things too.
#1 is a real issue, but is actually a problem of management and company as a whole. Teams want to be silo-ed and not bothered by anyone else hence set their goals and just do them, engineering managers just care about their teams or don’t even communicate between them to check for cross team projects, and upper management never sets some actual objectives and roadmap which could have been mapped into cross team projects and goals. And goals become a religious quarter to quarter thing without allowing any deviation, and then everything is slow.
> This might be useful for directors+ but is really a waste of the time of 50-100 other people. This is a problem with status meetings too;
A status meeting serves to reinforce the social status of the one who called the meeting. No other status is relevant.
A status meeting serves to reinforce the social status of the one who called the meeting. No other status is relevant.
The most common failure states I keep seeing are:
* Reverse-engineering the todo list to produce OKRs
* OKRs being the wrong fit for the team and/or the company's lifecycle.
The second one is more damaging, because it's subtle, whereas the first is obvious to everyone involved.
Fundamentally, OKRs are a tool that should allow teams to make decisions about what to focus on, with the knowledge that they're aligned with the business objectives. If a team already has an immutable quarter+ roadmap, they're not making any decisions, they're just working; OKRs aren't a good fit for this kind of team. OKRs done well _should_ result in teams feeling empowered, because they can see the link between their actions/decisions and overall success. OKRs done poorly have the exact opposite effective; not just benign, but harmful.
* Reverse-engineering the todo list to produce OKRs
* OKRs being the wrong fit for the team and/or the company's lifecycle.
The second one is more damaging, because it's subtle, whereas the first is obvious to everyone involved.
Fundamentally, OKRs are a tool that should allow teams to make decisions about what to focus on, with the knowledge that they're aligned with the business objectives. If a team already has an immutable quarter+ roadmap, they're not making any decisions, they're just working; OKRs aren't a good fit for this kind of team. OKRs done well _should_ result in teams feeling empowered, because they can see the link between their actions/decisions and overall success. OKRs done poorly have the exact opposite effective; not just benign, but harmful.
> Reverse-engineering the todo list to produce OKRs
I recently saw that. In a training. By a professional, paid, external trainer.
We are supposed to take our backlog, comb it for stuff that always falls between the cracks, collect that, these are our key results. [1]
Then we are supposed to invent a headline for all that assorted stuff. That's our objective.
The whole procedure is supposed to be called "bottom-up OKR". [2]
You don't have to tell me, I have actually read Doerr's book and know better, but everyone in that training went from knowing nothing about OKRs to knowing falsehoods about OKRs.
[1] yes, he really confused tasks with measurable outcomes. And yes, that procedure ensures that the not-so-important stuff gets highest priority :-)
[2] in reality, "bottom-up" refers to the company hierarchy. Bottom-up OKRs are set by lower-tier employees.
I recently saw that. In a training. By a professional, paid, external trainer.
We are supposed to take our backlog, comb it for stuff that always falls between the cracks, collect that, these are our key results. [1]
Then we are supposed to invent a headline for all that assorted stuff. That's our objective.
The whole procedure is supposed to be called "bottom-up OKR". [2]
You don't have to tell me, I have actually read Doerr's book and know better, but everyone in that training went from knowing nothing about OKRs to knowing falsehoods about OKRs.
[1] yes, he really confused tasks with measurable outcomes. And yes, that procedure ensures that the not-so-important stuff gets highest priority :-)
[2] in reality, "bottom-up" refers to the company hierarchy. Bottom-up OKRs are set by lower-tier employees.
It's not totally insane to want bottom-up OKRs. One of the common failure modes of OKRs is that the top-down view of the management doesn't connect well to the reality of day-to-day operations. So you often end up with people engaged in Kabuki theater (making up a nice story about how the things they were going to do anyway really are the KRs for any particular stated objective).
Of course, having teams produce bottom-up OKRs has failure modes too -- it's not really strategic planning if the leaves of the org tree are setting the goals. So you need both.
A cycle of planning seems to work best -- a high-level goal is transmitted down, then each team engages in a local goal-setting process, then these goals go up, then there is coordination and refinement. But this takes forever and requires incredible discipline, so it's hard to do well.
Of course, having teams produce bottom-up OKRs has failure modes too -- it's not really strategic planning if the leaves of the org tree are setting the goals. So you need both.
A cycle of planning seems to work best -- a high-level goal is transmitted down, then each team engages in a local goal-setting process, then these goals go up, then there is coordination and refinement. But this takes forever and requires incredible discipline, so it's hard to do well.
What this trainer was apparently describing as "bottom-up OKRs" sounds like what you're describing as "Kabuki theater".
As for the top-bottom-top planning cycle, my experience has been that the "coordination and refinement" phase tends to mangle the OKRs beyond recognition. Management tends to "refine" what they were handed up by reframing it to sound like what their boss wants to hear. The concrete and achievable goals written by (or at least with the direct input of) the team get rewritten to sound more ambitious, but also more abstract, because management doesn't understand the goals as well as the team. The more layers of management you have, the more severe this effect, but it really only takes two or three to turn a solid list of team goals into a meaningless heap of synergy goo.
As for the top-bottom-top planning cycle, my experience has been that the "coordination and refinement" phase tends to mangle the OKRs beyond recognition. Management tends to "refine" what they were handed up by reframing it to sound like what their boss wants to hear. The concrete and achievable goals written by (or at least with the direct input of) the team get rewritten to sound more ambitious, but also more abstract, because management doesn't understand the goals as well as the team. The more layers of management you have, the more severe this effect, but it really only takes two or three to turn a solid list of team goals into a meaningless heap of synergy goo.
Management doesn't write the KRs for the individual teams or people. If they are, they're engaged in something, it's just not OKR planning. Objectives and key results necessarily become less precise as you move up the org structure.
> Management tends to "refine" what they were handed up by reframing it to sound like what their boss wants to hear.
Sure, that always happens...but there's no system of management that is perfect. Humans gonna human. The only thing a system can do is make us aware of the biases of the people within it.
> Management tends to "refine" what they were handed up by reframing it to sound like what their boss wants to hear.
Sure, that always happens...but there's no system of management that is perfect. Humans gonna human. The only thing a system can do is make us aware of the biases of the people within it.
Bottom-up OKRs are perfectly fine.
But since objectives are often written at the top, with key results below them, this trainer believed that this is the top-down method.
And bottom-up means defining key results and only after doing that deriving objectives from those.
That's so obviously insane that I'm not surprised you misunderstood me, I should have written that more explicitly. :-)
But since objectives are often written at the top, with key results below them, this trainer believed that this is the top-down method.
And bottom-up means defining key results and only after doing that deriving objectives from those.
That's so obviously insane that I'm not surprised you misunderstood me, I should have written that more explicitly. :-)
I actually don’t think it is too bad to reverse engineer OKRs from the backlog.
Well, maybe not completely reverse engineer.. just strongly influence whatever the OKRs are. I guess… provided whatever is in the backlog is solving the highest priority problems.
Well, maybe not completely reverse engineer.. just strongly influence whatever the OKRs are. I guess… provided whatever is in the backlog is solving the highest priority problems.
I've been through several jobs that used OKRs, and even had to read a book on it at one point, and to be completely honest I still have no idea what they are. Maybe I'm just dumb or can't grasp it, but while I know what all the words mean, I still don't understand what it is or why it's useful. I'd write some "OKRs" based on what my boss told me to write, who was told be their boss, and then I'd enter them into some HR system and never saw or heard from them again. It was all very cargo cult-y.
I never really understood how an OKR is at all applicable to an individual. Maybe our OKRs were bad but they were always related to increasing some metric or measure. I can't personally, directly affect any of that. I can do my damnedest to do good work that I think will help with that, but ultimately I have no control over whether our conversion rate goes down because some other department did something that hurt it. Yeah we did a great job on some landing page but then marketing pushed the wrong audience to it so it tanks. How does an OKR help with that? Now it looks like I haven't met any of my goals?
Maybe the problem was we always had these executive-level, vague "objectives" set by the C-suite, but then nobody knew what to actually do with that. Object: be an industry leader in innovation. What does that even mean?
I never really understood how an OKR is at all applicable to an individual. Maybe our OKRs were bad but they were always related to increasing some metric or measure. I can't personally, directly affect any of that. I can do my damnedest to do good work that I think will help with that, but ultimately I have no control over whether our conversion rate goes down because some other department did something that hurt it. Yeah we did a great job on some landing page but then marketing pushed the wrong audience to it so it tanks. How does an OKR help with that? Now it looks like I haven't met any of my goals?
Maybe the problem was we always had these executive-level, vague "objectives" set by the C-suite, but then nobody knew what to actually do with that. Object: be an industry leader in innovation. What does that even mean?
It's another corporate flavor of the "month" trying to solve a realistic problem developed by corporates themselves, in Corporatese.
In theory the idea of OKRs is fine. They are "supposed" to give individuals a form of autonomous growth which can be related to the company and has a way to be measured and traced back. It gives them the "personal responsibility", "growth" and "autonomy" which tickles a particular type of people.
In practice, there are too many conflicting viewpoints, agendas, power hierarchies, goals and more, to make them work out. That's assuming everyone works in good faith with one another, too. As others point out, nothing's keeping a manager from using OKRs against you.
Stay tuned when in 10-20 years it will silently die off to be replaced by another flavor, and reinvent the square wheel once more.
In theory the idea of OKRs is fine. They are "supposed" to give individuals a form of autonomous growth which can be related to the company and has a way to be measured and traced back. It gives them the "personal responsibility", "growth" and "autonomy" which tickles a particular type of people.
In practice, there are too many conflicting viewpoints, agendas, power hierarchies, goals and more, to make them work out. That's assuming everyone works in good faith with one another, too. As others point out, nothing's keeping a manager from using OKRs against you.
Stay tuned when in 10-20 years it will silently die off to be replaced by another flavor, and reinvent the square wheel once more.
> In theory the idea of OKRs is fine. They are "supposed" to give individuals a form of autonomous growth which can be related to the company and has a way to be measured and traced back. It gives them the "personal responsibility", "growth" and "autonomy" which tickles a particular type of people.
I still don’t even understand how that’s supposed to work unless you’re an executive with wide latitude to do what you think is best. I worked on what my manager told me to work on. All I can control is the quality of my own work. Maybe it wasn’t meant for the rank and file.
I still don’t even understand how that’s supposed to work unless you’re an executive with wide latitude to do what you think is best. I worked on what my manager told me to work on. All I can control is the quality of my own work. Maybe it wasn’t meant for the rank and file.
They're meaningless. I don't understand how these things can continue to exist and evolve in ever more ridiculous incarnations of the same stuff. If, next year, they all disappeared and managers just "cut the pie" for their own sub-org-- nothing bad would happen and the vast majority of folks would see it as a relief.
The weird thing is that almost everyone, even high up in the organization, thinks these performance eval mechanisms are a baloney waste of time. But somewhere, at some level, somebody is really pushing hard for these and values them.
Is it a suit thing? At what point in one's career does someone all of sudden decide "yeah, having everyone write paragraphs of BS justifying their work performance is a good use of time and THAT will REALLY solve problems"?
The weird thing is that almost everyone, even high up in the organization, thinks these performance eval mechanisms are a baloney waste of time. But somewhere, at some level, somebody is really pushing hard for these and values them.
Is it a suit thing? At what point in one's career does someone all of sudden decide "yeah, having everyone write paragraphs of BS justifying their work performance is a good use of time and THAT will REALLY solve problems"?
> At what point in one's career does someone all of sudden decide "yeah, having everyone write paragraphs of BS justifying their work performance is a good use of time and THAT will REALLY solve problems"?
When somebody starts making a lot of noise that people should do it, the people under you seem to unanimously support it, and the people above you seem to unanimously support it. That is, except for the very few that you can get a honest answer from, those are the only few that think it's bullshit, but put-up with it because everybody else is pushing it.
A better question is how the hell somebody getting money to teach your people and organize the process get enough credibility that they can mess with all the communication channels. Maybe an even better question is if there is any way to make people feel safer at work than in a crazy absolutist king's court, so that they have less need to lie.
When somebody starts making a lot of noise that people should do it, the people under you seem to unanimously support it, and the people above you seem to unanimously support it. That is, except for the very few that you can get a honest answer from, those are the only few that think it's bullshit, but put-up with it because everybody else is pushing it.
A better question is how the hell somebody getting money to teach your people and organize the process get enough credibility that they can mess with all the communication channels. Maybe an even better question is if there is any way to make people feel safer at work than in a crazy absolutist king's court, so that they have less need to lie.
Our corporate environments and capitalist structure in the US consolidate power in people. Once you start being an exec who can fire individuals on a whim or hand out raises/promotions they end up getting surrounded by yes men and then you start seeing the crazy ideas start flowing down.
The worse corporate jobs I’ve had have been the privately held large firms as the places are big enough you never know the executive but you still end up spending days/weeks doing ice breakers and personality assessments because the CEO’s life guru convinced him it would align the astrological feng shui.
It doesn’t do anything for the company but waste time and money, but until it wastes enough to cause the leaders to lose all power it’ll continue flowing down to us peons
The worse corporate jobs I’ve had have been the privately held large firms as the places are big enough you never know the executive but you still end up spending days/weeks doing ice breakers and personality assessments because the CEO’s life guru convinced him it would align the astrological feng shui.
It doesn’t do anything for the company but waste time and money, but until it wastes enough to cause the leaders to lose all power it’ll continue flowing down to us peons
> ice breakers
I don't understand this aspect of corporate/startup culture. Who the hell likes ice breakers in meetings? Everyone I know -- and I mean everyone -- has started joining late in an attempt to avoid ice breakers.
(I actually know who likes them: all those "life coaches" that regularly get hired by startups with too much money.)
They are infantilizing, kindergarten-like activities for adults who will never again speak to each other until the next ice breaker activity.
I don't understand this aspect of corporate/startup culture. Who the hell likes ice breakers in meetings? Everyone I know -- and I mean everyone -- has started joining late in an attempt to avoid ice breakers.
(I actually know who likes them: all those "life coaches" that regularly get hired by startups with too much money.)
They are infantilizing, kindergarten-like activities for adults who will never again speak to each other until the next ice breaker activity.
I think of "OKRs" as just a fancy name for two things:
(1) What are you going to do in the next quarter/year/etc? i.e. what are you & your team's "objectives"
(2) How are you going to achieve that? i.e. what are the "key results" you're going to hit to achieve your objective.
I hope most people will agree that, in an organization, having an understanding - and agreement - of what each team plans to work on, along with the trust that they have reasonably well-thought steps on how to achieve that objective, is incredibly helpful.
The problem is, as with "Agile", "TDD", etc, people will run with this and lose track of what the actual end-goal is, i.e. to build things that matter while ensuring coordination between teams. So, you will see things that don't make much sense, like OKRs for individual contributors, OKRs that change monthly, objectives that aren't necessarily right for the company, key results that don't really tie into the objective, etc.
I'm not sure what the solution is. At a previous gig, I tried asking management plainly to state publicly what they're going to do and how they're going to do it, and no one did it. Then I tried, let's do OKRs "just like Google" and everyone jumped on, even though IMO it's the same thing...
I hope most people will agree that, in an organization, having an understanding - and agreement - of what each team plans to work on, along with the trust that they have reasonably well-thought steps on how to achieve that objective, is incredibly helpful.
The problem is, as with "Agile", "TDD", etc, people will run with this and lose track of what the actual end-goal is, i.e. to build things that matter while ensuring coordination between teams. So, you will see things that don't make much sense, like OKRs for individual contributors, OKRs that change monthly, objectives that aren't necessarily right for the company, key results that don't really tie into the objective, etc.
I'm not sure what the solution is. At a previous gig, I tried asking management plainly to state publicly what they're going to do and how they're going to do it, and no one did it. Then I tried, let's do OKRs "just like Google" and everyone jumped on, even though IMO it's the same thing...
I was head of Engineering at exec level in different startups that grew past series B and started implementing OKRs... they never made sense to me fir the tech side. I could see sales, marketing and customer success OKRs that were aligned with their day to day tasks.
But for Engineering? I had all kind of nice reading OKRs: reduce mttr, mttf, reduce bugs, reduce feature implementation time, etc. But in reality the day-to-day work of Engineering was "build the shit that the product team defines", we had little influence in stories that went on each sprint, and invariably every time we pushed for some technical matter, business always trumped us and the stories went to the backlog.
But for Engineering? I had all kind of nice reading OKRs: reduce mttr, mttf, reduce bugs, reduce feature implementation time, etc. But in reality the day-to-day work of Engineering was "build the shit that the product team defines", we had little influence in stories that went on each sprint, and invariably every time we pushed for some technical matter, business always trumped us and the stories went to the backlog.
> But in reality the day-to-day work of Engineering was "build the shit that the product team defines", we had little influence in stories that went on each sprint, and invariably every time we pushed for some technical matter, business always trumped us and the stories went to the backlog.
This is basically what I saw. All the objectives in engineering and product orgs basically boiled down to “do you job more gooder.”
> then I'd enter them into some HR system and never saw or heard from them again
My favorite version of this is when it's personal goals attached to some kind of performance review framework, but the company keeps on changing its performance review system every 6 months so you literally never can see them again.
My favorite version of this is when it's personal goals attached to some kind of performance review framework, but the company keeps on changing its performance review system every 6 months so you literally never can see them again.
> the company keeps on changing its performance review system every 6 months so you literally never can see them again.
Yes! In my past two jobs I finally learned to never pay attention to official performance reviews and career goal plans and personal goals tracking systems: every 6 months to 1 year, like clockwork, someone important in HR gets replaced, a new tool to track goals gets bought, and everything is redesigned from scratch.
The only way to get a promotion or a pay rise is to push for it on a completely different band, nothing to do with these systems.
Yes! In my past two jobs I finally learned to never pay attention to official performance reviews and career goal plans and personal goals tracking systems: every 6 months to 1 year, like clockwork, someone important in HR gets replaced, a new tool to track goals gets bought, and everything is redesigned from scratch.
The only way to get a promotion or a pay rise is to push for it on a completely different band, nothing to do with these systems.
There are so many ways to do OKRs poorly, and I've seen many. I love the book in theory, but when I saw OKRs in practice, every company implemented this poorly.
> Let's not have objectives just yet, we are not ready to communicate our goals yet with you, let's come up with key results... More like tasks, really just Jira tickets, our team already had to commit with management for the next year, we have a release plan and everything, so there is very little wiggle room there.
> And please, don't ask about any of those goals, you are just a code monkey, and you weren't there at all the meetings, but trust us, it's the most important and impactful thing we can do...
> Anyway, What's in the next 6 sprints? Let's just put them somehow in this OKR spreadsheet. Let's hope we don't need to change anything in the next sprint...
> Hmm, alright, it looks like we have some space there, let's come up with 2-3 extra projects that realistically would need a team effort and a month focused work to complete, but you will do it on your own... Just remember that you should only work on items in the sprint, and the next 12 sprints are already planned, and we can't add your tasks to any of the sprints. You also need to convince the team that it's important, but please don't bother the team with your tasks, they will lose focus on sprint items.
> I remember the book said something about something-something measurable. Unfortunately, no matter how many analysts we hire, they all quit around 3-4 months after they join, I wonder why that is. Anyway, we don't really have "numbers", so we can't come up with metrics, and we can't measure our success in any way, and we don't know whether gigantic projects bring any improvement at all.
> Oh, and I'm pretty sure I will not be your boss, whoops, sorry, "competency lead" in three months because I'm actively interviewing to get out of here. Cheerio!
> Let's not have objectives just yet, we are not ready to communicate our goals yet with you, let's come up with key results... More like tasks, really just Jira tickets, our team already had to commit with management for the next year, we have a release plan and everything, so there is very little wiggle room there.
> And please, don't ask about any of those goals, you are just a code monkey, and you weren't there at all the meetings, but trust us, it's the most important and impactful thing we can do...
> Anyway, What's in the next 6 sprints? Let's just put them somehow in this OKR spreadsheet. Let's hope we don't need to change anything in the next sprint...
> Hmm, alright, it looks like we have some space there, let's come up with 2-3 extra projects that realistically would need a team effort and a month focused work to complete, but you will do it on your own... Just remember that you should only work on items in the sprint, and the next 12 sprints are already planned, and we can't add your tasks to any of the sprints. You also need to convince the team that it's important, but please don't bother the team with your tasks, they will lose focus on sprint items.
> I remember the book said something about something-something measurable. Unfortunately, no matter how many analysts we hire, they all quit around 3-4 months after they join, I wonder why that is. Anyway, we don't really have "numbers", so we can't come up with metrics, and we can't measure our success in any way, and we don't know whether gigantic projects bring any improvement at all.
> Oh, and I'm pretty sure I will not be your boss, whoops, sorry, "competency lead" in three months because I'm actively interviewing to get out of here. Cheerio!
Quite recently I quit a company just as they were bringing in OKRs. The reason they bought in OKRs was because they felt that the engineering organisation was failing to meet the needs of the company. So they put together a list of Objectives and key results. They basically said "This is what we have to do to be successful". There were a few small hitches. Half the Objectives were outside the scope of the engineering team. We could execute perfectly, but if our internal customer fucked up, our objective would be blown. They explained this was because it doesn't matter if we meet some technical objective if it turns out that wasn't necessary for the company to make money. The second small hitch was they were diametrically opposed objectives. We were to going to increase our release cadence 10x. We were also going to reduce production issues by 100%. That's right, our objective was 0 production issues whilst massively increasing our release cadence with 0 extra resources. The third issue is that they were unacheivable - we were supposed to deliver a 3 year project that would take 10 people in 1 year with 5 people.
It missed that the reason the engineering org failed to deliver was that the internal customer would change the requirements of 6 month projects roughly once a week.
It was basically an exercise in trying to pin blame on engineers for the failure of the company. It didn't bother me too much because I was quitting anyway.
OKRs don't fix dysfunctional organisations.
It missed that the reason the engineering org failed to deliver was that the internal customer would change the requirements of 6 month projects roughly once a week.
It was basically an exercise in trying to pin blame on engineers for the failure of the company. It didn't bother me too much because I was quitting anyway.
OKRs don't fix dysfunctional organisations.
Having measures of success that are opposites of each other actually makes sense (as explained also in the High Output Management). That way you ensure you won't go too much into increasing release cadence at the cost of introducing too many bugs and vice versa.
For the purposes of quantifying this we weighted one of those worth 95%.
> OKRs don't fix dysfunctional organisations.
Very true.
However -- note that the process of implementing OKRs has caused the leadership team to write down their expectations, which previously might have been unspoken. This is a first step towards resolving the problem. The next step is for the CTO to push back, hard, on the bits of these that aren't actually realistic, and hopefully get the leadership team aligned on what can actually be done. And so, the process of OKRs potentially has value here in flushing out unrealistic or mismatched expectations between different parts of the org.
This is one of those rare "my way or the high way" moments in leadership; as CTO at this company it's your job to either get the leadership team to realize that they are asking you for more than you can be expected to deliver, or quit. You can't stick around and put your name on a plan that you know is impossible; otherwise you're going to be the one that failed for every quarter to come. And even worse, you can't sign your team up for this BS. It's your job to shield them from this kind of shit.
> Half the Objectives were outside the scope of the engineering team.
Shared OKRs are difficult, but sometimes they are unavoidable. The most difficult business problems usually are cross-functional. At their best, OKRs can help to make these cross-functional dependencies more explicit, and foster communication and collaboration around them.
If they are trying to have engineering take full ownership of a shared OKR, that's a big problem. But if you clearly call out the shared ownership, and consider both parties responsible for implementation, then I think that's OK.
> We were to going to increase our release cadence 10x. We were also going to reduce production issues by 100%. That's right, our objective was 0 production issues whilst massively increasing our release cadence with 0 extra resources.
As a tangential point, increasing release cadence can definitely decrease your long-term rate of issues (see "Continuous Delivery" by Humble[1]) -- this forces you to automate manual processes, and manual processes are one of the main places that errors creep in. Though I think "count of issues" is a very poor metric, you're better off with an uptime metric. And "100%" is the only strictly-incorrect number to pick for uptime, because it is literally impossible; my (super-unscientific, don't hold me to this) rule of thumb for business people is "every extra 9 costs you 10x". So do you need 99.9% uptime or 99.99%?
[1]: https://www.amazon.com/Continuous-Delivery-Deployment-Automa...
Very true.
However -- note that the process of implementing OKRs has caused the leadership team to write down their expectations, which previously might have been unspoken. This is a first step towards resolving the problem. The next step is for the CTO to push back, hard, on the bits of these that aren't actually realistic, and hopefully get the leadership team aligned on what can actually be done. And so, the process of OKRs potentially has value here in flushing out unrealistic or mismatched expectations between different parts of the org.
This is one of those rare "my way or the high way" moments in leadership; as CTO at this company it's your job to either get the leadership team to realize that they are asking you for more than you can be expected to deliver, or quit. You can't stick around and put your name on a plan that you know is impossible; otherwise you're going to be the one that failed for every quarter to come. And even worse, you can't sign your team up for this BS. It's your job to shield them from this kind of shit.
> Half the Objectives were outside the scope of the engineering team.
Shared OKRs are difficult, but sometimes they are unavoidable. The most difficult business problems usually are cross-functional. At their best, OKRs can help to make these cross-functional dependencies more explicit, and foster communication and collaboration around them.
If they are trying to have engineering take full ownership of a shared OKR, that's a big problem. But if you clearly call out the shared ownership, and consider both parties responsible for implementation, then I think that's OK.
> We were to going to increase our release cadence 10x. We were also going to reduce production issues by 100%. That's right, our objective was 0 production issues whilst massively increasing our release cadence with 0 extra resources.
As a tangential point, increasing release cadence can definitely decrease your long-term rate of issues (see "Continuous Delivery" by Humble[1]) -- this forces you to automate manual processes, and manual processes are one of the main places that errors creep in. Though I think "count of issues" is a very poor metric, you're better off with an uptime metric. And "100%" is the only strictly-incorrect number to pick for uptime, because it is literally impossible; my (super-unscientific, don't hold me to this) rule of thumb for business people is "every extra 9 costs you 10x". So do you need 99.9% uptime or 99.99%?
[1]: https://www.amazon.com/Continuous-Delivery-Deployment-Automa...
I’m glad you mentioned this, yes the CTO quit 6 months later.
"We're introducing OKRs, they're for your benefit so you know where to focus and can track how you're improving and the team success, they wont be used to judge your salary"
6 months later
"So yeah that's the most we're gonna offer you for this raise because your OKR score was only..."
Every time.
6 months later
"So yeah that's the most we're gonna offer you for this raise because your OKR score was only..."
Every time.
My experiences have tended more toward "everybody stresses out about OKRs for a couple weeks every quarter and then you might as well have deleted the file because nobody will ever, ever, ever talk about them again".
Yeah. Objective: Pay rise. Key Result: Pay. Strategy; Apply.
80% of the value of OKRs is in the discussions they create, not in the actual list of OKRs that is produced in the process. The more an organization focuses on the technical aspects of producing a perfect OKR list or on "grading" the OKRs, the less value they will have.
In particular, the "KR" part - quantifiable outcomes for the goals - usually helps in clarifying vague projects or ideas that may otherwise harm the team's focus.
It's similar to the famous Warren Buffett's advice on identifying your priorities: pick 20 ideas you have and identify the top 5 goals that you absolutely want to get done; then, throw away the other 15 goals and make sure that you never get tempted to work on them.
In particular, the "KR" part - quantifiable outcomes for the goals - usually helps in clarifying vague projects or ideas that may otherwise harm the team's focus.
It's similar to the famous Warren Buffett's advice on identifying your priorities: pick 20 ideas you have and identify the top 5 goals that you absolutely want to get done; then, throw away the other 15 goals and make sure that you never get tempted to work on them.
Yeah, I agree with this. It's like writing a summary study sheet before an exam...the actual sheet is not that useful, but the work that went into it is. I've found OKRs to be pretty good for clarifying focus areas, both in my org and for personal development. Both the Os and the KRs will frequently change, but good managers/orgs don't really care about granular tracking
The main problem I've seen with OKRs in a technical setting is that they haven't accounted for steady state support, or sudden urgent issues.
Both of those make up important work that has to be done in a timeframe shorter than the OKR reporting period.
As a result important work goes untracked, and completeness of KRs are affected since people had to focus on "unexpected" issues instead.
A compounding effect is burnout because a persons OKR workload and review process doesn't accurately reflect the day-to-day work that they did. Heroics are needed to avoid people higher up the management ladder seeing unfinished work under your name.
Both of those make up important work that has to be done in a timeframe shorter than the OKR reporting period.
As a result important work goes untracked, and completeness of KRs are affected since people had to focus on "unexpected" issues instead.
A compounding effect is burnout because a persons OKR workload and review process doesn't accurately reflect the day-to-day work that they did. Heroics are needed to avoid people higher up the management ladder seeing unfinished work under your name.
I’ve seen this too. Unless upper management fully understands and supports the fact there is day to day “keep the lights on” work… a lot of what your team does won’t get credit. It takes a lot of work to drill into everybody’s heads that OKRs aren’t an exhaustive list of what a team is working on.
Me irl :( Every time I'm sent the quarterly email demanding my OKRs I just copy over the couple of single line items like "Support X" and "Maintain Y". I'm sure there's someone I've never met wearing a suit and thinking I'm worthless as a result.
My issue with OKRs is trying to apply them to employees who have no power to make business decisions.
OKRs are supposed to be liberating. In theory the management owns the prioritization of problems to be worked on. The team owns the actual way the problem is solved. Done right, OKRs help drive team level innovation.
Of course there are plenty of ways to fuck up OKRs…
Of course there are plenty of ways to fuck up OKRs…
[deleted]
100%! I have to set goals at the beginning of the year but so far every time priorities changed and the goals became deprioritized or obsolete quickly. And at the end of the year I have to map my achievements into categories like "increase market share" or "fuel international growth". My work is so far away from these things that it makes no sense at all.
I can see this working for VP and higher who have a multi year perspective and can changes things as needed, but for lower ranks it makes no sense.
The only realistic goal for my work is "Keep the f...ing system running and enhance as needed"
I can see this working for VP and higher who have a multi year perspective and can changes things as needed, but for lower ranks it makes no sense.
The only realistic goal for my work is "Keep the f...ing system running and enhance as needed"
I’ve said for years that OKRs can make some sense at higher levels of the org because it’s an easy way to communicate strategy but it makes no sense for individual engineers to use them. I think your comment explains why. At some point the people writing the OKRs no longer have the authority or autonomy to actually achieve them. So what’s the point?
How about a twister of key results that depends on teams with their own OKRs? It's enough to try to keep my team moving forward sometimes, but I won't put down on paper something I have no control over and be accountable to it.
Or worse, doing a little farce where they supposedly "choose their own".
I've only done them at one place over 1 year but they're easily among the worst things to come out of the Silicon Valley cargo-cult school of management.
The root problem is that what works for the front-page of the internet who have a firehose of money and millions of users probably doesn't work for a pre-PMF start-up or B2B product. Primarily there's insufficient 'pressure' in any metrics to derive any meaningful signal from any changes a small group of developers can make. Any metric you can derive is way too noisy and spread over sales, marketing and development.
Sure, Gmail can change the location of the Compose button and measure the change in emails started with high reliability, but when your feature has at most 5 users and takes 2 months to deliver the impact is far less clear.
I felt in the company using OKRs we had one C-level person who was incredibly enthusiastic about them but with only 10 developers we'd have been far better served by a unifying vision and shared product understanding.
The root problem is that what works for the front-page of the internet who have a firehose of money and millions of users probably doesn't work for a pre-PMF start-up or B2B product. Primarily there's insufficient 'pressure' in any metrics to derive any meaningful signal from any changes a small group of developers can make. Any metric you can derive is way too noisy and spread over sales, marketing and development.
Sure, Gmail can change the location of the Compose button and measure the change in emails started with high reliability, but when your feature has at most 5 users and takes 2 months to deliver the impact is far less clear.
I felt in the company using OKRs we had one C-level person who was incredibly enthusiastic about them but with only 10 developers we'd have been far better served by a unifying vision and shared product understanding.
[deleted]
My biggest issue with OKRs comes from those who practice what could be called "Aimless Key Results".
Instead of thinking about an intuitive objective and then try to come up with some form of measurable Key Result that can help assess whether the org is getting closer to—or further from—the objective, some skip the whole Objective part altogether. They become so stressed with having something measurable that they end up with KRs based on how easy they are to measure, regardless if they actually correlate to a supposed objective.
This is Goodhart's Law[1] on steroids.
Healthy OKRs do exist but they have a few preconditions:
- the individuals devising them must fully internalize which are the objectives that do matter for the org, among an ocean of "priorities".
- the KRs must be carefully thought out and evaluated against their vulnerability to the law of unintended consequences.
- the team(s) implementing the KRs must understand why theses KRs exist, their relationship to the Objective they serve, and how well (or not) they measure the objective.
- the leaders must be quick to change the KRs if there's any doubt as to whether they are actually helping, or causing more damage. The "why" should remain relatively constant over time, the "how" can change.
- KRs that have thresholds should always be ambitious and very hard to actually meet, as they stretch the organization's goals.
- Tying perforance bonuses to them is dangerous because it immediately results in gamification: Damn the Objective, I want my bonus!
OKRs can be incredibly tricky for middle management because the top leadership may have a decent objective to be pursued, and the line managers may have a good grasp on what success looks like. But the middle part is caught in between the 2, and this can create all sorts of fun artifacts of measurement, aka. dysfunctions. Especially if that middle management layer doesn't have a rock solid understanding of the actual objectives and are only obsessed with the measuring part.
[1] When a measure becomes a target, it ceases to be a good measure. — https://en.wikipedia.org/wiki/Goodhart%27s_law#cite_note-Str...
Instead of thinking about an intuitive objective and then try to come up with some form of measurable Key Result that can help assess whether the org is getting closer to—or further from—the objective, some skip the whole Objective part altogether. They become so stressed with having something measurable that they end up with KRs based on how easy they are to measure, regardless if they actually correlate to a supposed objective.
This is Goodhart's Law[1] on steroids.
Healthy OKRs do exist but they have a few preconditions:
- the individuals devising them must fully internalize which are the objectives that do matter for the org, among an ocean of "priorities".
- the KRs must be carefully thought out and evaluated against their vulnerability to the law of unintended consequences.
- the team(s) implementing the KRs must understand why theses KRs exist, their relationship to the Objective they serve, and how well (or not) they measure the objective.
- the leaders must be quick to change the KRs if there's any doubt as to whether they are actually helping, or causing more damage. The "why" should remain relatively constant over time, the "how" can change.
- KRs that have thresholds should always be ambitious and very hard to actually meet, as they stretch the organization's goals.
- Tying perforance bonuses to them is dangerous because it immediately results in gamification: Damn the Objective, I want my bonus!
OKRs can be incredibly tricky for middle management because the top leadership may have a decent objective to be pursued, and the line managers may have a good grasp on what success looks like. But the middle part is caught in between the 2, and this can create all sorts of fun artifacts of measurement, aka. dysfunctions. Especially if that middle management layer doesn't have a rock solid understanding of the actual objectives and are only obsessed with the measuring part.
[1] When a measure becomes a target, it ceases to be a good measure. — https://en.wikipedia.org/wiki/Goodhart%27s_law#cite_note-Str...
I have a slightly different take.
I think there's a tendency to attach too much importance to the key results; though I very much agree with your point about the law of unintended consequences, this is why the concept of anchoring metrics/KRs comes up a lot.
To me, the Objective is what you want, whilst the KRs are just a set of heuristics that tell you if the work you're doing is taking you in that direction. But I see it as a classic "the map is not the territory" thing. Too much emphasis on the KRs (like, as you say, tying bonuses to them) can lead to gaming the system and other failure states.
I think there's a tendency to attach too much importance to the key results; though I very much agree with your point about the law of unintended consequences, this is why the concept of anchoring metrics/KRs comes up a lot.
To me, the Objective is what you want, whilst the KRs are just a set of heuristics that tell you if the work you're doing is taking you in that direction. But I see it as a classic "the map is not the territory" thing. Too much emphasis on the KRs (like, as you say, tying bonuses to them) can lead to gaming the system and other failure states.
I think the only time I've seen OKRs work correctly is when they were super specific, singular, and very short term. The team I've seen use them generally picks something that aligns closely with something leadership wants to see progress on, that isn't a multi-year project, and is easy to measure directly.
An example: Q1's goal was around tagging of AWS resources for billing. Our CBO came down with some new practices and automation around tagging and was having trouble getting traction in our BU with getting those tags in place for existing projects.
The work was tedious, but not difficult. Progress is directly measurable (X of Y resources in Z account are tagged correctly) and the measuring is easily automated into a dashboard. It has a massive benefit for automating Change Management and Billing/Budgeting bureaucracy.
I think OKRs have a place but I also think you just can't centralize them the way various big companies do. Even the "bottom-up" version just doesn't work because by the time the OKRs hit the C-Suite they're just mangled and incomprehensible. The OKR in my example never "escaped" past middle management. All the C-Suite knew was the CBO stopped whining about people not tagging their stuff.
An example: Q1's goal was around tagging of AWS resources for billing. Our CBO came down with some new practices and automation around tagging and was having trouble getting traction in our BU with getting those tags in place for existing projects.
The work was tedious, but not difficult. Progress is directly measurable (X of Y resources in Z account are tagged correctly) and the measuring is easily automated into a dashboard. It has a massive benefit for automating Change Management and Billing/Budgeting bureaucracy.
I think OKRs have a place but I also think you just can't centralize them the way various big companies do. Even the "bottom-up" version just doesn't work because by the time the OKRs hit the C-Suite they're just mangled and incomprehensible. The OKR in my example never "escaped" past middle management. All the C-Suite knew was the CBO stopped whining about people not tagging their stuff.
I couldn't agree more here -- one of the biggest challenges I've faced (only rolling out OKRs to a ~50 person company, with just two layers, so nothing like Google-scale) was figuring out how to keep the different layers legible. I found the lower layer (team-facing) to be extremely useful, and the CEO-facing layer to be much more difficult.
The dream is that you can imbue each employee with a "chain of objectives" that gives their work more purpose and clarity; I read an article on SpaceX that gave a rocket engineer saying something like "SpaceX's mission is to colonize Mars. In order to do that, one requirement is to build reusable rockets. My job is to build <rocket component X> in such a way as to enable cost-effective reusability." Perhaps that was a PR stunt but you can see how an employee with broader business context will be much more effective at making tactical adjustments within their domain of responsibility.
In theory it should be possible to make some software to manage OKRs better than a spreadsheet; I looked at https://gtmhub.com/ ages ago and didn't find it too useful. Maybe there is a good option now.
The dream is that you can imbue each employee with a "chain of objectives" that gives their work more purpose and clarity; I read an article on SpaceX that gave a rocket engineer saying something like "SpaceX's mission is to colonize Mars. In order to do that, one requirement is to build reusable rockets. My job is to build <rocket component X> in such a way as to enable cost-effective reusability." Perhaps that was a PR stunt but you can see how an employee with broader business context will be much more effective at making tactical adjustments within their domain of responsibility.
In theory it should be possible to make some software to manage OKRs better than a spreadsheet; I looked at https://gtmhub.com/ ages ago and didn't find it too useful. Maybe there is a good option now.
Whenever I see a website making the SIGN UP button bold and big but SIGN IN small and faded I am reminded how toxic OKRs are and how it end up hurting the user and eventually the business.
Making people mistakingly create new accounts indeed helps you hit your # of sign ups goal but at what cost?
Making people mistakingly create new accounts indeed helps you hit your # of sign ups goal but at what cost?
I've seen OKRs significantly improve teams when there's full staff bottom-up commitment; I've seen OKRs totally fail when they're drive-by top-down directives.
I maintain a repo of OKR guidance here:
https://github.com/joelparkerhenderson/objectives-and-key-re...
I maintain a repo of OKR guidance here:
https://github.com/joelparkerhenderson/objectives-and-key-re...
I read about OKRs briefly and worked at 2 companies that tried* to do it. Unfortunately, at both companies, management announced it to everyone, but I practically never heard anything after those announcements.
I would like to boil OKRs down to a combination of 2 things: "goals + habits". Pick good goals, and design your days/behaviours/habits to get to that goal. Goals, habits, objectives, key results would all benefit from being measurable, clear, simple, etc.
I would like to boil OKRs down to a combination of 2 things: "goals + habits". Pick good goals, and design your days/behaviours/habits to get to that goal. Goals, habits, objectives, key results would all benefit from being measurable, clear, simple, etc.
The biggest issue I've seen with OKRs is that it just turns into a game, and then proceeds to get "gamed".
Separately, there has been more than one occasion where we chose to work on something OKR related but ended up providing less value to our end user as requirements changed mid quarter. Therefore making our initial OKR irrelevant, and preventing management from wanting to pivot to solve a real customer need.
OKR shouldn't look like a set of sprint tasks, they are supposed to mirror what results matters to your team. If your team is supposed to solve the needs of a specific customer then your OKR should be something akin to "implement features to solve customer X needs and keep them happy" and not list those features explicitly since what you build doesn't matter, all that matters is whether the customer is happy so that is the key result. Alternatively the team can be focused on developing new generic features or products to be sold to many, in those cases you can list the products explicitly since then the key result your team is delivering is that product to sell instead of keeping a specific user happy.
In a sufficiently complex system with a big enough hierarchy, personal OKRs become quite far from the end product due to necessity.
If the product objective is to grow an app to 100m users, the objective of a backend distributed systems team would be to scale the system to handle the load.
If front end requirements change, for example the app needs to serve videos instead of images, entire OKRs of the backend team might need to be rewritten. If requirements change often enough the backend team OKRs just become meaningless. If they follow your model, the backend team objective would be to just "help the product scale", and the personal OKRs would be just to "help the team scale the backend and make my EM happy" because there's no way to really plan for what the product team wants next. That may well be the only thing that can be done, but it's a degeneration to a system that offers no clear accountability, and just points to the futility of sticking to the OKR model in a large organization that needs to move fast.
If the product objective is to grow an app to 100m users, the objective of a backend distributed systems team would be to scale the system to handle the load.
If front end requirements change, for example the app needs to serve videos instead of images, entire OKRs of the backend team might need to be rewritten. If requirements change often enough the backend team OKRs just become meaningless. If they follow your model, the backend team objective would be to just "help the product scale", and the personal OKRs would be just to "help the team scale the backend and make my EM happy" because there's no way to really plan for what the product team wants next. That may well be the only thing that can be done, but it's a degeneration to a system that offers no clear accountability, and just points to the futility of sticking to the OKR model in a large organization that needs to move fast.
The scenarios described here are familiar even though I've only spent a small part of my career doing formal OKRs. If your next blog post continues to mirror my experience, it will paint a picture of a quarterly OKR debrief meeting where half the people didn't work on their objectives and it just doesn't matter because they got good work done anyway. People who really like process and checklists will nail their OKRs, but they probably would have gotten the same work done in the quarter regardless so, again, it doesn't matter.
Upon reflection, it makes me wonder if OKRs are better used as a corrective tool for a team than as a formal process for already high performing teams.
Upon reflection, it makes me wonder if OKRs are better used as a corrective tool for a team than as a formal process for already high performing teams.
I don't disagree with any of this, but really these are problems with every goal-setting framework I have experienced in my career. Similar to performance review frameworks. It isn't the framework that sucks; it is the exercise itself. I've become convinced that at a certain scale, it is impossible for a corporation to have a company-wide goal process or performance review process that adds more value than it detracts. I don't know what the solution is, but I really don't think it's just "find a better process."
> I don't know what the solution is
I do, but they're not going to like it, so they're not going to do it. The mindset behind these goal-setting frameworks is "everybody is stealing from me and I have to watch them like a mafia boss to catch the cheaters". The solution is to actually treat the team as a team and work together, but the type of people who rise to a management role in any organization (especially a corporation) aren't the type of people who are capable of doing so.
I do, but they're not going to like it, so they're not going to do it. The mindset behind these goal-setting frameworks is "everybody is stealing from me and I have to watch them like a mafia boss to catch the cheaters". The solution is to actually treat the team as a team and work together, but the type of people who rise to a management role in any organization (especially a corporation) aren't the type of people who are capable of doing so.
OKR's without strategy or context (or OKR's substituting for a strategy or context) is a killer I've seen. Especially if I'm "laddering up" my product's OKRs.
This is where the bi-directional approach does work better than strictly top-down or bottom-up; my leadership probably doesn't see the opportunities or constraints for my product, but for my opportunities to be attainable, I need to be swimming the same direction as my organization. Strategy gives me context for where I should be playing.
This is where the bi-directional approach does work better than strictly top-down or bottom-up; my leadership probably doesn't see the opportunities or constraints for my product, but for my opportunities to be attainable, I need to be swimming the same direction as my organization. Strategy gives me context for where I should be playing.
I want to compare OKRs to Performance Reviews and Roadmapping. They’re all worthwhile ideas that can bring discipline and structure to the chaotic world of business, all dreaded by their participants for some reason.
It's not mysterious, why those things are hated.
In business, there are innate conflicts of interest. The company wants to suck as much out of people, and pay as little, as it can. You want... something else. Not to be exploited. To have a career. To make more money. Doesn't matter. The company is a paperclip maximizer and you are made of atoms it can use for something else. When you write OKRs, you have to generate information that will only be used against you--never for you. You have to pretend that you're doing this out of some sense of mutuality when, in fact, the situation is inherently adversarial.
You might have a decent manager. Great. That happens sometimes. However, all these devices exist as ways for companies to make managers unable to protect their own people. That's why "Agile" time-tracking exists. That's why there are two management structures (product and people management) for reptilian executives to pit against each other. That's why performance reviews with failure quotas exist. For your boss to be able to protect you from the company is the last thing the company wants.
It's not mysterious, why those things are hated.
In business, there are innate conflicts of interest. The company wants to suck as much out of people, and pay as little, as it can. You want... something else. Not to be exploited. To have a career. To make more money. Doesn't matter. The company is a paperclip maximizer and you are made of atoms it can use for something else. When you write OKRs, you have to generate information that will only be used against you--never for you. You have to pretend that you're doing this out of some sense of mutuality when, in fact, the situation is inherently adversarial.
You might have a decent manager. Great. That happens sometimes. However, all these devices exist as ways for companies to make managers unable to protect their own people. That's why "Agile" time-tracking exists. That's why there are two management structures (product and people management) for reptilian executives to pit against each other. That's why performance reviews with failure quotas exist. For your boss to be able to protect you from the company is the last thing the company wants.
This is why I prefer to work in startups. The objectives are more paying customers, more retention, and (for later stage companies) at a lower cost. If you're not doing something that moves the needle on those things in a startup, you're working on the wrong thing.
I've only been at one place that had OKR's. That was my shortest job due to the toxic work environment. OKR's are simple enablers of toxic environments due to the amount of goal post moving and gaslighting.
"Here is an arbitrary goal """you""" agreed to, why has it not been achieved?"
"Well, you didn't really give me a choice and you also moved me to another project or the project was killed off"
"not good enough"
Yeah, I'll pass anywhere that encourages this.
"Here is an arbitrary goal """you""" agreed to, why has it not been achieved?"
"Well, you didn't really give me a choice and you also moved me to another project or the project was killed off"
"not good enough"
Yeah, I'll pass anywhere that encourages this.
[deleted]
/s
The best thing about OKRs
People: It helps companies dump as many people/contractors as it can afford into a pod. Result: It supports this[0] kind of development process
That said, there will always be one or two genuine workaholics in every pod who write enough code to show something tangible. That helps keep the OKR/Agile business go on forever.
0: https://imgur.com/a/IeKjsff
The best thing about OKRs
People: It helps companies dump as many people/contractors as it can afford into a pod. Result: It supports this[0] kind of development process
That said, there will always be one or two genuine workaholics in every pod who write enough code to show something tangible. That helps keep the OKR/Agile business go on forever.
0: https://imgur.com/a/IeKjsff
So, in conclusion:
1-okrs should not be used to evaluate staff or be scored for pay raise decision. Oops, seems like some people still do that.
2-individuals should not be defining okrs at their level. I don’t see many people doing this anymore… even Google came out and advised against this practice as it leads to a lack of collaboration. And okrs end up looking like personal goals such as “buy house in Mountain View”
3-okrs should not be a to-do list, but looks like many, if not most, teams who think they are doing “okrs” simply make a to-do list and call it “okrs” which is ironic since okrs are about outcomes not output.
4-Okrs work best when leadership stops saying just “be innovative” and instead says “successfully expand the ecosystem of product ABC” Then describes why that objective is important and why now to educate and motivate the company. And then gets input to solicit how we will agree on what measurable progress will define the achievement of the objective so we all know what the goals are for the short term. But okrs do not work when krs look like “reduce the backlog” or “fix bugs” as those are not actually “krs” they are “to-do lists”
5- last point, and most importantly… okrs is a “verb”, a way of asking questions. You are doing okrs when you are asking yourself and others include the following questions:
A-what is the most important area to focus on making progress in near term? Why? B-how will measure progress on the objective? C-what is the intended outcome of the task (because people will answer question B with a task list)
If you ask these questions of yourself and others, good things happen. If you use okrs to make a to-do list or evaluate performance of staff, you will end up complaining that okrs don’t work. Your choice.
2-individuals should not be defining okrs at their level. I don’t see many people doing this anymore… even Google came out and advised against this practice as it leads to a lack of collaboration. And okrs end up looking like personal goals such as “buy house in Mountain View”
3-okrs should not be a to-do list, but looks like many, if not most, teams who think they are doing “okrs” simply make a to-do list and call it “okrs” which is ironic since okrs are about outcomes not output.
4-Okrs work best when leadership stops saying just “be innovative” and instead says “successfully expand the ecosystem of product ABC” Then describes why that objective is important and why now to educate and motivate the company. And then gets input to solicit how we will agree on what measurable progress will define the achievement of the objective so we all know what the goals are for the short term. But okrs do not work when krs look like “reduce the backlog” or “fix bugs” as those are not actually “krs” they are “to-do lists”
5- last point, and most importantly… okrs is a “verb”, a way of asking questions. You are doing okrs when you are asking yourself and others include the following questions:
A-what is the most important area to focus on making progress in near term? Why? B-how will measure progress on the objective? C-what is the intended outcome of the task (because people will answer question B with a task list)
If you ask these questions of yourself and others, good things happen. If you use okrs to make a to-do list or evaluate performance of staff, you will end up complaining that okrs don’t work. Your choice.
Never seen OKRs be anything but a disaster. Probably never will see anything else.
OKRs are New Year resolutions: "this year I'm try to stop drinking" or, if you want to sound more realistic, but still ambitions, then reword it to "this year I'll get less than 2 DUIs."
OKRs just seem like another attempt in a long line of failed attempts to make development costs more predictable. I applaud the effort, but at any company I've worked, they've always turned into a stick used to beat on the underlings. I think I get how they could work in an ideal scenario, but the implementation of them has always failed, because the adopted process doesn't allow them to shift even as things arise outside your control, because they got tied to raises/bonuses in unfair ways, etc.
My only "successful" encounter with OKRs was at a company that really bought into them hard, and so over the course of about half a year I got the teams in my group to slowly get ahead of the curve, such that 90+% of every next-quarter OKR items were things we were done with already, so that we could spend pretty much the whole quarter dealing with fires or secretly getting new stuff done for the next-next quarter.
My only "successful" encounter with OKRs was at a company that really bought into them hard, and so over the course of about half a year I got the teams in my group to slowly get ahead of the curve, such that 90+% of every next-quarter OKR items were things we were done with already, so that we could spend pretty much the whole quarter dealing with fires or secretly getting new stuff done for the next-next quarter.
I can't be the only one who thinks the primary goal of OKRs is to keep non-technical managers employed, right?
No, that's not the only goal - it's also there to create a paper trail to safely fire technical people who non-technical managers don't personally like.
I remember when one member of my team put in an OKR for "learn to play the guitar" and mapped it into a training objective from above. It got approved, no questions asked. I was sort of disappointed management didn't follow up and ask him to perform for us all at the end of the quarter.
"I was sort of disappointed management didn't follow up and ask him to perform for us all at the end of the quarter."
that would have been pretty cool and given me lots of respect for management.
that would have been pretty cool and given me lots of respect for management.
Probably the best OKR i have heard. At least it is good for morale!
The problem with OKRs is that they force you to set goals without doing anything to guide you about how to actually achieve those goals, or even to improve your odds. The industry fetish for OKRs is entirely due to survivorship bias. A few successful companies do OKRs and so now everyone does OKRs because no one stops to think about whether the success stories are because of OKRs or despite them. As an early Googler I can tell you from my firsthand experience that it was "despite" not "because".
In fact, now that I reflect on it, the real function of OKRs is to get you to put in more hours, because either you haven't met your KRs yet and you need to keep working, or you have met them, and so you didn't set the bar high enough.
In fact, now that I reflect on it, the real function of OKRs is to get you to put in more hours, because either you haven't met your KRs yet and you need to keep working, or you have met them, and so you didn't set the bar high enough.
My current employer use OKRs to align the different levels of the org and to help each team structure their work. We use an approach that is mostly owned on the lowest level; company leadership set long and medium term objectives for the company, area/department heads set goals for each 4-month period, and each team gets to work out their own OKRs for the next period. The team objectives do not not need to match area objectives 1-to-1; area objectives are mostly guiding.
I started rather recently, and I'm in my second OKR-period currently. This has been my first experience with OKR, and so far it's been on the strong side of positive; we get some guiding principles to work towards (but nothing too concrete or checkbox-final) and it works well. Sure, we won't be able to solve everything we write down, but our team is aligned on our own direction and a course that we control ourselves , to a large degree, but still within the overall goals of the company.
In my experience, software engineering is about 20% creating the solution, 15% tuning and debugging the solution and 65% understanding the problem.
Within this perspective, the work of talking through the problems that your team is working to solve, and contextualizing why you're solving them, is highly valuable and counts towards understanding the problem. The process of defining OKRs, within the correct frame of reference and expectations, can work very well for this.
IMO, using the backlog to define upcoming work can enrich this process as well; it brings context, but should not becone the final OKR "product" alone.
I've only ever encountered OKRs on a team level, but I cannot grasp the value they bring as individual goals. The real value in OKRs lies in the process leading up to defining them, not the objectives and results themselves.
A recurring theme in the horror stories I've read regarding corporate strategies is that they tend to be implemented with a goal of rigidity rather than fluidity. And making rigid processes that aren't compatible with team autonomy brings with helplessness and alienation between the goal-setters and those working to deliver.
I started rather recently, and I'm in my second OKR-period currently. This has been my first experience with OKR, and so far it's been on the strong side of positive; we get some guiding principles to work towards (but nothing too concrete or checkbox-final) and it works well. Sure, we won't be able to solve everything we write down, but our team is aligned on our own direction and a course that we control ourselves , to a large degree, but still within the overall goals of the company.
In my experience, software engineering is about 20% creating the solution, 15% tuning and debugging the solution and 65% understanding the problem.
Within this perspective, the work of talking through the problems that your team is working to solve, and contextualizing why you're solving them, is highly valuable and counts towards understanding the problem. The process of defining OKRs, within the correct frame of reference and expectations, can work very well for this.
IMO, using the backlog to define upcoming work can enrich this process as well; it brings context, but should not becone the final OKR "product" alone.
I've only ever encountered OKRs on a team level, but I cannot grasp the value they bring as individual goals. The real value in OKRs lies in the process leading up to defining them, not the objectives and results themselves.
A recurring theme in the horror stories I've read regarding corporate strategies is that they tend to be implemented with a goal of rigidity rather than fluidity. And making rigid processes that aren't compatible with team autonomy brings with helplessness and alienation between the goal-setters and those working to deliver.
> The real value in OKRs lies in the process leading up to defining them, not the objectives and results themselves.
I couldn't agree more, and the article is headed in completely the wrong direction.
Companies fail at using OKRs when they are rigid about treating OKRs as a measure of successfulness of the team. In my experience, the true goals almost always become clearer as the quarter progresses, and hitting the OKR objectives you set months ago is a sign that your team is not flexible enough to solve the real problems. Oversimplifying your work into key results also hides the true status. It overemphasizes measurable, but meaningless, metrics over truly checking the work for quality.
I couldn't agree more, and the article is headed in completely the wrong direction.
Companies fail at using OKRs when they are rigid about treating OKRs as a measure of successfulness of the team. In my experience, the true goals almost always become clearer as the quarter progresses, and hitting the OKR objectives you set months ago is a sign that your team is not flexible enough to solve the real problems. Oversimplifying your work into key results also hides the true status. It overemphasizes measurable, but meaningless, metrics over truly checking the work for quality.
Quiet shocked by the negative comments regarding OKR. As a Product Manager I constantly have to tell the story to management after what I go. Whats the goal…
And so the Objective is usefull. Example: Increase usage - so I look for weekly active users increase by x.
If I now set that as part of my salary target etc is a different question, I am not a fan off. But having a direction and looking ar various is a good solution.
As always if OKR don’t help you, don’t do them. But still better to try to measure and improve to get a better outcome, than to blindly follow the CEO or other brainfarts…
If I now set that as part of my salary target etc is a different question, I am not a fan off. But having a direction and looking ar various is a good solution.
As always if OKR don’t help you, don’t do them. But still better to try to measure and improve to get a better outcome, than to blindly follow the CEO or other brainfarts…
As the resident 'fire-put-outer' engineer on my team whose priorities appear and vaporize every week or two, how do I quantify that work into quarterly OKR(s)?
OKR are about the reason you get paid. The main reason they pay you seems to be to put out fires, so something like "Put out fires before things go bad" should be your OKR. If you did a good job putting out fires you get a high score.
So many here say "OKR doesn't match what I really need to do", the answer is then always "then write down what you really need to do/focus on as your OKR". If your manager complains ask him "would you rather I work on this project instead of fixing a fire when a situation happens?", if he says yes then you should stop fixing those fires it isn't your job, if he says no then he should be fine with it being a part of your OKR's.
So many here say "OKR doesn't match what I really need to do", the answer is then always "then write down what you really need to do/focus on as your OKR". If your manager complains ask him "would you rather I work on this project instead of fixing a fire when a situation happens?", if he says yes then you should stop fixing those fires it isn't your job, if he says no then he should be fine with it being a part of your OKR's.
Since OKRs are becoming so commonplace, what are some good strategies for playing the game sufficiently well enough to stay under the radar without a lot of time investment into it?
Make sure your manager likes you.
OKRs have become, like peer reviews, just one of those "corporate" things that you have to do, but that nobody really cares.
My performance/bonus/promotions were never affected positive/negative, in any way by my OKR.
Frequent re-org and change of direction very often invalidate any OKR one might even have tried to achieve.
I wish companies realize that OKR, like working from the office, are things of the past that no longer fit in the world we live in, where things move at an incredible fast pace.
My performance/bonus/promotions were never affected positive/negative, in any way by my OKR.
Frequent re-org and change of direction very often invalidate any OKR one might even have tried to achieve.
I wish companies realize that OKR, like working from the office, are things of the past that no longer fit in the world we live in, where things move at an incredible fast pace.
> If it takes 3 weeks into the quarter to define your OKRs for the quarter, well, congratulations, you spent those 3 weeks choosing what you’ll actually do this quarter. You’ll make the case that the things you’re working on are really important and already in progress, even if they’re not lined up exactly with the department OKRs. And they may be really important, and the OKRs may be wrong because we didn’t spend enough time working on them and took too long to deliver them, and we didn’t leave room for bottom-up objective setting. So we do the important things we’re already doing, and we’ll fudge the KRs a bit at the end of the quarter.
LOL this paragraph really spoke to me. I've been in FAANG for 6 years, and every time roadmapping/OKRs come around this always happens.
As an IC, those weeks spent planning are precious time that could be spent landing ~impact~ for your performance review, so you might do a mini-planning session to figure out how to use your time. That project that you picked up ends up getting traction, but due to disconnects with the team's planning process, the overall OKRs no longer align with your work! Guess we'll have to fudge the numbers...
LOL this paragraph really spoke to me. I've been in FAANG for 6 years, and every time roadmapping/OKRs come around this always happens.
As an IC, those weeks spent planning are precious time that could be spent landing ~impact~ for your performance review, so you might do a mini-planning session to figure out how to use your time. That project that you picked up ends up getting traction, but due to disconnects with the team's planning process, the overall OKRs no longer align with your work! Guess we'll have to fudge the numbers...
[deleted]
I work at a anti-fraud department, settings up OKR is always difficult because fraud happens in every unexpected way. IDK how others are doing it, but I'd really like to see a detailed OKR for a game like Tetris.
Ah yes, the 1000 word useless collection of thoughts on a nuanced and dense topic, followed by a flurry of kvetching and outlier horror stories in the comments. Classic HN work organization and management discussion.
I miss n-gate updates, but this made my minute!
There's plenty of problems with OKRs, but almost all the OKRs I encountered were bottom-up. I'm sure it was different in other parts of the company, though. Working on developer tools is the best.
I have heard about OKRs but feel I don't really grok them. How can the whole org have common goals. Consider an IT dept. In my company, they ONLY focus on security .. which means they spend all their time locking things down and making life intolerable for end users. From my perspective, security should be one metric but others would be subjective (user's perspective of IT systems and services) and objective (avg number of tickets, turn-around time, etc.). Even in a chip company, how does a sub-org like IT implement OKRs?
> All of them set a hierarchical pyramid of OKRs that cascaded down, rather than a set of OKRs that worked bottom-up, even if the company wasn’t in a crisis and would have benefited from promoting innovation.
Maybe I've only worked companies that do OKRs wrong, but I can't imagine what the bottom-up version of this would even look like. Individual teams pick their own OKRs, and then the exec above that looks at all of the OKRs that their various teams have decided on and then summarizes them in some way as their own OKRs after the fact?
Maybe I've only worked companies that do OKRs wrong, but I can't imagine what the bottom-up version of this would even look like. Individual teams pick their own OKRs, and then the exec above that looks at all of the OKRs that their various teams have decided on and then summarizes them in some way as their own OKRs after the fact?
That’s kind of the only way I have seen them. Individual teams define the okr and they bubble up. I don’t know what summarizes as their own would mean, but the first part was right.
Bottoms up works really good. It needs to always be understood that bottom tier OKRs don’t always directly tie to higher level OKRs and that is okay.
This is a good insight. The biggest problem I've seen with OKRs is the desire to "align" them, which always ends up meaning that each manager rewrites their team's OKRs to fit into their director's OKRs and so on up the ladder. This doesn't "align" anything, it conceals a lack of alignment and makes it impossible to address whatever the underlying issue is.
It seems to me that if the result of an OKR process is a bunch of team OKRs that have little to do with the company strategy, the result of that should not be to repeat the process or rewrite the OKRs but for company leadership to spend the next quarter figuring out what's going on (communication issue, too many underlying technical struggles to be able to prioritize, the company strategy is bad and nobody understands or likes it, etc.).
It seems to me that if the result of an OKR process is a bunch of team OKRs that have little to do with the company strategy, the result of that should not be to repeat the process or rewrite the OKRs but for company leadership to spend the next quarter figuring out what's going on (communication issue, too many underlying technical struggles to be able to prioritize, the company strategy is bad and nobody understands or likes it, etc.).
In truth I kind of question the usefulness of "higher level" OKRs. They become too fuzzy and meaningless. Worse, I think it is almost impossible to come up with quantifiable key results that are directly influenced by the work of "lower level" OKRs.
Tired of people such as author of this post jumping on the OKRs are bad bandwagon. OKRs are a tool - they are not inherently good or bad but used well they can be good and misused they can be bad.
My source for this is when I first used OKRs to manage a small team they were fantastic. Really focussed our energy and drove the team forward.
Now I'm trying to grow the business I'm struggling to make OKRs stick as well as they did previously. I truly believe I'm misusing them as a tool - and now need to rethink my approach.
My source for this is when I first used OKRs to manage a small team they were fantastic. Really focussed our energy and drove the team forward.
Now I'm trying to grow the business I'm struggling to make OKRs stick as well as they did previously. I truly believe I'm misusing them as a tool - and now need to rethink my approach.
I think we all understand that tools are just tools. But when a tool is as widely misused as OKRs are, there's probably something wrong with the tool.
I agree. What could be more important? It is leadership's job to set the goals. If the goals fail, leadership has failed.
Here is an expanded summary for those who want to learn more: https://medium.com/@rocketsyntax/okr-framework-strategic-pla...
Here is an expanded summary for those who want to learn more: https://medium.com/@rocketsyntax/okr-framework-strategic-pla...
I've been wrestling with this recently as well, and found a great read re: OKRS versus a framework called OGSM.
It provides the metrics and strategies that OKRs are missing - and results in deeper thinking up front.
Here's a good read on this - https://medium.com/infinite-beta/ogsm-okr-8761dcb50e02
It provides the metrics and strategies that OKRs are missing - and results in deeper thinking up front.
Here's a good read on this - https://medium.com/infinite-beta/ogsm-okr-8761dcb50e02
Objectives and key results (OKRs). It's baffling that software engineers don't understand they have to define a variable before using it.
Uh, please see https://news.ycombinator.com/item?id=31420938 (Stop using grey text). Especially on a grey background. My eyes don't have enough life in them to try to read this.
(Yes this is off topic and about formatting and it's boring.)
(Yes this is off topic and about formatting and it's boring.)
Ironically, you're being downvoted and right now your text is grey.
Yeah, maybe I should reconfigure the default theme to light mode and try to add the CSS prefers-color-scheme media query.
For now, if you want, you can click the circle in the upper right to toggle to light mode.
Thanks for the feedback!
For now, if you want, you can click the circle in the upper right to toggle to light mode.
Thanks for the feedback!
I second your discomfiture at gray text.
Firefox has "Reading mode" button right in URL box. Both on desktop and mobile. Enjoy!
Thought of that after posting and closing the tab. But I don't feel like going back. It makes me angry that people think making text as hard to read as possible is good design. But it's just my opinion, and it's OK for people to have differing opinions. I just choose not to spend my time and eyeballs on their content.
[deleted]
While I admire the optimism of what OKRs are suppose to do, I've never seen them done well or with a positive net outcome. In reality, it's been another one of those things that require discipline by everyone involved and is harder to accomplish at a large organization.
So, if you follow the link from the first word of the blog (the one giving details on what OKRs are), it takes you to a site[1] which when you go to the cookie prefs when prompted about what cookies you want, has a section I haven't really seen before (or was oblivious to before), called "Unclassified" with quite a few cookies. The difference between this section and the others? While others have a checkbox forced checked (Necessary cookies) or a checkbox you can toggle to accept or not (Preferences and Marketing), the Unclassified section doesn't offer up any checkbox at all.
Seems awfully convenient to have a bunch of cookies you haven't classified so don't need to offer a choice to your users about.
1: https://www.whatmatters.com/
Seems awfully convenient to have a bunch of cookies you haven't classified so don't need to offer a choice to your users about.
1: https://www.whatmatters.com/
Any pro-OKR arguments now sound more and more like "But Real communism has never been tried" :)
OKRs are a joke made up by MBA product focused types to try and remain relevant
OKRs written properly drive business and development initiatives. They should be boiled down to the smallest team so that they can make a big impact on the business while not doing worthless dev work.
Am I the only one that saw “jibe” at the end of the article, thought it was incorrect, looked it up, and discovered I have been using “jive” incorrectly instead for years?
[deleted]
OKRs are a tool that barely competent psychopaths reach for. Possibly they work for other use cases (sales?) where everyone's a psychopath. The high functioning psychopaths don't need such ineffective tools.
I feel like OKRs are poor version of google's 20% free time policy
[deleted]
While I think OKRs are necessary, and strategic leadership is necessary to achieve them, consider that whether a company is being led to an objective, or managed to optimize itself - is entirely dependent on the stage of the company. I'd argue optimization phase OKRs are negatively defined, where growth phase OKRs are positively definied.
Stages I think of as survival/subsistance, product market fit, and max market share, are growth phases, whereas stages like max stock price and max gross margins, are optimization phases of a company. Optimization phases are when you already have market fit and a revenue stream, where as a board you can just drop in a bunch of MBAs to refine and hollow out the org and stabilize the company as a revenue stream in a portfolio. Management is value extraction, and it is a specific skillset that a company needs when it has a revenue producing asset, which it needs to optimize for stability, so that it can be used as collateral for leverage into new ventures. That's the point of management: to stabilize an asset with steady hands so that it is a coherent asset that can be traded and leveraged.
Leadership qualities in managers are mainly plumage on (or cover for) their foundation of extractive skills, and are neither sufficient or necessary. You can't manage something until there is a null hypothesis, where the thing makes value or money already (default-alive in PG parlence). This is why managers creating OKRs often sound so vague, it's because they rig the OKR definition to avoid a perception of failure that would cause their attrition in a zero-sum optimization environment. OKRs are necessarily about black-and-white outcomes, whereas, managing is a matter of sustaining and directing an equllibrium. (yes, b&w thinking is usually considered "bad," but mainly from a mangerial frame of reference). I'm proposing OKRs are a growth/leadership phase tool that feels cargo culty in optimization/management phase companies.
Smart people become managers because they can reason abstractly about stuff that makers, leaders, and IC's take personally, and there is a lot of value in learning to respect that skill, even when it is repellant, and not fall into the trap of merely moralizing our own limitations. (my bias should be obvious)
Leadership is for the growth phases of a company, where you need to get from zero to one, a to b, subsistance to product market fit - where the function of leadership is to affect change. A company whose majority growth phase is behind it is in a stable state doesn't need change, it needs to be managed and optimized as an asset for leverage. It's dumb to drop leaders into stable companies because the inertia of the company is already headed toward an equillibrium of being a commodity asset, a piece of financial furniture in portfolios, and change agents (leaders) either have to derail that to succeed, or get frustrated and leave.
For a FAANG company to have OKRs below the manager level now seems misguided, as their growth phases are behind them, e.g. the majority of the change in their revenue growth is going to come from cost management and margins, and not from growing into new market share. Their best hope for market share growth is demographic change, as if you haven't adopted their product by now, you're probably not going to unless you were born recently and are just discovering the product, or you have just arrived and the products are part of your new life. Otherwise, I'm probably not going to become a new user/market share of a FAANG product.
As an optimization phase company you can't tell your engineering staff that the future is lean and that the company is now a zero-sum optimization problem, which their job is to beat out everyone else at doing the same or more with less. That's a great and strategic place to make a P&L mark as a manager, but a shitty place to be someone who builds and makes things. Your upside comes from outsourcing functions and services, integrating with tech debt, and other brain damaging tasks. An OKR in an optimization stage company is whether a function can survive being operated by cheap and the absolute minimally competent people. It's mainly about cost reduction. Imo, OKRs in an optimization stage company are like skinny jeans on a middle aged man, where nobody wants to have to be the one to say it, but they're past the stage where it's appropriate.
OKRs make more sense in a startup or a growth stage company where there is a sense of shared mission and clear outward direction for growth, and where you're betting on growing your way out of a lot of problems. Deliver a feature that positions us for this market share growth, make something someone wants, establish PMF, establish feature parity w/ competitors, improve conversions in the pipeline by x% - these are the things that leadership is designed to achieve. It's high risk and leadership has terrible failure modes, but that's an artifact of the company stage.
Long comment with intent to provoke discussion, but if your OKR is not concrete and a b&w binary outcome, I'd ask whether you are in an org that is still in a growth phase, and whether this is what you want. Nothing wrong with being in an optimization phase company (e.g a bank) but not being aligned personally to the phase of your company is a recipe for suffering.
Stages I think of as survival/subsistance, product market fit, and max market share, are growth phases, whereas stages like max stock price and max gross margins, are optimization phases of a company. Optimization phases are when you already have market fit and a revenue stream, where as a board you can just drop in a bunch of MBAs to refine and hollow out the org and stabilize the company as a revenue stream in a portfolio. Management is value extraction, and it is a specific skillset that a company needs when it has a revenue producing asset, which it needs to optimize for stability, so that it can be used as collateral for leverage into new ventures. That's the point of management: to stabilize an asset with steady hands so that it is a coherent asset that can be traded and leveraged.
Leadership qualities in managers are mainly plumage on (or cover for) their foundation of extractive skills, and are neither sufficient or necessary. You can't manage something until there is a null hypothesis, where the thing makes value or money already (default-alive in PG parlence). This is why managers creating OKRs often sound so vague, it's because they rig the OKR definition to avoid a perception of failure that would cause their attrition in a zero-sum optimization environment. OKRs are necessarily about black-and-white outcomes, whereas, managing is a matter of sustaining and directing an equllibrium. (yes, b&w thinking is usually considered "bad," but mainly from a mangerial frame of reference). I'm proposing OKRs are a growth/leadership phase tool that feels cargo culty in optimization/management phase companies.
Smart people become managers because they can reason abstractly about stuff that makers, leaders, and IC's take personally, and there is a lot of value in learning to respect that skill, even when it is repellant, and not fall into the trap of merely moralizing our own limitations. (my bias should be obvious)
Leadership is for the growth phases of a company, where you need to get from zero to one, a to b, subsistance to product market fit - where the function of leadership is to affect change. A company whose majority growth phase is behind it is in a stable state doesn't need change, it needs to be managed and optimized as an asset for leverage. It's dumb to drop leaders into stable companies because the inertia of the company is already headed toward an equillibrium of being a commodity asset, a piece of financial furniture in portfolios, and change agents (leaders) either have to derail that to succeed, or get frustrated and leave.
For a FAANG company to have OKRs below the manager level now seems misguided, as their growth phases are behind them, e.g. the majority of the change in their revenue growth is going to come from cost management and margins, and not from growing into new market share. Their best hope for market share growth is demographic change, as if you haven't adopted their product by now, you're probably not going to unless you were born recently and are just discovering the product, or you have just arrived and the products are part of your new life. Otherwise, I'm probably not going to become a new user/market share of a FAANG product.
As an optimization phase company you can't tell your engineering staff that the future is lean and that the company is now a zero-sum optimization problem, which their job is to beat out everyone else at doing the same or more with less. That's a great and strategic place to make a P&L mark as a manager, but a shitty place to be someone who builds and makes things. Your upside comes from outsourcing functions and services, integrating with tech debt, and other brain damaging tasks. An OKR in an optimization stage company is whether a function can survive being operated by cheap and the absolute minimally competent people. It's mainly about cost reduction. Imo, OKRs in an optimization stage company are like skinny jeans on a middle aged man, where nobody wants to have to be the one to say it, but they're past the stage where it's appropriate.
OKRs make more sense in a startup or a growth stage company where there is a sense of shared mission and clear outward direction for growth, and where you're betting on growing your way out of a lot of problems. Deliver a feature that positions us for this market share growth, make something someone wants, establish PMF, establish feature parity w/ competitors, improve conversions in the pipeline by x% - these are the things that leadership is designed to achieve. It's high risk and leadership has terrible failure modes, but that's an artifact of the company stage.
Long comment with intent to provoke discussion, but if your OKR is not concrete and a b&w binary outcome, I'd ask whether you are in an org that is still in a growth phase, and whether this is what you want. Nothing wrong with being in an optimization phase company (e.g a bank) but not being aligned personally to the phase of your company is a recipe for suffering.
OKRs are also a tool for communicating priorities and agendas in all directions of the hierarchy.
I think they work reasonably well for that. They're succinct and the key results force them to be grounded on some reality that people can relate to.
I think they work reasonably well for that. They're succinct and the key results force them to be grounded on some reality that people can relate to.