3 ms·

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 tha

by cletus 4y ago

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.

markrages 4y ago
> 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.
commandlinefan 4y ago
> 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.
- LowkeyMouths 4y ago
  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.
  - commandlinefan 4y ago
    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.
dougdonohoe 4y ago
> 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?
- djur 4y ago
  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.
- theptip 4y ago
  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.
higeorge13 4y ago
#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.
theptip 4y ago
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.

by cletus 4y ago

markrages 4y ago

> 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.

commandlinefan 4y ago

> 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.

LowkeyMouths 4y ago
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.
- commandlinefan 4y ago
  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.

dougdonohoe 4y ago

> 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?

djur 4y ago
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.
theptip 4y ago
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.

higeorge13 4y ago

#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.

theptip 4y ago

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.