4 ms·

It feels like OP has made a bit of a straw man out of OKRs. More charitably, perhaps we did not get our information from the same place - all I know about OKRs

It feels like OP has made a bit of a straw man out of OKRs. More charitably, perhaps we did not get our information from the same place - all I know about OKRs is from reading "Measure What Matters" and implementing it in my own company. Reading this article makes me feel like someone took an incredibly simple idea and decided that what it needs is more complication. From TFA: "most companies are not set up to effectively apply this technique". Yes. And if you read the above book, you'll learn that this is sort of the point. You WILL fail at your first few OKR cycles, but you're supposed to use those experiences to change your company into one that CAN set and achieve objectives. If you think your company is one where OKRs won't work, all the more reason to do them. OKRs are about creating and communicating strategic short-term objectives across the company, so they remain top of mind. And that's 80% of what you need to know! The objections to OKRs mentioned in the article don't make sense to me, because it seems to follow a different definition of what OKRs are.

quadrifoliate 6y ago
> all I know about OKRs is from reading "Measure What Matters" and implementing it in my own company. Reading this article makes me feel like someone took an incredibly simple idea and decided that what it needs is more complication. I know this is HN and you could totally be Drew Houston; but I'm going to go out on a limb and say that your company has fewer than 500 employees. The problems the OP is describing are, in my opinion, usually present at a large, bureaucratic company. There is no strict size definition for this (I've seen incredibly bureaucratic 50-person startups), but Dunbar's number [1] is a good rule of thumb. > You WILL fail at your first few OKR cycles, but you're supposed to use those experiences to change your company into one that CAN set and achieve objectives. Once you get into a bureaucratic company, it's largely about avoiding failure or the perception thereof. Since you own your company, it's easy for you to take this overall view of "if it failed, it failed". Any mid-level manager or individual contributor is going to be incentivized to avoid the perception of failure since it's super-bad in a large organization. Google is often used as a counterexample, but I'm not entirely sure that Google is a company that's good at making products. Also, Google uses the approach of "Hire extremely smart people and throw a truckload of money at them" approach which most companies under discussion (including yours) likely don't; which (IMO) is a far better predictor of success than OKRs. > The objections to OKRs mentioned in the article don't make sense to me, because it seems to follow a different definition of what OKRs are. This is the No True Scotsman fallacy. The reality is that the "cascading" nature of OKRs often gets lost in translation and doesn't take into account macro-level changes in your specific vertical. Yes, the company's goal is to become a leader in the field of underwater baskets; how does this translate to me rewriting that terrible frontend code that the cofounder's buddy wrote in 2007 and has never been touched since? Doing that translation will become more difficult year by year due to how technology evolves; and most people in "leadership" suck at doing that translation well. That's what the article is talking about. [1] https://en.wikipedia.org/wiki/Dunbar%27s_number https://en.wikipedia.org/wiki/Dunbar%27s_number
- daveungerer 6y ago
  Nowhere in the book is it pitched as a tool you roll out to a bunch of MBAs and hope that good things happen - it's never about out-of-touch managers demanding results. If someone cascades objectives without also cascading planning and estimation, are they not simply a bad manager? What the book DOES say is that you should not create such a fear of failure that no-one will set stretch goals, and that OKR results should not replace individual performance evaluations. In short, OKRs are what you seem to think they are, plus the culture that makes it possible. If an organisation doesn't get that right, are they doing OKRs? If your organisation does not allow developers to push back against impossible objectives, do you not perhaps have bigger problems that OKRs (or any other system) can't fix for you? Why would you blame OKRs - would any other system not also be painful when a company has become so dysfunctional? Also, did you know that all objectives don't need to cascade - some can be set bottom-up? You're going to call No True Scotsman fallacy, and I'm going to call Straw Man, so I'm done with this thread. Perhaps I just fell for John Doerr's elaborately constructed fantasy that he uses to sell books. But right now it seems like a useful tool to keep a company on track, and I'll keep adapting it as the company grows.
  - athenot 6y ago
    I'll add to this thread that I was largely against OKRs, having seen them implemented in the style of "we need a quantitative measurement for success so let's make something up hastily", only to fall prey to Goodhart's Law[1]. But John Doerr's book introduced me to the bridge of concepts that I was not seeing: in a healthy setup, we are first and foremost focused on a qualitative objectives and THEN we attempt to model that fuzzy feeling with a quantitative measure (the "key result") that should reflect success. It takes several iterations in order to come up with a matching measurement, and even then we need to constantly re-evaluate whether the measurement is appropriate or if is devolving into a numbers game devoid of true objective. In other words the full acronym is OAMBKY, or "Objectives, AS MEASURED BY Key Results". But that doesn't roll off the tongue quite as well. So in that light, OKRs are a useful tool IF AND ONLY IF leadership—as well as the whole team—are focused on the philosophical, qualitative goal and are all aware that the measurement is only an imperfect proxy that is contantly re-evaluated to help us better assess the goal; not a goal unto itself. But that takes real leadership to drive that message (as well as avoiding setting up misguided incentives). [1] When a measure becomes a target, it ceases to be a good measure.
cdavid 6y ago
I am curious about your perspective. I work in a large-ish company (few 1000s people), I am managing ~25 people and this is the first organization where I used OKRs. I found them pretty worthless myself, and for similar reasons as the OT. Fundamentally, OKRs only make sense if your organization is focused on outcomes, not on output. And underlying that, that's really about the culture in your org. It requires a good executive and sr management team to actually cascade the OKR into non direct financial terms. E.g. if your product objective is to increase retention by X, how do you translate this into a strategy ? Also, OKRs don't make much sense if product/engineering are run separately. This is still extremely common outside of tech companies. The cascading, which I considered as one of the most fundamental difference compared to traditional management by objective, is often a productivity killer, because 2. If you do OKRs every quarter, and you have 3-4 levels to cascade to, you're gonna get your OKRs end of first month, which means you realistically only really have 6 weeks left in your quarter. Finally, Measure what matters, I don't understand that book. I found it completely worthless as an Eng. Manager, with absolutely 0 actionable insight. It could have been 5 pages. The famous example of a football team is the only example that actually has enough details to explain things. On similar topics, high output management, or even hard things about hard things, were much more useful for a middle manager like me.

quadrifoliate 6y ago

> all I know about OKRs is from reading "Measure What Matters" and implementing it in my own company. Reading this article makes me feel like someone took an incredibly simple idea and decided that what it needs is more complication. I know this is HN and you could totally be Drew Houston; but I'm going to go out on a limb and say that your company has fewer than 500 employees. The problems the OP is describing are, in my opinion, usually present at a large, bureaucratic company. There is no strict size definition for this (I've seen incredibly bureaucratic 50-person startups), but Dunbar's number [1] is a good rule of thumb. > You WILL fail at your first few OKR cycles, but you're supposed to use those experiences to change your company into one that CAN set and achieve objectives. Once you get into a bureaucratic company, it's largely about avoiding failure or the perception thereof. Since you own your company, it's easy for you to take this overall view of "if it failed, it failed". Any mid-level manager or individual contributor is going to be incentivized to avoid the perception of failure since it's super-bad in a large organization. Google is often used as a counterexample, but I'm not entirely sure that Google is a company that's good at making products. Also, Google uses the approach of "Hire extremely smart people and throw a truckload of money at them" approach which most companies under discussion (including yours) likely don't; which (IMO) is a far better predictor of success than OKRs. > The objections to OKRs mentioned in the article don't make sense to me, because it seems to follow a different definition of what OKRs are. This is the No True Scotsman fallacy. The reality is that the "cascading" nature of OKRs often gets lost in translation and doesn't take into account macro-level changes in your specific vertical. Yes, the company's goal is to become a leader in the field of underwater baskets; how does this translate to me rewriting that terrible frontend code that the cofounder's buddy wrote in 2007 and has never been touched since? Doing that translation will become more difficult year by year due to how technology evolves; and most people in "leadership" suck at doing that translation well. That's what the article is talking about. [1] https://en.wikipedia.org/wiki/Dunbar%27s_number https://en.wikipedia.org/wiki/Dunbar%27s_number

daveungerer 6y ago
Nowhere in the book is it pitched as a tool you roll out to a bunch of MBAs and hope that good things happen - it's never about out-of-touch managers demanding results. If someone cascades objectives without also cascading planning and estimation, are they not simply a bad manager? What the book DOES say is that you should not create such a fear of failure that no-one will set stretch goals, and that OKR results should not replace individual performance evaluations. In short, OKRs are what you seem to think they are, plus the culture that makes it possible. If an organisation doesn't get that right, are they doing OKRs? If your organisation does not allow developers to push back against impossible objectives, do you not perhaps have bigger problems that OKRs (or any other system) can't fix for you? Why would you blame OKRs - would any other system not also be painful when a company has become so dysfunctional? Also, did you know that all objectives don't need to cascade - some can be set bottom-up? You're going to call No True Scotsman fallacy, and I'm going to call Straw Man, so I'm done with this thread. Perhaps I just fell for John Doerr's elaborately constructed fantasy that he uses to sell books. But right now it seems like a useful tool to keep a company on track, and I'll keep adapting it as the company grows.
- athenot 6y ago
  I'll add to this thread that I was largely against OKRs, having seen them implemented in the style of "we need a quantitative measurement for success so let's make something up hastily", only to fall prey to Goodhart's Law[1]. But John Doerr's book introduced me to the bridge of concepts that I was not seeing: in a healthy setup, we are first and foremost focused on a qualitative objectives and THEN we attempt to model that fuzzy feeling with a quantitative measure (the "key result") that should reflect success. It takes several iterations in order to come up with a matching measurement, and even then we need to constantly re-evaluate whether the measurement is appropriate or if is devolving into a numbers game devoid of true objective. In other words the full acronym is OAMBKY, or "Objectives, AS MEASURED BY Key Results". But that doesn't roll off the tongue quite as well. So in that light, OKRs are a useful tool IF AND ONLY IF leadership—as well as the whole team—are focused on the philosophical, qualitative goal and are all aware that the measurement is only an imperfect proxy that is contantly re-evaluated to help us better assess the goal; not a goal unto itself. But that takes real leadership to drive that message (as well as avoiding setting up misguided incentives). [1] When a measure becomes a target, it ceases to be a good measure.

cdavid 6y ago

I am curious about your perspective. I work in a large-ish company (few 1000s people), I am managing ~25 people and this is the first organization where I used OKRs. I found them pretty worthless myself, and for similar reasons as the OT. Fundamentally, OKRs only make sense if your organization is focused on outcomes, not on output. And underlying that, that's really about the culture in your org. It requires a good executive and sr management team to actually cascade the OKR into non direct financial terms. E.g. if your product objective is to increase retention by X, how do you translate this into a strategy ? Also, OKRs don't make much sense if product/engineering are run separately. This is still extremely common outside of tech companies. The cascading, which I considered as one of the most fundamental difference compared to traditional management by objective, is often a productivity killer, because 2. If you do OKRs every quarter, and you have 3-4 levels to cascade to, you're gonna get your OKRs end of first month, which means you realistically only really have 6 weeks left in your quarter. Finally, Measure what matters, I don't understand that book. I found it completely worthless as an Eng. Manager, with absolutely 0 actionable insight. It could have been 5 pages. The famous example of a football team is the only example that actually has enough details to explain things. On similar topics, high output management, or even hard things about hard things, were much more useful for a middle manager like me.