10 ms·

Hitting OKRs vs. Doing Your Job

369 points by zdw 2y ago

gbin 2y ago
"Let OKRs highlight a special focus. Don’t try to cram everything you do into them" Then link compensation to OKRs then everybody just focuses on bending the reality to meet the letter of the OKR and nobody is interested in doing their job. After the "oh shit" moment, we cram everything we do into them. Then everybody ignores OKRs.
- osmsucks 2y ago
  The most insulting case is that of the retroactively-adjusted OKR wording so that you can always meet 0.7+ scores.
- szundi 2y ago
  I remember when reading about Intel and OKRs in every management execution book. I thought that's the time to sell the stock.
  - Aromasin 2y ago
    They brought them back during my recent tenure at Intel, just after Pat joined. I was an application engineer, so my purpose was to debug customer support issues on our chips, filter between the customer and the engineering staff, write some User Guides and helpful collateral to developers, and open tickets with engineering when problems were severe enough. My OKRs could have just been "close tickets" and I think that would have been the best ROI for the company - there was never a point in my career where I didn't have tickets that needed working on that were halting multiple millions in revenue, but somehow my time was always spent having to work on other things. Management insisted on filling my OKRs with low-value 1:N activities - spending time on the forum (full-time forum people were paid to do that), helping sales with technical discussions with customers (field engineers were paid to do that), creating demos/PoCs for marketing (technical marketing engineerings were paid to do that), or being part of one "centre of excellence" or another wasting time in meetings with non-technical people talking about how we were all going to tackle problems when the reality was that no one in the team had the time, talent, or political capital to do any of the things we spent hours discussing. To me, OKRs seem effective for the workforce in the same way scout badges are effective for children to learn skills - good for those who otherwise would do nothing. The issue is, for intrinsically motivated people who are incredibly specialised in a largely reactive role they are a distraction at best, and when used for quarterly and yearly performance tracking, a detriment to the core role at worst.
    - PaulHoule 2y ago
      I worked at a startup where the main problems I saw were: (1) It was impossible for anyone to enforce anything. Our genius business development guy couldn't get our head data scientist to share data files with customers (say Big 5 accounting firms) in a way they felt were safe. I couldn't get the data scientists to use standardized versions of Python. (Docker just accelerated their ability to find defective Pythons, such as one with Hungarian as the standard charset) The engineering manager would tell me "we use monads for error handling in Scala" and "we do code reviews" but I don't believe the latter because the first certainly wasn't true. (2) We were developing core technology and developing solutions for various customers. There was a lot of zigging and zagging and spoiled work in progress. I felt like the customer contact was helping us understand the requirements for the core so I'm not complaining about that. Our management practices should have been focused 100% on squaring that circle. The VCs believed in our vision and our BD genius (I did!) but they knew we were badly managed and brought in a stream of consultants some of whom were helpful and some who weren't. The worst was the consultant who came in and forced us all to write OKRs which took two weeks against the core and solution and development work that did matter for the business. My feeling was that my job was to pull for the team wherever it needed it and it wasn't my business to set goals that weren't fundamentally grounded in the needs of the team. I had enough work to do that I didn't need to add a single task that wasn't on that critical path. Particularly customer requirements could change faster than the OKR cycle, we needed practices that worked at the speed of our business. I was anxious that when review time came along I'd find that, out of 20 OKRs, I would nail 5 of them, totally fail at 5 of them and the other 10 would be in between. At review time whether this is success failure would depend on politics and ability to navigate politics. That genius BD would deservedly get a good review, a really good coder or data sci may or may not. People with high and unmitigated narcissism are privileged by systems like stack ranking and OKR because they are focused on presentation of self in ways that average people aren't.
friendzis 2y ago
Goodhart's law is an adage often stated as, "When a measure becomes a target, it ceases to be a good measure".
- blueboo 2y ago
  I prefer Campbell’s Law — the more a metric is used in social decision-making, the more likely it is to be manipulated. You’ve stated the widely-accepted formulation of Goodhart’s, but it can be interesting to note Charles Goodhart’s original statement was that “any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes.” (The implication is people doubly go wrong presuming the regularity’s existence and placing pressure on it!)
  - friendzis 2y ago
    I'm being humorous here. I kinda disagree with tour takeaway. I have expanded on this idea elsewhere in this thread, however, the main point is that a measure is a byproduct of an existing process. Making the measure a target, i.e. process output, changes (possibly inadvertently) the process itself. It does not matter if the regularity truly existed or was wrongly presumed to exist, as putting pressure on it invalidates the causal relationship it had before.
    - zmgsabst 2y ago
      I’m not sure I’ve heard it summarized that way before: that good process causes good metrics, but good metrics don’t cause good process. People are indeed prone to affirming the consequent. https://en.wikipedia.org/wiki/Affirming_the_consequent https://en.wikipedia.org/wiki/Affirming_the_consequent
mrayycombi 2y ago
https://blog.appliedcomputing.io/p/okrs-are-bullshit https://blog.appliedcomputing.io/p/okrs-are-bullshit
padolsey 2y ago
Now having worked in a few smaller teams since my time at FB, I realize how marvellous it is to not have to worry about OKRs, performance reviews and all that malarkey. It was so draining to run yourself as a mini PR/brand within one's team (/one's department) and market oneself (one's team) to your manager (/your company). So much mental bandwidth was spent. I also, from a systems-thinking POV, just fundamentally reject the value in OKRs as a meaningful proxy for the value you (/your team) are producing unless you are an entirely mechanistic function. By mechanistic I mean you have a clear discrete Input<>Output expectation. Every single time an element of human activity is reduced to a metric, you lose something, and if you do it enough times, you've effectively produced a metric that is completely distinct from the thing you intended on measuring in the first place. For example: let's say you're in the suicide prevention team at FB, and your OKR is 'number of suicides averted'. Well, that sounds good, but unbeknownst to you, perverse incentives have kicked in and invisibly imbued your metric-chasing experiments a dark undertone. A new risk model might start flagging more content as potentially suicidal to boost numbers, leading to over-intervention that could traumatize users or waste resources. Or perhaps the surface we use to measure success, a UX or user activity metric, might actually be uncorrelated with crisis aversion or... and this is where it hits: the thing that's instrumental in crises is social media itself. The metric becomes a game, and it games _you_. Your team thinks you're doing X, but you're really doing Y. Because you're disattached from the real problem and comforted by incredibly lossy proxies.
- friendzis 2y ago
  I have semi-humorously dropped a comment defining Goodhart's law. The problem you are describing is nothing else but Goodhart's law in action: A measure stops being a good measure, i.e. be a proxy for something, once there are objectives attached to it. In other words, attaching goals to a metric invalidates previous causal relationship. That's neither bad, not good. It's a property of goal setting. The problematic part is still treating the measure as if it had causal relationship to something when that relationship has already been invalidated. In your example, number of suicides ceases to be comparable between pre and post OKR timeframes, however if you look closely, this particular goal is based on a metric the underlying OKR targets invalidate. Yes, sometimes you get these weird tautologies where you have to change the whole framework/process to make something both targetable and measurable simultaneously, potentially losing comparability to past data.
lifeisstillgood 2y ago
OKRs are just another word for priority. You have an infinite amount of “could do” and a limited amount of “must do”, and “must” is very rarely clear a year or more out in any measureable sense So eventually we come to “support the overriding mission”, and record everything we do, and we can retroactively look to see who contributed most. It will never be who you think Plus that part is so politically driven you may as well say “elites will reward elites, those with skills will leave if they can find somewhere”
- lifeisstillgood 2y ago
  Just a thought but if “elites reward elites” is a truism, then only when you spread enough wealth around that elites become so common that democracy is the only viable means for elites to reward other elites…
qprofyeh 2y ago
As an engineer I have nothing against OKRs. But it's often the day-to-day management (EM or PM) who tend to override the team's OKRs for upper management to prioritize something ad-hoc & out of scope they agreeably said Yes to.
- Cthulhu_ 2y ago
  And that's fine I think, it's why a lot of companies are using one or more of the agile methodologies. But if that's combined with OKRs then said OKRs need to be adjusted, and it'll be down to the manager to pay that cost. We use SAFe at my current job (please don't look at the website, if you thought the "scrum" infographic was too big already lol); we set quarterly goals and objectives, usually don't meet them because Reasons, but if there is an incident or change that warrants changing those goals it's a Big Thing and we basically redo the planning sessions (two days or so); it's a big disruption and it's costly so it's not done lightly. We've only done that once in the past two and a half years or so.
  - wesselbindt 2y ago
    > it's a big disruption and it's costly so it's not done lightly Isn't this the very definition of not being agile?
    - robertlagrant 2y ago
      It's what the consulting class invented to lift the power that agile places in individual teams back up to management.
- xtracto 2y ago
  Engineering OKR: Make system like more stable and with less bugs. Product: Here are these 1567 story points for this new sprint with new product development stuff which is urgent and should be completed in 2 weeks.
ozim 2y ago
I always like to observe people who want quick results reading about agile or OKRs or KPIs and then handsomely shooting themselves into foot. Other fun thing is having management mandate those things and people who don’t have time to understand all that stuff implement it. Worst one is having ambitious young people thinking if they push for implementing those things they will be „real professionals” - that is how dev teams go to crawl enforcing all BS rules and product teams bikeshedding OKRs instead of delivering stuff.
- throwawaysleep 2y ago
  The need for “impact” in performance evaluations is also the cause of a lot of bike shedding. I had a meeting the other day where my manager sent our team and told us to “be visible so we have something to report for year end about broader impact.” We basically disrupted a meeting with poorly thought out commentary to put “cross pollination” on our self summaries.
- ibejoeb 2y ago
  >ambitious young people thinking if they push for implementing those things they will be „real professionals” This is a real problem. It can destroy a successful operation. I don't specifically want to blame "young" or any other particular attribute, but it's common in that ambitious corporate type. Hiring managers, especially in startups, should really think about a newcomer's background. If someone comes from services where the name of the game is billable hours, it is going to be ingrained that there are processes that exist to justify those hours. That fails when your client is your company.
praptak 2y ago
Duh, obviously I want "shipping the roadmap" in the OKRs. OKRs should capture everything you plan to do, otherwise what's the point? Obviously I don't want the whole roadmap, just the part we commited to. You probably also don't want only the roadmap, for obvious reasons. There's never enough time to do everything that's planned or necessary and OKRs should be the tool that lets you resolve the conflicts. Ship feature X or fix the infrastructure? "X is in OKRs, let's work on X". "X is not in OKRs and we have KR to get Y% success on autodeployments, let's fix infra". What I definitely don't want is "do OKRs and also do roadmap". The only things that should not be in the OKRs are ones where prioritization is trivial (like "fix critical outages").
SteveVeilStream 2y ago
The reality of OKRs (or Rockefeller Habits or any other company wide framework for establishing priorities and goals,) is that by going through the exercise of trying to create them across the company, you often discover that there are meaningful disconnects in how teams are prioritizing work or how teams function vs how other stakeholders in the company believe those teams are operating. The real value comes from diving deeper into understanding those things. However, companies often view those as annoyances and find a way to plow the goals through while completely missing that learning opportunity.
- AndrewSChapman 2y ago
  This. High level OKRs should be set by the company to steer the ship, and engineering OKRs should align with the company OKRs. Thus, the roadmap is defined by the OKRs - I believe that's the whole point.
  - WXLCKNO 2y ago
    It just takes so many cycles to get to a point where everyone in the company is on-boarded to OKRs properly and by then people are burnt out on them, going through the motions without seeing the value, at least from the bottom up.
- zoul 2y ago
  Yes! Instead of data-driven management, I believe in conversation-driven management. Frameworks such as OKRs are a way to spark helpful conversations.
  - maayank 2y ago
    Or, you could have these conversations without OKRs?
- ghaff 2y ago
  Large organizations also just have to be more process-driven and formal. And it's fine if you don't like that. At a former employer, I was much happier when it was a medium-sized enterprise than when it grew by almost 10x. A lot of things had to change that weren't really to my liking (or skill set) but they had to.
justinl33 2y ago
I strongly believe that the addition of every metric brings with it an associated productivity tax in the form of: 1. time spent doing things that exploit this metric 2. time spent purely documenting/surfacing this metric on your ‘brand’
michidk 2y ago
Yes, exactly this! We are actually spending soo much time deriving, thinking, formulating & refining OKRs from roadmap items that we could just declare as simple "Goals". We could get so much shit done during that time. Most of the time as the quarter goes on, we then scrap those OKRs anyway because we didn't manage to do them or they were too specific and requirements changed. I always had the feeling that what we are doing is bullshit. So great to finally hear it from someone else. I wonder how many engineering companies actually use OKRs though.
- rednafi 2y ago
  I call it planning palooza. It keeps a ton of people employed though.
brcmthrowaway 2y ago
What does OpenAI or Anthropic use?
zelphirkalt 2y ago
In my experience managemant roles set the OKRs in a closed circle, without feedback from technical employees and then things like reliable infrastructure are underestimated or forgotten. Once OKRs are set, they are set in stone, because management roles are too busy to come together again and additionally include engineering roles in the decision making process. Instead just put more pressure on engineering. This kind of thing easily destroys great team dynamic and makes people change from getting work done to meeting target metrics, even if they only game them. This can lead to good and essential people quitting and the downfall of the company.
- robertlagrant 2y ago
  I think this is an attribution error. The issues you list are a function of management style, not of OKRs. Any management technique is very dependent on management not behaving pathologically.
  - marcosdumay 2y ago
    Nah. What gets excluded is a function of management style. But that most important things are excluded is an inherent feature of OKRs.
rednafi 2y ago
If I could give one piece of advice to my early-career self, it’d be this: do more "visible" work rather than "good" work. The former gets you promoted, while the latter leaves you stuck as a senior engineer forever. For me, that ship sailed a while ago, and I’m sorta happy being stuck as a senior engineer. That puts me in a good spot to say OKRs are bullshit.
- lrog 2y ago
  With what other role / direction would you be satisfied instead of being SE? Going up in the IC ladder (lead, staff, etc.) or management? What disadvantages do you see settling at SE?
  - rednafi 2y ago
    Staff is the natural progression for people who want to take the next step but don’t want direct reports. Each company has its own definition of a staff engineer's responsibilities. I’ve seen people move back to SE after burning out from all the meetings. In some places, staff engineers rarely code and are essentially glorified team leads. But there are definitely companies where Staff engineers get to do some awesome work and there's a proper delineation between a Staff and a TL. I'm yet to work in a company like that yet.
- zeroonetwothree 2y ago
  Really depends on your priorities. For me I'd rather do 'good' work (or 'interesting' work to me) since I don't care about minmaxing my comp.
  - rednafi 2y ago
    Same and got stuck in the eternal loop of SE.
  - azemetre 2y ago
    Also if you are going to job hop in less than 3 years there's much less reason to play the corpo game.
doppp 2y ago
I still chuckle when I recall this tweet, "OKRs were actually a psyop from Google to slow down potential early stage competitors" [1]. [1] https://x.com/benwbear/status/1543056694330003456 https://x.com/benwbear/status/1543056694330003456
- PaulHoule 2y ago
  That's what I told the managers at one startup when they brought in a consultant to introduce OKRs.
- marcosdumay 2y ago
  I imagine React was the Facebook version of this. There's a famous theory that Gantt charts were actually created to keep decision-makers on the dark while Gantt could have some freedom to manage in a way that worked instead of letting they dictate some way that doesn't. Taylorism was, of course, something that Taylor never believed in. That's no secret, as he spoke against it several times. Most personal "ism"s are like that. (What he actually preached was something very different.) It's almost completely settled that current form "agile" was created by people that sold books and courses, and had not interest nor any professional experience in making teams work better. And I guess the list goes on, but I don't remember more. But surprisingly, the guy that invented stack-ranking apparently believed it was really great.
- wavemode 2y ago
  Funny - I used to make this same joke about Kubernetes.
DanielHB 2y ago
I remember reading an anecdote about this stuff from the book The Essential Deming by W. Edwards Deming the "father of the quality movement and was hugely influential in post-WWII Japan". It talked about some company moving oil around in barges, the setup was unprofitable and a new manager was brought up to fix it. He created metrics of the business, but didn't put any goals or goalposts for the barge crews and other managers in the company. All he did was simply print the metrics and glue them on every barge of the fleet weekly. Soon the whole project was massively profitable. Apparently the captains of the barges would compete with each other to see who could save more money, without any penalties for the low performing nor any rewards for the high performing barges. One thing that was very surprising is that the barges were given freedom to choose where to source materials and, more importantly, the fuel. Before the metrics the captains would pick whatever was closest no matter the prices, after the metrics the captains would, on their own, try to source fuel from the cheapest place that they could. No amount of central planning could have been as optimal as the prices fluctuated a lot from day to day, so whenever a captain saw a good deal he would re-fuel. It turns out that empowered people want to do a good job and want to save money.
- liontwist 2y ago
  I think business people understand the value of setting high level goals and giving autonomy to accomplish them. It’s a good sign if your job works this way. Unfortunately this tends to mostly be applied at the VP level. Engineers are modeled as expensive pieces of an equipment to optimize and derisk.
  - DanielHB 2y ago
    > I think business people understand the value of setting high level goals and giving autonomy to accomplish them. I think a lot of business don't, at least on the lowest levels of the org chart.
- chasd00 2y ago
  > It turns out that empowered people want to do a good job and want to save money. You have to be careful here. In your example those captains didn’t really care about their job they cared about getting the high score. Metrics, KPIs, etc work but only when they’re setup perfectly aligned with your actual business goals. Measure/score the wrong thing and you’ll get nowhere. For example, what if the metric posted was distance traveled by a barge. You’d have captains taking the longest routes possible just to get the high score instead of shipping the most product per unit time which is what the manager would have intended.
jtbetz22 2y ago
This post reflects an insidious anti pattern in the practice of setting OKRs: "shipping the roadmap" is not the objective, it is a means to achieving some other underlying objective. With a well written objective / key result (ex: "grow DAU by 30%"), you can abandon your entire roadmap two weeks into the quarter and still hit your OKRs. They enable you to respond to new information and lessons learned, rather than locking the whole team into a rigid plan for the entire quarter.
steveBK123 2y ago
I've always worked in a non-tech where our customers are internal. They have unfortunately read too many SRE/Phoenix Project/Big Tech Management Papers and so OKRs was one thing shoved down our throats. What I've found is that they've hired a slew of Product Mangers (tm) who mostly just sit in between devs & users, without coordinating cross team, actually writing specs/Jiras/roadmaps, etc. So each teams devs wrote their own OKRs, in ignorance of what users (who might be other tech teams) might actually want or what other teams OKRs are. For example, to use an analogy one team builds the foundation and decides their OKR is to use 15% less concrete next year. The other team builds frames and decides their OKR is to make the average building 15% taller next year. If any of them talked to actual final customers, they'd have found out the customers actually desire the buildings to be more robust to storm winds.
- m463 2y ago
  okr: reduce parts count me: Tesla,I want a car with turn signal and drive selector stalks!
  - Schiendelman 2y ago
    Has the new UX bothered you when using it? I got used to it in a day and it seems fine.
    - m463 2y ago
      how has quickly reversing to get a parking spot in moving traffic worked for you?
      - steveBK123 2y ago
        You see, in the new economy you don't even needs stalks! I simply hit this Autopark button and then my car alternates between inching back & forth to sharply jerking the wheel every which way, and then lands itself in the spot. All while taking 3x longer than a competent human parallel parker and with heart stopping near-misses of hitting the surround parked cards. Oh and curbs your rims 20% of the time. Oh and as the human driver you are still responsible to monitor for passing pedestrians and bikers. If it crashes it's because you weren't monitoring it closely enough. And if you hit the brakes to stop it, you are a wimp who doesn't trust the car which totally would have gotten it right if you let it.
dent9876543 2y ago
The problem is that OKRs are divorced from the “go do this piece of work” instruction, and so, just like code comments, they quickly become out of date or are outright ignored. Because of that, the prescription about SMART and focus on delivery is simply wasted effort. At best a duplication. The good part about OKRs is (/should be) that it forces an alignment conversation between teams and amongst managers. And the performance discussion with manager is often useful and sometimes revealing. More often both focus on metrics, losing the last opportunity to extract value from the concept.
dakiol 2y ago
Am I the only one who doesn’t care about OKRs or whatever companies are following nowadays? I tend to work around 2-3 years per company. Get a salary bump when switching. My first year is rather slow/smooth because “I’ve been here for less than a year!”. My second year is more interesting and I do take it as “real” work. My third year I couldn’t care less since I’m already looking for something else. I couldn’t care less about goals or OKRs. I get paid, I solve whatever problems the business has (whether they make sense or not) and then I just leave.
- kubb 2y ago
  This is the way. But I’m unlucky to have been locked into a small job market, so I’m stuck in a local maximum. Won’t be moving to the US anytime soon with Trump’s immigration policies.
- nine_zeros 2y ago
  This is the right approach. As an individual engineer, you are not paid enough to care about business problems and propose your own solutions and timelines. You are also not given organizational authority, budgets, or agency beyond your line of work. You literally haven't been given the tools to own metrics and OKRs. And moving those metrics and OKRs doesn't get you more money. So why would you care? You sound rational to me.
  - prh8 2y ago
    And even if/when you are paid well, you probably aren't given any meaningful ability to do the things necessary for those business problems. Corporate inertia is strong.
  - jensensbutton 2y ago
    > And moving those metrics and OKRs doesn't get you more money. Because you are already being paid to move those metrics and OKRs. Not doing so means you're not actually doing your job and, in a well managed company (which are admittedly few and far between), will be rightfully fired and replaced by someone who does.
- 2y ago
crowcroft 2y ago
I'm convinced there is no 'good' way to set goals/OKRs etc. in big companies. Orgs should set goals though, but the problem is when you spend too much time doing it. If top level management set company OKRs, and then cascade them down with every department and sub department then setting and aligning mini OKRs to the big ones you end up with a months long planning cycle which by the time you finish, you need to restart for the next year. A good heuristic is that no team should ever end up in a situation where they spend more time debating how a task should be prioritized than the amount of time the task takes to do.
indymike 2y ago
As long as the metrics attached to an OKR actaully a)make sense and b)are causally related to the OKR, then they can work. Where ORKs go off the rail is trying to set a goal for something you just can't manage.
jongjong 2y ago
OKRs and KPIs are scams. Human language and psychology are both vague and malleable. The kinds of people who are good at meeting OKRs aren't the kinds of people who can produce quality work. OKRs are mostly about lowering expectations prior to implementing and exaggerating results after implementing... It's mostly psychological work, a magic trick, not real productivity. The goal of this game is to sacrifice long term gains for short term gains; build a house of cards fast to boost your OKR scores and get promoted fast... Then let the next person who is assigned to the project take the blame for the collapse. People don't care about foundations... Only thing that matters is whose watch the tower falls on. People are literally that ignorant and superficial. It works every time.
keeptrying 2y ago
If you work in a big company, - the perception of hitting OKRs is more important than anything else - if you can enter into the OKR discussion early, then you can control it. - if you can, run the OKR process much to your gain :)
naasking 2y ago
Goodhart's law suggests that no fixed set of measures will suffice, but what about a dynamic or a set of complementary measures that periodically switch? Spend 3-6 months optimizing for X, then spend 3-6 months optimizing for some property complementary to X. Like having metrics that focus on new features, then bug fixes, then new features, etc. Or new features, bug fixes, refactoring/maintenance, new features, bug fixes, etc. Selecting the set of good and complementary metrics requires careful thought and experimentation, but it might prevent gaming over the long term because the complementary measures of the second phase should make up for deficiencies in the primary measures in the first phase. Anyone have any experience with this sort of thing?
0xbadcafebee 2y ago
OKRs, KPIs, etc are often challenging for orgs, teams, and individuals that are poorly trained. It's the same problem with Scrum: if the people are poorly trained, they will find it challenging, even counter-productive, to use them. Every company I have worked for has not trained their workers for OKRs, KPIs, Scrum, etc. (Well that's not true: Cisco paid for us to have two weeks of Scrum training because our stand-ups were 1.5 hrs long. That's the only reason I know how it's supposed to work) They hire you expecting you know all of that (though never verifying), and then they dump you in the deep end and don't give you the training you need to use it correctly. The end result is nobody uses it right, and the company suffers. And it's complex enough that a pithy clickbait blog post on HN isn't going to teach you how to do it right. Managers, execs: train your staff. You're only hurting yourself and the company by not doing so.
theptip 2y ago
Some good observations here but I disagree with the conclusion. > Shipping features from the roadmap is a chunk of our core job. It shouldn’t usually be in our OKRs. First of all, your roadmap shouldn’t be static. You should give teams flexibility to change it. When/why? When they see a better way of achieving the teams objective. Ideally you can set up your KRs to also be flexible WRT implementation. People loose sight of this, but it’s one of the two big value adds from OKRs. The second big one is legibility outside your team/org. OKRs are about making your goals and work easily understandable, because the alternatives don’t scale as well. So vis. the article, you should start with the question of what you want to make visible to the org, and make sure you craft your OKRs to highlight that part of the roadmap. Concrete example, I plan with two buckets: new features, and bug fixes/ops/quality. The customer for new features is users, and the org cares about this. You need OKRs to make your impact legible to your CEO, who (let’s be real) is not going to log into Jira and read the full backlog. Bug fixes and ops need to happen, and they should be groomed and prioritized ideally, but in the ideal world nobody outside of the owning team should see them. Internal tooling should be on the roadmap but not OKRs, unless you are in the red and your CEO wants to know that you are improving after, say, a business-impacting outage. So the roadmap is going to have a bunch of detail on the current delivery plans, sequencing, etc, but it’s downstream of your objectives. You should align your objectives with leadership first, then make your roadmap and propose KRs.
joegoober 2y ago
Context: I'm an engineering director at a medium-large tech company. What both the article and the comments here show is that for most users of OKRs, they don't actually consider the Objective and the Key results to be different. If you consider a key result without considering the objective, then yes, you'll just move a number and nothing more. If you actually try to deliver an objective, and use your KRs to see if you have made progress towards that objective you'll do much better. That said, I've had to fight many times in my career, even with senior-level product managers, to think about OKRs that way. I ideally ask the engineers that report up to me to care first and mostly about the Objectives their team has taken on, and to care about the KRs second. That leads people to do the right work far more often than having them try to move a specific numerical value above all else.
gdubs 2y ago
The problem with OKRs and just about every corporate process is that something that began as a good idea gets diluted over time to the point of being nearly meaningless at best and super distracting at worst. The reality — having worked in big tech for almost a decade — is that people just take what they already wanted to do and frame it as an OKR. You see this happen with Agile processes as well: "as a user I would like [to use this feature the PM is excited about]"
- jayd16 2y ago
  Was it ever a good idea? Even when I bend over backwards to treat the process as earnestly as possible, it feels like silly dance, corporate kabuki.
  - gdubs 2y ago
    Honestly? I don't know! The central idea of "measure what matters" is good if you actually do the meaningful soul-searching involved. But most good ideas can turn into just a lot of rules and process to follow over time.
PaulHoule 2y ago
As a software dev the only KPI I want my team to have is the build time. There was that time at one place where it seemed I was the only person who actually put tickets in the ticket system (the product manager never did.) I was told that every ticket I put in had to have clear value for the consumer and they complained about a ticket to speed up the build. I told them "it has value for the customer because the customer wants the product and could have had it six months ago if we 5x'ed the build speed a year ago"
epolanski 2y ago
It should be noted that as of today no single study on the OKRs demonstrates any value in them. Consensus among scholars is that there's no evidence Google thrived thanks to OKRs, in fact it could be said that it thrived despite OKRs.
Kurtcheng 2y ago
[dead]
dogman144 2y ago
I’ve led teams and then I’ve worked as an engineer, so I feel I understand both sides but have an informed take on how things go when OKRs show up despite/due to that. I get as a leader that some form of goal orientation and niche engineering speak translation into outcomes must occur. But, for every 1 leader who can do this well, there are 99 who can’t. For every 1/2 leaders who can do this faithfully, there are 99.5 who don’t care much beyond building fiefdoms or just plain don’t know how to do it in practice - the ex-consultant PM, the manager not the leader, the PM who holds zero authority over a team of skilled ICs, and so on. Also, as an engineer, I have OKRs, I have ops, and I have the random stuff that shows up that blows a hole in my week to week plans. A good PM maybe can reduce this, but again see above. And: what am I measured on for my hearth and home paychecks: Answer - OKRs. So, in practice, when OKRs show up, I believe earnest big picture effort (which people love going to startups for, I think), goes out the window overall because of the above. You’ll only get people hitting OKRs, “hitting OKRs” has so much absurd flex in it because again see above, and so you best hope you have the 1 of 100 PMs that know how to do that well or else people start doing the silly dances engineers leave companies over.
- maayank 2y ago
  I’ve had the same experience, both as IC and a manager. It’s a nice framework, just not for human organizations (KPI for next framework: result in less “no true Scotsman” replies whenever a post details why the framework sucks in their organization)
curious_cat_163 2y ago
> Marketing is closer to project work, while Engineering (at places like Honeycomb) is product work. Projects like Marketing campaigns fit within a quarter or two, while product work is an ongoing rhythm of updates. I am from the engineering side of things but this does not seem right about marketing... Also, the examples of OKRs for engineering in the article seem somewhat contrived. I am sure some organizations/teams have OKRs like "ship the roadmap" but to say that is what all of them look like (everywhere!) is generalizing too far. Like, everything in life, there is probably a balance: Between thinking in the near-term vs. thinking about the long-term. Between thinking what the ICs on the front-line think is most important vs. what the "middle-management" thinks will move the numbers on metrics that the execs care about. A well-run planning process will result in the right balance being struck. And that IMHO is a rare thing: a well-run planning process, i.e. My $0.02.
- jklinger410 2y ago
  > I am from the engineering side of things but this does not seem right about marketing... I am from the marketing side of things and this seems exactly right about marketing. But I'm not sure what makes you say this because you did not elaborate.
  - curious_cat_163 2y ago
    Hey! Just caught up to replies. There is project-oriented engineering work that lasts for some arbitrary near-term period as well (2 week scrums, or 6 week long cycles in the shape-up world) -- but there is some deep strategic thought given to overarching design, etc. that I think the original post was talking about. Those don't fit neatly into OKRs and I buy that. I would think that some marketing work is project-like but there have to be things that are more strategic in nature... Things that have impact beyond a quarterly campaign, etc. That's where I was coming from. Feel free to disagree. Would love to get your take. :)
tetha 2y ago
This article is interesting, because we as a team are currently going through a strange phase, which is similar to KPIs and OKRs, but in a better way than previous companies did it. Some internal discussions and skewed perceptions of our team are now causing our team are currently causing our team to make our work and our infrastructure more tractable and more quantifiable. For example, we've started to track time spent for internal customers and different topics team-internally and aggregate those on the team-level. Or we've started to generate information about resource consumption of different products. And this has led to interesting results. At a workers level, our director and the board is very clear that they want to continue this data to be collected without interference or skew. If you work in an area, you track it in that area - don't try to protect anyone. Track time as you spend it. Track resources as spent. On a leadership level, this has however resulted in a fairly interesting tone. Suddenly you have a CEO saying "Alright, so my very expensive team is spending that much time on this area you claim to be somewhat simple? Make that number go down significantly this year. Hire if and as necessary". Or "I dislike this amount of outages, but if you say we need better data there, make it so" It's also a very much data driven management style. But you don't have magical bespoke numbers fall from the sky one day and you need to make sense of them and integrate them into your normal work. It is data about our work we collect along the way, and we're trying to change our tasks and our decision making to change our work to change the metrics into a better direction.
shusson 2y ago
This is another way to determine if a company is a "start-up"! If you work at a company that has OKRs, it's no longer a start-up or it's time to bail because said start-up is about to fail.
- dimgl 2y ago
  > because said start-up is about to fail. How come?
doawoo 2y ago
My favorite part of the year is when everyone needs to re-write their OKRs/Goals before review season, because we ended up have to do actual work that related to the end-user product, and in general most humans cannot predict the future.
awkward 2y ago
There's a big gap between the big list "what we have to do" and being able to furnish a brief summary that both focuses the team's attention correctly and shows higher leadership that what's happening is meaningful. The problem with OKRs is that they're another metric, and get gamed and talked about as such. The soft skill of being able to effectively summarize and express the meaning behind list of tasks isn't necessarily going to
jjslocum3 2y ago
Are people still talking about OKRs? Dang that's so '00s
crest 2y ago
I read it as "hitting orcs vs. doing you job". Maybe I should read less war reports.
graycat 2y ago
My experience: (1) Do bang up, really good word, save/make major improvements in the work of the organization. (2) Thus, fully unintentionally scare the management (afraid of being upstaged, shown up) all the way to the top. (3) Have the scared management arrange to fire you. Response: Find a market need can meet with own resources (e.g., think of a new Web site, get some computing equipment, write the code, go live on the Internet, get some publicity, users, and ad revenue, entertain buyout offers), be the first level worker and also the manager and owner. Basically, if get good revenue, can't get fired, e.g., can't lose your job. Experience examples: (1) In high school plane geometry, in class mostly slept, refused to admit doing any of the assigned (too simple) homework, but there were some more difficult exercises in the back of the book so made sure I did ALL of them. One took me Friday to Sunday evening, and on Monday in class the teacher had the class work on an easy exercise with the same figure, so for the only time I participated said "There's an exercise in the back with the same figure ...". For about 20 minutes the class and teacher struggled with increasing frustration but no success. Since I didn't want to be accused of wasting the class time, said "Why don't we ...", and the teacher interrupted, spoke over me, wouldn't let me finish the suggestion, and said with anger "You knew how to do it all the time." Of course, wouldn't say anything otherwise. Point: The main goal was to learn some plane geometry which I was doing apparently quite well but got anger instead of praise. (2) At the end of the class, there was a State achievement test. The last problem was "What is the first step in using construction to inscribe a square in a semi-circle." I didn't get it so after the test kept working on it until I did. My solution was first to construct something easier: Construct a square of whatever size, circumscribe a semi-circle, thus, have a figure similar to the desired one but of the wrong size, construct a 4th proportional to get the needed length in the given semi-circle. Constructing the second figure looked novel, not from the course, so after school asked the teacher if that was okay? She said "No, but why are you working on that?" Later I discovered that I'd reinvented similitude, actually taught in some more advanced material. Point: The main goal, even beyond what was in the class and book, was to make progress, even invent, in the subject. Again the from the teacher I got contempt instead of praise. (3) Working in a time-sharing company, my job was the math library. The FFT (Fast Fourier transform) was a hot topic, and I got fairly deep into it, along with the related Blackman-Tukey power spectral estimation, dropping the assumption of number of samples a power of 2, etc. The manager's remark was "You tend to pick the bones clean" and fired me. Point: The main goal was to please the customers, and having a better software library in the FFT hot topic was a part of that. So, from doing admittedly exceptionally good work, I got fired instead of promoted or even keeping my job. (3) After the FFT work, got hired as helper of users of a university computer center. As a tool for teaching some statistics, a prof had written a main program to call the statistics routines in the IBM SSP (scientific subroutine package). In testing he found that two of the routine were slow (for integer n points of input ran in time proportional to n^2) and for polynomial fitting (via a method that led to the notoriously ill conditioned Hilbert matrix) gave numerically inaccurate results. So, for the two n^2 cases, I found tricky ways to use the n(log(n)) heap sort without using more storage (did some tricky overlay, reuse of the storage in the passed parameters) and for the polynomial case used some Forsythe and Moler work to get better numerical accuracy. To do this, some days I worked late, and the head of the computer center said critically I hear that you have been working all hours of the day and night" and fired me. The Dean of the business school kept me on to teach courses in computer science. Point: Again the main goal was to have better software, better than the prof wrote, to have a better computer center, and my work, improving on what the prof and IBM had done, was exceptionally good work, but I got fired instead of praised. (4) At FedEx, the BOD was seriously* (funding at stake) concerned about scheduling the fleet. At a meeting to see how to respond, no one had any ideas, so I said I'd solve it. I had some ideas, wrote the code, ran the code, pleased the BOD, saved the funding and the company, and got an angry manager who tried to get me fired. The founder, COB, CEO got me a Senior VP as a new manager; I did some better work on scheduling the fleet, and the VP's response was "there no money in the budget for you", and wanted me fired. The promised stock was very late, and I went for a Ph.D. in such applied math. Later FedEx worked with a prof and a grad student and implemented, as a Ph.D. dissertation, my scheduling idea (0-1 integer linear programming set covering). While reporting to the VP, I pleased again the BOD and saved the company. Point: So, I had saved the company twice, and the new scheduling proposal in effect directed a dissertation, i.e., it was good work. But the two managers both tried to fire me and there was no stock and no money in the budget. (5) Later in a major AI project, there was a big problem with the design and code. The team had a crude solution in mind, that would take weeks of coding and at best would not be very good. So, I had an idea, got a pizza, worked all night, and had running code for a nice solution. I got an award from my manager, but from the rest of the management chain soon I was fired. Point: I'd done novel, good work, saved the AI project, but got fired. There are a few more examples. Old quips: "No good deed goes unpunished." "The nail that sticks up gets hammered down." "Don't rock the boat."

369 points by zdw 2y ago

gbin 2y ago

"Let OKRs highlight a special focus. Don’t try to cram everything you do into them" Then link compensation to OKRs then everybody just focuses on bending the reality to meet the letter of the OKR and nobody is interested in doing their job. After the "oh shit" moment, we cram everything we do into them. Then everybody ignores OKRs.

osmsucks 2y ago
The most insulting case is that of the retroactively-adjusted OKR wording so that you can always meet 0.7+ scores.
szundi 2y ago
I remember when reading about Intel and OKRs in every management execution book. I thought that's the time to sell the stock.
- Aromasin 2y ago
  They brought them back during my recent tenure at Intel, just after Pat joined. I was an application engineer, so my purpose was to debug customer support issues on our chips, filter between the customer and the engineering staff, write some User Guides and helpful collateral to developers, and open tickets with engineering when problems were severe enough. My OKRs could have just been "close tickets" and I think that would have been the best ROI for the company - there was never a point in my career where I didn't have tickets that needed working on that were halting multiple millions in revenue, but somehow my time was always spent having to work on other things. Management insisted on filling my OKRs with low-value 1:N activities - spending time on the forum (full-time forum people were paid to do that), helping sales with technical discussions with customers (field engineers were paid to do that), creating demos/PoCs for marketing (technical marketing engineerings were paid to do that), or being part of one "centre of excellence" or another wasting time in meetings with non-technical people talking about how we were all going to tackle problems when the reality was that no one in the team had the time, talent, or political capital to do any of the things we spent hours discussing. To me, OKRs seem effective for the workforce in the same way scout badges are effective for children to learn skills - good for those who otherwise would do nothing. The issue is, for intrinsically motivated people who are incredibly specialised in a largely reactive role they are a distraction at best, and when used for quarterly and yearly performance tracking, a detriment to the core role at worst.
  - PaulHoule 2y ago
    I worked at a startup where the main problems I saw were: (1) It was impossible for anyone to enforce anything. Our genius business development guy couldn't get our head data scientist to share data files with customers (say Big 5 accounting firms) in a way they felt were safe. I couldn't get the data scientists to use standardized versions of Python. (Docker just accelerated their ability to find defective Pythons, such as one with Hungarian as the standard charset) The engineering manager would tell me "we use monads for error handling in Scala" and "we do code reviews" but I don't believe the latter because the first certainly wasn't true. (2) We were developing core technology and developing solutions for various customers. There was a lot of zigging and zagging and spoiled work in progress. I felt like the customer contact was helping us understand the requirements for the core so I'm not complaining about that. Our management practices should have been focused 100% on squaring that circle. The VCs believed in our vision and our BD genius (I did!) but they knew we were badly managed and brought in a stream of consultants some of whom were helpful and some who weren't. The worst was the consultant who came in and forced us all to write OKRs which took two weeks against the core and solution and development work that did matter for the business. My feeling was that my job was to pull for the team wherever it needed it and it wasn't my business to set goals that weren't fundamentally grounded in the needs of the team. I had enough work to do that I didn't need to add a single task that wasn't on that critical path. Particularly customer requirements could change faster than the OKR cycle, we needed practices that worked at the speed of our business. I was anxious that when review time came along I'd find that, out of 20 OKRs, I would nail 5 of them, totally fail at 5 of them and the other 10 would be in between. At review time whether this is success failure would depend on politics and ability to navigate politics. That genius BD would deservedly get a good review, a really good coder or data sci may or may not. People with high and unmitigated narcissism are privileged by systems like stack ranking and OKR because they are focused on presentation of self in ways that average people aren't.

friendzis 2y ago

Goodhart's law is an adage often stated as, "When a measure becomes a target, it ceases to be a good measure".

blueboo 2y ago
I prefer Campbell’s Law — the more a metric is used in social decision-making, the more likely it is to be manipulated. You’ve stated the widely-accepted formulation of Goodhart’s, but it can be interesting to note Charles Goodhart’s original statement was that “any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes.” (The implication is people doubly go wrong presuming the regularity’s existence and placing pressure on it!)
- friendzis 2y ago
  I'm being humorous here. I kinda disagree with tour takeaway. I have expanded on this idea elsewhere in this thread, however, the main point is that a measure is a byproduct of an existing process. Making the measure a target, i.e. process output, changes (possibly inadvertently) the process itself. It does not matter if the regularity truly existed or was wrongly presumed to exist, as putting pressure on it invalidates the causal relationship it had before.
  - zmgsabst 2y ago
    I’m not sure I’ve heard it summarized that way before: that good process causes good metrics, but good metrics don’t cause good process. People are indeed prone to affirming the consequent. https://en.wikipedia.org/wiki/Affirming_the_consequent https://en.wikipedia.org/wiki/Affirming_the_consequent

mrayycombi 2y ago

https://blog.appliedcomputing.io/p/okrs-are-bullshit https://blog.appliedcomputing.io/p/okrs-are-bullshit

padolsey 2y ago

Now having worked in a few smaller teams since my time at FB, I realize how marvellous it is to not have to worry about OKRs, performance reviews and all that malarkey. It was so draining to run yourself as a mini PR/brand within one's team (/one's department) and market oneself (one's team) to your manager (/your company). So much mental bandwidth was spent. I also, from a systems-thinking POV, just fundamentally reject the value in OKRs as a meaningful proxy for the value you (/your team) are producing unless you are an entirely mechanistic function. By mechanistic I mean you have a clear discrete Input<>Output expectation. Every single time an element of human activity is reduced to a metric, you lose something, and if you do it enough times, you've effectively produced a metric that is completely distinct from the thing you intended on measuring in the first place. For example: let's say you're in the suicide prevention team at FB, and your OKR is 'number of suicides averted'. Well, that sounds good, but unbeknownst to you, perverse incentives have kicked in and invisibly imbued your metric-chasing experiments a dark undertone. A new risk model might start flagging more content as potentially suicidal to boost numbers, leading to over-intervention that could traumatize users or waste resources. Or perhaps the surface we use to measure success, a UX or user activity metric, might actually be uncorrelated with crisis aversion or... and this is where it hits: the thing that's instrumental in crises is social media itself. The metric becomes a game, and it games _you_. Your team thinks you're doing X, but you're really doing Y. Because you're disattached from the real problem and comforted by incredibly lossy proxies.

friendzis 2y ago
I have semi-humorously dropped a comment defining Goodhart's law. The problem you are describing is nothing else but Goodhart's law in action: A measure stops being a good measure, i.e. be a proxy for something, once there are objectives attached to it. In other words, attaching goals to a metric invalidates previous causal relationship. That's neither bad, not good. It's a property of goal setting. The problematic part is still treating the measure as if it had causal relationship to something when that relationship has already been invalidated. In your example, number of suicides ceases to be comparable between pre and post OKR timeframes, however if you look closely, this particular goal is based on a metric the underlying OKR targets invalidate. Yes, sometimes you get these weird tautologies where you have to change the whole framework/process to make something both targetable and measurable simultaneously, potentially losing comparability to past data.

lifeisstillgood 2y ago

OKRs are just another word for priority. You have an infinite amount of “could do” and a limited amount of “must do”, and “must” is very rarely clear a year or more out in any measureable sense So eventually we come to “support the overriding mission”, and record everything we do, and we can retroactively look to see who contributed most. It will never be who you think Plus that part is so politically driven you may as well say “elites will reward elites, those with skills will leave if they can find somewhere”

lifeisstillgood 2y ago
Just a thought but if “elites reward elites” is a truism, then only when you spread enough wealth around that elites become so common that democracy is the only viable means for elites to reward other elites…

qprofyeh 2y ago

As an engineer I have nothing against OKRs. But it's often the day-to-day management (EM or PM) who tend to override the team's OKRs for upper management to prioritize something ad-hoc & out of scope they agreeably said Yes to.

Cthulhu_ 2y ago
And that's fine I think, it's why a lot of companies are using one or more of the agile methodologies. But if that's combined with OKRs then said OKRs need to be adjusted, and it'll be down to the manager to pay that cost. We use SAFe at my current job (please don't look at the website, if you thought the "scrum" infographic was too big already lol); we set quarterly goals and objectives, usually don't meet them because Reasons, but if there is an incident or change that warrants changing those goals it's a Big Thing and we basically redo the planning sessions (two days or so); it's a big disruption and it's costly so it's not done lightly. We've only done that once in the past two and a half years or so.
- wesselbindt 2y ago
  > it's a big disruption and it's costly so it's not done lightly Isn't this the very definition of not being agile?
  - robertlagrant 2y ago
    It's what the consulting class invented to lift the power that agile places in individual teams back up to management.
xtracto 2y ago
Engineering OKR: Make system like more stable and with less bugs. Product: Here are these 1567 story points for this new sprint with new product development stuff which is urgent and should be completed in 2 weeks.

ozim 2y ago

I always like to observe people who want quick results reading about agile or OKRs or KPIs and then handsomely shooting themselves into foot. Other fun thing is having management mandate those things and people who don’t have time to understand all that stuff implement it. Worst one is having ambitious young people thinking if they push for implementing those things they will be „real professionals” - that is how dev teams go to crawl enforcing all BS rules and product teams bikeshedding OKRs instead of delivering stuff.

throwawaysleep 2y ago
The need for “impact” in performance evaluations is also the cause of a lot of bike shedding. I had a meeting the other day where my manager sent our team and told us to “be visible so we have something to report for year end about broader impact.” We basically disrupted a meeting with poorly thought out commentary to put “cross pollination” on our self summaries.
ibejoeb 2y ago
>ambitious young people thinking if they push for implementing those things they will be „real professionals” This is a real problem. It can destroy a successful operation. I don't specifically want to blame "young" or any other particular attribute, but it's common in that ambitious corporate type. Hiring managers, especially in startups, should really think about a newcomer's background. If someone comes from services where the name of the game is billable hours, it is going to be ingrained that there are processes that exist to justify those hours. That fails when your client is your company.

praptak 2y ago

Duh, obviously I want "shipping the roadmap" in the OKRs. OKRs should capture everything you plan to do, otherwise what's the point? Obviously I don't want the whole roadmap, just the part we commited to. You probably also don't want only the roadmap, for obvious reasons. There's never enough time to do everything that's planned or necessary and OKRs should be the tool that lets you resolve the conflicts. Ship feature X or fix the infrastructure? "X is in OKRs, let's work on X". "X is not in OKRs and we have KR to get Y% success on autodeployments, let's fix infra". What I definitely don't want is "do OKRs and also do roadmap". The only things that should not be in the OKRs are ones where prioritization is trivial (like "fix critical outages").

SteveVeilStream 2y ago

The reality of OKRs (or Rockefeller Habits or any other company wide framework for establishing priorities and goals,) is that by going through the exercise of trying to create them across the company, you often discover that there are meaningful disconnects in how teams are prioritizing work or how teams function vs how other stakeholders in the company believe those teams are operating. The real value comes from diving deeper into understanding those things. However, companies often view those as annoyances and find a way to plow the goals through while completely missing that learning opportunity.

AndrewSChapman 2y ago
This. High level OKRs should be set by the company to steer the ship, and engineering OKRs should align with the company OKRs. Thus, the roadmap is defined by the OKRs - I believe that's the whole point.
- WXLCKNO 2y ago
  It just takes so many cycles to get to a point where everyone in the company is on-boarded to OKRs properly and by then people are burnt out on them, going through the motions without seeing the value, at least from the bottom up.
zoul 2y ago
Yes! Instead of data-driven management, I believe in conversation-driven management. Frameworks such as OKRs are a way to spark helpful conversations.
- maayank 2y ago
  Or, you could have these conversations without OKRs?
ghaff 2y ago
Large organizations also just have to be more process-driven and formal. And it's fine if you don't like that. At a former employer, I was much happier when it was a medium-sized enterprise than when it grew by almost 10x. A lot of things had to change that weren't really to my liking (or skill set) but they had to.

justinl33 2y ago

I strongly believe that the addition of every metric brings with it an associated productivity tax in the form of: 1. time spent doing things that exploit this metric 2. time spent purely documenting/surfacing this metric on your ‘brand’

michidk 2y ago

Yes, exactly this! We are actually spending soo much time deriving, thinking, formulating & refining OKRs from roadmap items that we could just declare as simple "Goals". We could get so much shit done during that time. Most of the time as the quarter goes on, we then scrap those OKRs anyway because we didn't manage to do them or they were too specific and requirements changed. I always had the feeling that what we are doing is bullshit. So great to finally hear it from someone else. I wonder how many engineering companies actually use OKRs though.

rednafi 2y ago
I call it planning palooza. It keeps a ton of people employed though.

brcmthrowaway 2y ago

What does OpenAI or Anthropic use?

zelphirkalt 2y ago

In my experience managemant roles set the OKRs in a closed circle, without feedback from technical employees and then things like reliable infrastructure are underestimated or forgotten. Once OKRs are set, they are set in stone, because management roles are too busy to come together again and additionally include engineering roles in the decision making process. Instead just put more pressure on engineering. This kind of thing easily destroys great team dynamic and makes people change from getting work done to meeting target metrics, even if they only game them. This can lead to good and essential people quitting and the downfall of the company.

robertlagrant 2y ago
I think this is an attribution error. The issues you list are a function of management style, not of OKRs. Any management technique is very dependent on management not behaving pathologically.
- marcosdumay 2y ago
  Nah. What gets excluded is a function of management style. But that most important things are excluded is an inherent feature of OKRs.

rednafi 2y ago

If I could give one piece of advice to my early-career self, it’d be this: do more "visible" work rather than "good" work. The former gets you promoted, while the latter leaves you stuck as a senior engineer forever. For me, that ship sailed a while ago, and I’m sorta happy being stuck as a senior engineer. That puts me in a good spot to say OKRs are bullshit.

lrog 2y ago
With what other role / direction would you be satisfied instead of being SE? Going up in the IC ladder (lead, staff, etc.) or management? What disadvantages do you see settling at SE?
- rednafi 2y ago
  Staff is the natural progression for people who want to take the next step but don’t want direct reports. Each company has its own definition of a staff engineer's responsibilities. I’ve seen people move back to SE after burning out from all the meetings. In some places, staff engineers rarely code and are essentially glorified team leads. But there are definitely companies where Staff engineers get to do some awesome work and there's a proper delineation between a Staff and a TL. I'm yet to work in a company like that yet.
zeroonetwothree 2y ago
Really depends on your priorities. For me I'd rather do 'good' work (or 'interesting' work to me) since I don't care about minmaxing my comp.
- rednafi 2y ago
  Same and got stuck in the eternal loop of SE.
- azemetre 2y ago
  Also if you are going to job hop in less than 3 years there's much less reason to play the corpo game.

doppp 2y ago

I still chuckle when I recall this tweet, "OKRs were actually a psyop from Google to slow down potential early stage competitors" [1]. [1] https://x.com/benwbear/status/1543056694330003456 https://x.com/benwbear/status/1543056694330003456

PaulHoule 2y ago
That's what I told the managers at one startup when they brought in a consultant to introduce OKRs.
marcosdumay 2y ago
I imagine React was the Facebook version of this. There's a famous theory that Gantt charts were actually created to keep decision-makers on the dark while Gantt could have some freedom to manage in a way that worked instead of letting they dictate some way that doesn't. Taylorism was, of course, something that Taylor never believed in. That's no secret, as he spoke against it several times. Most personal "ism"s are like that. (What he actually preached was something very different.) It's almost completely settled that current form "agile" was created by people that sold books and courses, and had not interest nor any professional experience in making teams work better. And I guess the list goes on, but I don't remember more. But surprisingly, the guy that invented stack-ranking apparently believed it was really great.
wavemode 2y ago
Funny - I used to make this same joke about Kubernetes.

DanielHB 2y ago

I remember reading an anecdote about this stuff from the book The Essential Deming by W. Edwards Deming the "father of the quality movement and was hugely influential in post-WWII Japan". It talked about some company moving oil around in barges, the setup was unprofitable and a new manager was brought up to fix it. He created metrics of the business, but didn't put any goals or goalposts for the barge crews and other managers in the company. All he did was simply print the metrics and glue them on every barge of the fleet weekly. Soon the whole project was massively profitable. Apparently the captains of the barges would compete with each other to see who could save more money, without any penalties for the low performing nor any rewards for the high performing barges. One thing that was very surprising is that the barges were given freedom to choose where to source materials and, more importantly, the fuel. Before the metrics the captains would pick whatever was closest no matter the prices, after the metrics the captains would, on their own, try to source fuel from the cheapest place that they could. No amount of central planning could have been as optimal as the prices fluctuated a lot from day to day, so whenever a captain saw a good deal he would re-fuel. It turns out that empowered people want to do a good job and want to save money.

liontwist 2y ago
I think business people understand the value of setting high level goals and giving autonomy to accomplish them. It’s a good sign if your job works this way. Unfortunately this tends to mostly be applied at the VP level. Engineers are modeled as expensive pieces of an equipment to optimize and derisk.
- DanielHB 2y ago
  > I think business people understand the value of setting high level goals and giving autonomy to accomplish them. I think a lot of business don't, at least on the lowest levels of the org chart.
chasd00 2y ago
> It turns out that empowered people want to do a good job and want to save money. You have to be careful here. In your example those captains didn’t really care about their job they cared about getting the high score. Metrics, KPIs, etc work but only when they’re setup perfectly aligned with your actual business goals. Measure/score the wrong thing and you’ll get nowhere. For example, what if the metric posted was distance traveled by a barge. You’d have captains taking the longest routes possible just to get the high score instead of shipping the most product per unit time which is what the manager would have intended.

jtbetz22 2y ago

This post reflects an insidious anti pattern in the practice of setting OKRs: "shipping the roadmap" is not the objective, it is a means to achieving some other underlying objective. With a well written objective / key result (ex: "grow DAU by 30%"), you can abandon your entire roadmap two weeks into the quarter and still hit your OKRs. They enable you to respond to new information and lessons learned, rather than locking the whole team into a rigid plan for the entire quarter.

steveBK123 2y ago

I've always worked in a non-tech where our customers are internal. They have unfortunately read too many SRE/Phoenix Project/Big Tech Management Papers and so OKRs was one thing shoved down our throats. What I've found is that they've hired a slew of Product Mangers (tm) who mostly just sit in between devs & users, without coordinating cross team, actually writing specs/Jiras/roadmaps, etc. So each teams devs wrote their own OKRs, in ignorance of what users (who might be other tech teams) might actually want or what other teams OKRs are. For example, to use an analogy one team builds the foundation and decides their OKR is to use 15% less concrete next year. The other team builds frames and decides their OKR is to make the average building 15% taller next year. If any of them talked to actual final customers, they'd have found out the customers actually desire the buildings to be more robust to storm winds.

m463 2y ago
okr: reduce parts count me: Tesla,I want a car with turn signal and drive selector stalks!
- Schiendelman 2y ago
  Has the new UX bothered you when using it? I got used to it in a day and it seems fine.
  - m463 2y ago
    how has quickly reversing to get a parking spot in moving traffic worked for you?
    - steveBK123 2y ago
      You see, in the new economy you don't even needs stalks! I simply hit this Autopark button and then my car alternates between inching back & forth to sharply jerking the wheel every which way, and then lands itself in the spot. All while taking 3x longer than a competent human parallel parker and with heart stopping near-misses of hitting the surround parked cards. Oh and curbs your rims 20% of the time. Oh and as the human driver you are still responsible to monitor for passing pedestrians and bikers. If it crashes it's because you weren't monitoring it closely enough. And if you hit the brakes to stop it, you are a wimp who doesn't trust the car which totally would have gotten it right if you let it.

dent9876543 2y ago

The problem is that OKRs are divorced from the “go do this piece of work” instruction, and so, just like code comments, they quickly become out of date or are outright ignored. Because of that, the prescription about SMART and focus on delivery is simply wasted effort. At best a duplication. The good part about OKRs is (/should be) that it forces an alignment conversation between teams and amongst managers. And the performance discussion with manager is often useful and sometimes revealing. More often both focus on metrics, losing the last opportunity to extract value from the concept.

dakiol 2y ago

Am I the only one who doesn’t care about OKRs or whatever companies are following nowadays? I tend to work around 2-3 years per company. Get a salary bump when switching. My first year is rather slow/smooth because “I’ve been here for less than a year!”. My second year is more interesting and I do take it as “real” work. My third year I couldn’t care less since I’m already looking for something else. I couldn’t care less about goals or OKRs. I get paid, I solve whatever problems the business has (whether they make sense or not) and then I just leave.

kubb 2y ago
This is the way. But I’m unlucky to have been locked into a small job market, so I’m stuck in a local maximum. Won’t be moving to the US anytime soon with Trump’s immigration policies.
nine_zeros 2y ago
This is the right approach. As an individual engineer, you are not paid enough to care about business problems and propose your own solutions and timelines. You are also not given organizational authority, budgets, or agency beyond your line of work. You literally haven't been given the tools to own metrics and OKRs. And moving those metrics and OKRs doesn't get you more money. So why would you care? You sound rational to me.
- prh8 2y ago
  And even if/when you are paid well, you probably aren't given any meaningful ability to do the things necessary for those business problems. Corporate inertia is strong.
- jensensbutton 2y ago
  > And moving those metrics and OKRs doesn't get you more money. Because you are already being paid to move those metrics and OKRs. Not doing so means you're not actually doing your job and, in a well managed company (which are admittedly few and far between), will be rightfully fired and replaced by someone who does.
2y ago

crowcroft 2y ago

I'm convinced there is no 'good' way to set goals/OKRs etc. in big companies. Orgs should set goals though, but the problem is when you spend too much time doing it. If top level management set company OKRs, and then cascade them down with every department and sub department then setting and aligning mini OKRs to the big ones you end up with a months long planning cycle which by the time you finish, you need to restart for the next year. A good heuristic is that no team should ever end up in a situation where they spend more time debating how a task should be prioritized than the amount of time the task takes to do.

indymike 2y ago

As long as the metrics attached to an OKR actaully a)make sense and b)are causally related to the OKR, then they can work. Where ORKs go off the rail is trying to set a goal for something you just can't manage.

jongjong 2y ago

OKRs and KPIs are scams. Human language and psychology are both vague and malleable. The kinds of people who are good at meeting OKRs aren't the kinds of people who can produce quality work. OKRs are mostly about lowering expectations prior to implementing and exaggerating results after implementing... It's mostly psychological work, a magic trick, not real productivity. The goal of this game is to sacrifice long term gains for short term gains; build a house of cards fast to boost your OKR scores and get promoted fast... Then let the next person who is assigned to the project take the blame for the collapse. People don't care about foundations... Only thing that matters is whose watch the tower falls on. People are literally that ignorant and superficial. It works every time.

keeptrying 2y ago

If you work in a big company, - the perception of hitting OKRs is more important than anything else - if you can enter into the OKR discussion early, then you can control it. - if you can, run the OKR process much to your gain :)

naasking 2y ago

Goodhart's law suggests that no fixed set of measures will suffice, but what about a dynamic or a set of complementary measures that periodically switch? Spend 3-6 months optimizing for X, then spend 3-6 months optimizing for some property complementary to X. Like having metrics that focus on new features, then bug fixes, then new features, etc. Or new features, bug fixes, refactoring/maintenance, new features, bug fixes, etc. Selecting the set of good and complementary metrics requires careful thought and experimentation, but it might prevent gaming over the long term because the complementary measures of the second phase should make up for deficiencies in the primary measures in the first phase. Anyone have any experience with this sort of thing?

0xbadcafebee 2y ago

OKRs, KPIs, etc are often challenging for orgs, teams, and individuals that are poorly trained. It's the same problem with Scrum: if the people are poorly trained, they will find it challenging, even counter-productive, to use them. Every company I have worked for has not trained their workers for OKRs, KPIs, Scrum, etc. (Well that's not true: Cisco paid for us to have two weeks of Scrum training because our stand-ups were 1.5 hrs long. That's the only reason I know how it's supposed to work) They hire you expecting you know all of that (though never verifying), and then they dump you in the deep end and don't give you the training you need to use it correctly. The end result is nobody uses it right, and the company suffers. And it's complex enough that a pithy clickbait blog post on HN isn't going to teach you how to do it right. Managers, execs: train your staff. You're only hurting yourself and the company by not doing so.

theptip 2y ago

Some good observations here but I disagree with the conclusion. > Shipping features from the roadmap is a chunk of our core job. It shouldn’t usually be in our OKRs. First of all, your roadmap shouldn’t be static. You should give teams flexibility to change it. When/why? When they see a better way of achieving the teams objective. Ideally you can set up your KRs to also be flexible WRT implementation. People loose sight of this, but it’s one of the two big value adds from OKRs. The second big one is legibility outside your team/org. OKRs are about making your goals and work easily understandable, because the alternatives don’t scale as well. So vis. the article, you should start with the question of what you want to make visible to the org, and make sure you craft your OKRs to highlight that part of the roadmap. Concrete example, I plan with two buckets: new features, and bug fixes/ops/quality. The customer for new features is users, and the org cares about this. You need OKRs to make your impact legible to your CEO, who (let’s be real) is not going to log into Jira and read the full backlog. Bug fixes and ops need to happen, and they should be groomed and prioritized ideally, but in the ideal world nobody outside of the owning team should see them. Internal tooling should be on the roadmap but not OKRs, unless you are in the red and your CEO wants to know that you are improving after, say, a business-impacting outage. So the roadmap is going to have a bunch of detail on the current delivery plans, sequencing, etc, but it’s downstream of your objectives. You should align your objectives with leadership first, then make your roadmap and propose KRs.

joegoober 2y ago

Context: I'm an engineering director at a medium-large tech company. What both the article and the comments here show is that for most users of OKRs, they don't actually consider the Objective and the Key results to be different. If you consider a key result without considering the objective, then yes, you'll just move a number and nothing more. If you actually try to deliver an objective, and use your KRs to see if you have made progress towards that objective you'll do much better. That said, I've had to fight many times in my career, even with senior-level product managers, to think about OKRs that way. I ideally ask the engineers that report up to me to care first and mostly about the Objectives their team has taken on, and to care about the KRs second. That leads people to do the right work far more often than having them try to move a specific numerical value above all else.

gdubs 2y ago

The problem with OKRs and just about every corporate process is that something that began as a good idea gets diluted over time to the point of being nearly meaningless at best and super distracting at worst. The reality — having worked in big tech for almost a decade — is that people just take what they already wanted to do and frame it as an OKR. You see this happen with Agile processes as well: "as a user I would like [to use this feature the PM is excited about]"

jayd16 2y ago
Was it ever a good idea? Even when I bend over backwards to treat the process as earnestly as possible, it feels like silly dance, corporate kabuki.
- gdubs 2y ago
  Honestly? I don't know! The central idea of "measure what matters" is good if you actually do the meaningful soul-searching involved. But most good ideas can turn into just a lot of rules and process to follow over time.

PaulHoule 2y ago

As a software dev the only KPI I want my team to have is the build time. There was that time at one place where it seemed I was the only person who actually put tickets in the ticket system (the product manager never did.) I was told that every ticket I put in had to have clear value for the consumer and they complained about a ticket to speed up the build. I told them "it has value for the customer because the customer wants the product and could have had it six months ago if we 5x'ed the build speed a year ago"

epolanski 2y ago

It should be noted that as of today no single study on the OKRs demonstrates any value in them. Consensus among scholars is that there's no evidence Google thrived thanks to OKRs, in fact it could be said that it thrived despite OKRs.

Kurtcheng 2y ago

[dead]

dogman144 2y ago

I’ve led teams and then I’ve worked as an engineer, so I feel I understand both sides but have an informed take on how things go when OKRs show up despite/due to that. I get as a leader that some form of goal orientation and niche engineering speak translation into outcomes must occur. But, for every 1 leader who can do this well, there are 99 who can’t. For every 1/2 leaders who can do this faithfully, there are 99.5 who don’t care much beyond building fiefdoms or just plain don’t know how to do it in practice - the ex-consultant PM, the manager not the leader, the PM who holds zero authority over a team of skilled ICs, and so on. Also, as an engineer, I have OKRs, I have ops, and I have the random stuff that shows up that blows a hole in my week to week plans. A good PM maybe can reduce this, but again see above. And: what am I measured on for my hearth and home paychecks: Answer - OKRs. So, in practice, when OKRs show up, I believe earnest big picture effort (which people love going to startups for, I think), goes out the window overall because of the above. You’ll only get people hitting OKRs, “hitting OKRs” has so much absurd flex in it because again see above, and so you best hope you have the 1 of 100 PMs that know how to do that well or else people start doing the silly dances engineers leave companies over.

maayank 2y ago
I’ve had the same experience, both as IC and a manager. It’s a nice framework, just not for human organizations (KPI for next framework: result in less “no true Scotsman” replies whenever a post details why the framework sucks in their organization)

curious_cat_163 2y ago

> Marketing is closer to project work, while Engineering (at places like Honeycomb) is product work. Projects like Marketing campaigns fit within a quarter or two, while product work is an ongoing rhythm of updates. I am from the engineering side of things but this does not seem right about marketing... Also, the examples of OKRs for engineering in the article seem somewhat contrived. I am sure some organizations/teams have OKRs like "ship the roadmap" but to say that is what all of them look like (everywhere!) is generalizing too far. Like, everything in life, there is probably a balance: Between thinking in the near-term vs. thinking about the long-term. Between thinking what the ICs on the front-line think is most important vs. what the "middle-management" thinks will move the numbers on metrics that the execs care about. A well-run planning process will result in the right balance being struck. And that IMHO is a rare thing: a well-run planning process, i.e. My $0.02.

jklinger410 2y ago
> I am from the engineering side of things but this does not seem right about marketing... I am from the marketing side of things and this seems exactly right about marketing. But I'm not sure what makes you say this because you did not elaborate.
- curious_cat_163 2y ago
  Hey! Just caught up to replies. There is project-oriented engineering work that lasts for some arbitrary near-term period as well (2 week scrums, or 6 week long cycles in the shape-up world) -- but there is some deep strategic thought given to overarching design, etc. that I think the original post was talking about. Those don't fit neatly into OKRs and I buy that. I would think that some marketing work is project-like but there have to be things that are more strategic in nature... Things that have impact beyond a quarterly campaign, etc. That's where I was coming from. Feel free to disagree. Would love to get your take. :)

tetha 2y ago

This article is interesting, because we as a team are currently going through a strange phase, which is similar to KPIs and OKRs, but in a better way than previous companies did it. Some internal discussions and skewed perceptions of our team are now causing our team are currently causing our team to make our work and our infrastructure more tractable and more quantifiable. For example, we've started to track time spent for internal customers and different topics team-internally and aggregate those on the team-level. Or we've started to generate information about resource consumption of different products. And this has led to interesting results. At a workers level, our director and the board is very clear that they want to continue this data to be collected without interference or skew. If you work in an area, you track it in that area - don't try to protect anyone. Track time as you spend it. Track resources as spent. On a leadership level, this has however resulted in a fairly interesting tone. Suddenly you have a CEO saying "Alright, so my very expensive team is spending that much time on this area you claim to be somewhat simple? Make that number go down significantly this year. Hire if and as necessary". Or "I dislike this amount of outages, but if you say we need better data there, make it so" It's also a very much data driven management style. But you don't have magical bespoke numbers fall from the sky one day and you need to make sense of them and integrate them into your normal work. It is data about our work we collect along the way, and we're trying to change our tasks and our decision making to change our work to change the metrics into a better direction.

shusson 2y ago

This is another way to determine if a company is a "start-up"! If you work at a company that has OKRs, it's no longer a start-up or it's time to bail because said start-up is about to fail.

dimgl 2y ago
> because said start-up is about to fail. How come?

doawoo 2y ago

My favorite part of the year is when everyone needs to re-write their OKRs/Goals before review season, because we ended up have to do actual work that related to the end-user product, and in general most humans cannot predict the future.

awkward 2y ago

There's a big gap between the big list "what we have to do" and being able to furnish a brief summary that both focuses the team's attention correctly and shows higher leadership that what's happening is meaningful. The problem with OKRs is that they're another metric, and get gamed and talked about as such. The soft skill of being able to effectively summarize and express the meaning behind list of tasks isn't necessarily going to

jjslocum3 2y ago

Are people still talking about OKRs? Dang that's so '00s

crest 2y ago

I read it as "hitting orcs vs. doing you job". Maybe I should read less war reports.

graycat 2y ago

My experience: (1) Do bang up, really good word, save/make major improvements in the work of the organization. (2) Thus, fully unintentionally scare the management (afraid of being upstaged, shown up) all the way to the top. (3) Have the scared management arrange to fire you. Response: Find a market need can meet with own resources (e.g., think of a new Web site, get some computing equipment, write the code, go live on the Internet, get some publicity, users, and ad revenue, entertain buyout offers), be the first level worker and also the manager and owner. Basically, if get good revenue, can't get fired, e.g., can't lose your job. Experience examples: (1) In high school plane geometry, in class mostly slept, refused to admit doing any of the assigned (too simple) homework, but there were some more difficult exercises in the back of the book so made sure I did ALL of them. One took me Friday to Sunday evening, and on Monday in class the teacher had the class work on an easy exercise with the same figure, so for the only time I participated said "There's an exercise in the back with the same figure ...". For about 20 minutes the class and teacher struggled with increasing frustration but no success. Since I didn't want to be accused of wasting the class time, said "Why don't we ...", and the teacher interrupted, spoke over me, wouldn't let me finish the suggestion, and said with anger "You knew how to do it all the time." Of course, wouldn't say anything otherwise. Point: The main goal was to learn some plane geometry which I was doing apparently quite well but got anger instead of praise. (2) At the end of the class, there was a State achievement test. The last problem was "What is the first step in using construction to inscribe a square in a semi-circle." I didn't get it so after the test kept working on it until I did. My solution was first to construct something easier: Construct a square of whatever size, circumscribe a semi-circle, thus, have a figure similar to the desired one but of the wrong size, construct a 4th proportional to get the needed length in the given semi-circle. Constructing the second figure looked novel, not from the course, so after school asked the teacher if that was okay? She said "No, but why are you working on that?" Later I discovered that I'd reinvented similitude, actually taught in some more advanced material. Point: The main goal, even beyond what was in the class and book, was to make progress, even invent, in the subject. Again the from the teacher I got contempt instead of praise. (3) Working in a time-sharing company, my job was the math library. The FFT (Fast Fourier transform) was a hot topic, and I got fairly deep into it, along with the related Blackman-Tukey power spectral estimation, dropping the assumption of number of samples a power of 2, etc. The manager's remark was "You tend to pick the bones clean" and fired me. Point: The main goal was to please the customers, and having a better software library in the FFT hot topic was a part of that. So, from doing admittedly exceptionally good work, I got fired instead of promoted or even keeping my job. (3) After the FFT work, got hired as helper of users of a university computer center. As a tool for teaching some statistics, a prof had written a main program to call the statistics routines in the IBM SSP (scientific subroutine package). In testing he found that two of the routine were slow (for integer n points of input ran in time proportional to n^2) and for polynomial fitting (via a method that led to the notoriously ill conditioned Hilbert matrix) gave numerically inaccurate results. So, for the two n^2 cases, I found tricky ways to use the n(log(n)) heap sort without using more storage (did some tricky overlay, reuse of the storage in the passed parameters) and for the polynomial case used some Forsythe and Moler work to get better numerical accuracy. To do this, some days I worked late, and the head of the computer center said critically I hear that you have been working all hours of the day and night" and fired me. The Dean of the business school kept me on to teach courses in computer science. Point: Again the main goal was to have better software, better than the prof wrote, to have a better computer center, and my work, improving on what the prof and IBM had done, was exceptionally good work, but I got fired instead of praised. (4) At FedEx, the BOD was seriously* (funding at stake) concerned about scheduling the fleet. At a meeting to see how to respond, no one had any ideas, so I said I'd solve it. I had some ideas, wrote the code, ran the code, pleased the BOD, saved the funding and the company, and got an angry manager who tried to get me fired. The founder, COB, CEO got me a Senior VP as a new manager; I did some better work on scheduling the fleet, and the VP's response was "there no money in the budget for you", and wanted me fired. The promised stock was very late, and I went for a Ph.D. in such applied math. Later FedEx worked with a prof and a grad student and implemented, as a Ph.D. dissertation, my scheduling idea (0-1 integer linear programming set covering). While reporting to the VP, I pleased again the BOD and saved the company. Point: So, I had saved the company twice, and the new scheduling proposal in effect directed a dissertation, i.e., it was good work. But the two managers both tried to fire me and there was no stock and no money in the budget. (5) Later in a major AI project, there was a big problem with the design and code. The team had a crude solution in mind, that would take weeks of coding and at best would not be very good. So, I had an idea, got a pizza, worked all night, and had running code for a nice solution. I got an award from my manager, but from the rest of the management chain soon I was fired. Point: I'd done novel, good work, saved the AI project, but got fired. There are a few more examples. Old quips: "No good deed goes unpunished." "The nail that sticks up gets hammered down." "Don't rock the boat."