## Comments

Comments from: Hacker News 
[1](https://news.ycombinator.com/item?id=19549453) 
[2](https://news.ycombinator.com/item?id=29130039) 
[3](https://news.ycombinator.com/item?id=29231936)
[4](https://news.ycombinator.com/item?id=31422718)
[5](https://news.ycombinator.com/item?id=40552291)
and related blog posts.


### Strategy vs. objectives

"Distinguish the concept of an objective from strategy. An objective is something that is desired to be achieved, something that indicates the business is running well. It is merely a target and does not specify how that target can be achieved. Strategy is what gives direction as to how a target can be reached and sort of a framework under which they can operate. Businesses sometimes define an objective without having a strategy; in such a situation there will be a hundred different ways how the objective can be achieved but no direction on which way to pick."

"For strategy with objectives, the best quick start I've seen is a strategic balanced scorecard, and it leads directly to OKRs and KPIs. Describe what your organization/project will look like, at an agreed future date, such as one year from now: 1. What are the financial highlights such as sales and investments? 2. What are the external highlights such as customers and vendors? 3. What are the internal highlights such as processes and employees? 4. What are the learning and growth areas such as research and upskilling?"

"Goals masquerading as strategy is an incredibly common problem. The book "Good Strategy Bad Strategy" is my favorite treatment of the problem. Unfortunately a lot of executives don’t like to be told they are suppose to take responsibility for strategy. Here is an article length version from the author: https://www.mckinsey.com/business-functions/strategy-and-corporate-finance/our-insights/the-perils-of-bad-strategy"

"I use OKRs extensively up, down and across my business and at no point have I felt they masquerade for strategy. You set a destination for the business through the creation of a vision and then create OKRs and KPIs to measure progress towards it and perhaps more importantly provide transparency."


### Pros


"Good OKRs provide measurement and alignment. Measurement is handy -- the idea is to say 'I want to do O, and I believe X, Y and Z are sufficient to achieve it'. Since all these variables are measurable, you can see whether the problem is that you failed to achieve X, Y, and Z, or if your plan wasn't actually sufficient to achieve it. Alignment is a bit more nebulous. For small teams, it may be unnecessary. But as orgs grow, there's room for mission creep and contradictory goals and efforts. Good OKRs are designed to be able to connect up the org chart. Staff should be able to explain how their contribution serves the mission, rather than their own insular fiefdom. And if they can't, it might indicate they're not doing what the rest of the org is planning around!"

"When I took over at my new lab, 40 FTEs, I implemented OKRs, just between my direct reports and I. It quickly became apparent who gets shit done and who doesn't. It also became apparent how overloaded some folks were. How little some understand their jobs. It helped me see what I needed to focus on and what I needed the lab to focus on. I am also in a massive, MASSIVE, organization with literally acres of people dedicated to formal communication processes. I submit that OKRs were handy because they forced formal communication that revealed problems outside the official formal methods. It's a hack. And in the realm of formal comms, it's a particularly low-friction, low-cost-of-adoption hack. 10/10 will use again."

"You should be looking at your OKRs and figuring out what you should do to get there. But, you might have to break it down a little further. Indeed, a KR of 'increase monthly active users by x%' is not directly actionable by an engineer. But an engineering department can come up with its own OKRs that fit in that direction. For instance, to achieve that goal it might be necessary to develop new features. However, if 70% of the engineering time is spent in bug-fixing then they're not going to be able to do that. Do you know where your team spends its time? That might be worthwhile to figure out. So, an objective of 'Increase development time for features' (or some such) might be considered. If you find you're dealing with a lot of bugs, one of the key results might be to reduce bug reports by 50%. To do that you might argue that you should add some integration tests so that you can change code and catch issues before they get to production so that in the future you'll be spending less time on bug fixing / rework, so that you can work on new features that will entice new users to full fill the company objective."

"OKR work is/should be all work. Each task should be aimed toward moving forward on the goal.... Let's consider a KR of 'increase active users by X%'. Interviewing/hiring isn't going to move the needle on getting X% more active users by itself. Having more engineering time available for new (critical) feature work might, and you have to do interviewing to get new hires. Training in and of itself isn't going to move the needle either. But having a more knowledgable engineering team probably will, by being able to move faster or better. You have to do training to improve knowledge. Maintenance work might not move the needle on active users FORWARD (or it might, if you have a lot of bugs that prevent users from actually using your stuff) but it might prevent it from going BACKWARD."

OKRs, KPIs, etc are often challenging for orgs, teams, and individuals that are poorly trained. If people are poorly trained, they will find it challenging, even counter-productive, to use them. The end result is nobody uses it right, and the company suffers. And it's complex enough that a pithy blog post 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.

"I implemented OKRs among my small team of 10 devs who are all pretty awesome rockstars and good contributors, but still early in their careers. It turns out that OKRs made the employees happier, because it served as a “more abstract” form of feedback. Before, they were receiving feedback, but it was too specific and narrow. Things like “this class can be refactored to X pattern” or “You missed a few unit tests covering X Y Z cases.” But when we started tracking things like time to ship a new feature, bugs per implemented feature, hard deadlines for certain product releases, etc. it really helped to give some better feedback."

"OKR work is a subset of engineering time. We deal with things like interviews, meetings, tech talks, training, migrations, and maintenance work outside the framework. You should always be making progress on OKRs, but it’s not the only thing you do. Engineering has its own overhead, not every hour is billable."

"Refactoring, from an OKR perspective, means you are protecting the ability to ship. Which means that there are tacit implications to OKRs. Nobody would want you to prioritize some random OKR that would cause code quality to drop to the point that it impacts shipping (because now there are, say, bugs that shut off entire functional areas or something stupid like that). OKRs have built-in assumptions and these tend to be around protecting existential abilities of the company, like shipping code."

"One engineering team objective is to remain efficient as the team is growing. The way to achieve that? By refactoring code and introducing automation (like CI, CD, etc). This gets reflected in the cost of developer time per feature / project. Which can be represented as a KR."

"Security is an actual objective at Google. Supporting key results would be things like performing a certain number of audits, conducting pen tests, code reviews, etc."

"[Contradictory goals] is the single biggest thing that trips up organizations which have grown, or been acquired. It also seems to be the thing that people can't wrap their heads around because it feels difficult. If whole divisions aren't aligned then it doesn't really matter how well your team performs because the lowest common denominator division becomes the limit."

"Everybody's acting like OKRs are this enormous heavyweight process. Why? You just write down what you're planning on doing this quarter in a prioritized list. The purpose is to broadcast your view of your priorities, so interested parties can ask that they be adjusted. At the end of the quarter you look back and review what you actually accomplished. It's really not that big of a deal. The process gets heavier at the level where OKRs are getting aggregated across multiple teams, or teams of teams, but that's a cost paid by managers, not by line employees."

"OKRs put goals one place. The process to determine what the OKRs are ensure that everyone's on the same page about the objectives. People in an organization want to feel like they know what they're working towards. When they don't they get stressed out and unproductive."

"I came in thinking I had one laser-focused mission. But I had seen an org use OKRs and was interested in deploying the system. So I found a format I liked (Excel, objectives in bold, key results under each, quarters pushing out in columns to the right), explained the plan to people, invited them to come get me up to speed on things. Turned out there were over 70 discrete projects ongoing trying to implement or change things. Some from above, some initiated from below, some inherited from my predecessor who hadn't bothered to mention them to me. I had started 1:1s every week with each of 5-6 folks and got their input. Each person ended up with their own sheet. It took a while to sort out that some people had different names for the same things. There was clearly some gradient descent on my part. 70 projects is the lowest local minimum I could find. It took several epochs to find."

"John Doerr wrote the great book about OKRs to explain how important they were in setting the strategy for Intel when it went out of the memory business and focused just on processors: achieving that in 1 quarter is only possible with very clear communication. If it's not rare enough (quarterly or yearly) or not short enough (few items), it doesn't work, it's just a wish list. I have seen them working and not working (when the whole team knew that doing all the stretch goals were impossible)."

"We just got done with trying OKRs for a quarter at my company. It was overall a really positive experience. We had a small team of people working to push out a new product. At the beginning of the quarter, we defined what success looked like for that new product and came up with the key indicators for it. As a developer, it was really fulfilling to take time to really think through what it would take to build out a truly quality product. I spent a lot more time thinking through the things I normally wouldn't put much effort into. We built tools to help our support team understand the new product. We put together documentation. We took time to think about how to train the company on the new product. We wrote automated tests to make sure that we could sell the new product as a stable solution. Everything was focused on our overall objective to deliver a quality product. Our team had people from development, marketing, sales, product, and quality assurance. It was great to see a cross-department team unified to get something amazing done. Just adding a data point that there are ways to make it work well."

"One way in which I've seen OKRs used effectively is as a defense against the type of middle or upper manager who is constantly coming up with new ideas or tasks. But what if we did $shiny_thing!? Sorry, that's not in our OKRs this quarter, let's have a meeting to plan for next quarter."

"OKR and other management frameworks work well in environments that would perform well even without them (self-organizing, enthusiastic, competent, non-threating and driven employees). Having just the structure in place wouldn't guarantee much. Google's success using OKRs was a side effect of their past employee composition and the fact it got least in the way of them to do great things."

"Ive found communicating OKRs steadily on a cadence (weekly) as well as show the team the progress towards a goal at an all hands to be effective. Its rare for someone to miss all the all hands meetings. Commms, progress, priorities, from a company down to tactical execution level are easy but require discipline."

"I like having a static quarterly document, in a super easy to access place. It must be one page max and lay out the "theme" of the quarter and supporting initiatives. Every team weekly summary email has a link to this document in the footer. Tracker — or whatever you use — has epics et al. aligned with this document."

"I worked at a startup that started OKRs and I found experience super enjoyable, to the point where working in a more relaxed environment (for lack of a better description) is kinda hard these days. The two things people and teams struggled the most with though, IMHO: 1) Coming up with a good OKR that met longer term, higher level company priorities that intersected your work. 2) Coming up with a good ORK in terms of measurable key results. It can be tough and time consuming to get the measurements in place necessary to gauge the results, or even make a case for the OKR in the first place (incidentally this is the dirty secret of SRE IMHO). We would pro-actively get data collection in place on occasion for reasons that included helping to launch and score future OKRs."

"As a manager, you have to talk about performance. If you’re not, you’re failing your company and you’re failing your team. If OKRs help you do this, go for it. If not, find another tool. What’s important is that you talk about performance, early and often."

"Figuring out why you do what you do and how you measure the success of that in a way that leads you to the right result IS hard but extremely valuable work. It forces you to deeply understand the problem you're solving and the challenges you face."

"There is a peace that comes with knowing what you are working on is aligned with the company, and that management has good visibility into how you are doing. And if you take your job seriously, it is really not that hard to keep up with."

"OKRs probably only make sense in terms of a complex system, so required reading should probably be Donella Meadows’ Thinking in Systems. In particular, you need to understand that for something to change often everything must change. People try to do these very tiny scoped OKRs and that's kind of risky. To get a complex system to change, often you just need to hold the output at some desired level, and allow the internals to reconfigure to provide that output. Nobody talks about OKR-induced organizational chaos, but ideally you should have one or two OKRs a year that really rearrange the entire system because they happened to be located at a bottleneck and they had to twist the system around until something else became the bottleneck."

"OKRs inspire a conversation about how the company should really be spending its time and resources. What are the ultimate goals of what the business is doing? What is the real opportunity? How do we define success and how can we push success further? What's the dream by investing in these various initiatives? Once you are leading an organization, it behooves you to take this type of planning seriously and spend some time trying to answer these questions at some cadence (once or twice a year at least) to solidify the high level goals - even if there is constantly the risk of these OKRs getting trampled by the realities of the business."

"One of the main benefits of OKRs in my opinion is helping each person understand where they fit into the big objective. Many people comment about their desire for ownership of their work. OKRs can play a role in describing a persons ownership."

"The most important part of OKRs isn’t the metrics, it’s the understanding that the team has been tasked with solving some problem without being told how to solve it. The team gets to own the solutions that drive the metric. This is far better than just being a feature factory that cranks out whatever upper management demands."

"Getting clarity about goals across a big organization where every single person has a different conception of the problems it faces is Very Hard. I don't know if OKRs are the right answer, but the right answer will definitely reflect the Very Hard nature of the problem it's trying to solve. Probably the most any methodology can do here is trick you into asking the right questions."

"I have found that KPIs are a useful addition to an OKR framework. Objectives are usually big and ambitious, but need to be pinned down using Key Results. Key Results are the definition of success for an Objective. However, it’s often the case that there are many ‘numbers’ that affect the Key Results. In advance it is very difficult to know which combination of such metrics is the right one to target. In many cases these metrics can’t be hard coded into a KR, as the sweet spot for the business is unknown - and ultimately we don’t care which combination brings us to hit our KR. So KPIs allow us to play with the next layer down from KRs, setting and revising targets for the constituent numbers that ultimately drive a KR."

"Improving SLA metrics are excellent OKRs since they are easily measurable and are grease to the orgs cogs."

"The alternative to OKR is that your manager writes down your goals in a hidden place where you can't see them, the only thing that changes is that now you are less informed. Personally I thought it was good that I could see what goals my manager had, what goals his manager had, what goals that managers manager had etc. I don't see why people are so angry at that level of transparency."

"Now in a manager chair I have both experiences, setting bad OKRs and good OKRs. The performance and communication improvements when you get it right are astonishing. When you find a place where people get it right, you'll love it."

"OKR in general makes it much easier for managers to do their job, and you really want your managers to do their job properly."

"OKRs are done right in tons of places, just that when they are done right people don't notice them much because they aren't meant to be a thing you notice much. Its first and foremost a thing managers should be engaged with since it helps them organize with each other, individual employees should barely be aware OKRs are even a thing at the company."

"The times I've seen OKRs and metrics used effectively, they met two criteria. (1) it was always a metric closely aligned with what customers want and which drives revenue for the company; and (2) it didn't just impose a requirement to do work, it also provided political cover for not doing other, competing work."

"Ideally management is working with IC teams to set good Key Results. Management shares context of what's important (objectives) and IC teams propose good quantitative measures (key results) of how they'll achieve it."

"Communicating consistently the priorities and tradeoffs the company wants to make as they get larger is a hopeful use of OKRs. In small teams/companies “the right thing” can be obvious and the team can operate in a shared headspace with low cycle time to discuss and decide tradeoffs when they arise. This gets really problematic at scale."

"Objectives are always inevitably a thing. OKRs make the implicit explicit."

"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 - that's the whole point."

"The big value add from OKRs is legibility outside your team/org. OKRs are about making your goals and work easily understandable, because the alternatives don’t scale as well. 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."

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

"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 auto-deployments, let's fix infrastructure". 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")."


### Mixed


"Fundamentally, OKRs are a tool that should allow teams to make decisions about what to focus on, with the knowledge that they're aligned with the business objectives. If a team already has an immutable quarter+ roadmap, they're not making any decisions, they're just working; OKRs aren't a good fit for this kind of team. OKRs done well _should_ result in teams feeling empowered, because they can see the link between their actions/decisions and overall success. OKRs done poorly have the exact opposite effective; not just benign, but harmful." 

"One of the common failure modes of OKRs is that the top-down view of the management doesn't connect well to the reality of day-to-day operations. Of course, having teams produce bottom-up OKRs has failure modes too -- it's not really strategic planning if the leaves of the org tree are setting the goals. So you need both top-down and bottom-up. A cycle of planning seems to work best -- a high-level goal is transmitted down, then each team engages in a local goal-setting process, then these goals go up, then there is coordination and refinement. But this takes significant time and requires incredible discipline, so it's hard to do well."

"Healthy OKRs do exist but they have preconditions. 1. The individuals devising them must fully internalize which are the objectives that do matter for the org, among an ocean of "priorities". 2. The KRs must be carefully thought out and evaluated against their vulnerability to the law of unintended consequences. 3. The team(s) implementing the KRs must understand why theses KRs exist, their relationship to the Objective they serve, and how well (or not) they measure the objective. 4. The leaders must be quick to change the KRs if there's any doubt as to whether they are actually helping, or causing more damage; the "why" should remain relatively constant over time, the "how" can change. 5. KRs that have thresholds should always be ambitious and very hard to actually meet, as they stretch the organization's goals. 6. Tying perforance bonuses to them is dangerous because it immediately results in gamification."

"OKRs as the summary of a strategy conversation (not a “visioning” session) that actually happened, in the words of those who will do the work, fine. In most other scenarios I would proceed with extreme caution."

"At higher level OKRs looks like "attract X more customers" or "reduce customer churn by Y%" etc. To achieve those they instruct teams to create customer value. At the individual level, such goals aren't as easy to write since they are the result of contributions from many parts. If you can come up with good measurable goals for you as an individual since you have enough individual freedom to do so, then yes writing that down is good. But if you don't have any long term project and don't have control to plan what you work on, then writing down an OKR is just hazing."

"In most places OKR, SMART, etc, just pops up around performance-review time. During other times the actual goals and priorities drift and rearrange like deck chairs on the titanic. As long as one can finagle the rhetoric to make it seem like there was a coherent narrative where one has done the things they wrote down they were going to do last year-- nobody cares."

"My charitable view is, they can serve as an error correction function in a product led org. I.e., product and sales people don't care about the internals, just feature, feature feature. Over time this increases entropy. OKRs can be used to make time to address entropy."

"OKR shows you the state of the current organization. If the OKR are dysfunctional the organization is dysfunctional, it would be even if you didn't see the OKRs. The fix isn't to remove the OKRs, it is to align OKR with what each team is really expected to do."

"Sometimes you may want more than single metrics, and the metrics you leave on the side to priorize the OKRs can be as critical. Put another way, if your client has 20 inherent metrics, you can't have 20 OKRs so you're always at risk to mess it when focusing on a smaller set."

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

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

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

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


### Cons


"I have yet to find anyone at my company who can explain to me what an OKR really is, but apparently I'm supposed to have them entered in to our HR system."

"Number one way for management and so-called leadership to befuddle their way into the arms of Goodhart's law."

"Companies think OKRs are a godsend because suddenly the companies can measure their progress in some way that is not just 'story points per sprint' ignoring the fact this measurement only makes sense within the system itself and may not reflect the reality at all."

"There are so many dimensions of valuable work (no security holes, being nice, not reinventing the wheel, documenting well, long-term stability/refactorability, code being reusable by other teams) but I imagine OKRs can't cover all those facets."

"We used to set OKRs at team level, and then prompty discard them and the carefully constructed plans that went nowhere when faced with the reality. So now we're setting the Objectives, and measure the KPIs that are defined to reflect the objectives. The actual means to move the KPI, which would be the KR (key results) in OKRs, are no longer defined in quarterly planning sessions, but are selected and updated by the team during sprint planning."

"I felt a sort of a weird disconnect between OKRs and actual work/performance. On the one hand, OKRs were presumably critically important, but on the other, they weren't directly tied to individual performance. I still have trouble wrapping my head around that."

"I found that as a team lead, to the extent that OKRs were stressed, any non-OKR related work became highly disincentivized. Refactor? Write more integration tests? Hell no, not if it doesn't directly impact OKRs. We had stories in the backlog that really should have been done because they would have helped other teams and yielded a positive return, but anything non-OKR was just dropped on the floor."

"OKRs didn't really provide any value to the team that I could discern. We didn't have to look at our objectives every day to know what to do. We had typical releases/epics, etc... to do, and on a day to day basis, the OKRs just receded into the background."

"OKRs were a complete waste of time. I was required to waste hours trying to come up with OKRs, none if which had anything to do with what my actual day to day work entailed. The OKRs were then promptly ignored so I could got back to getting shit done. At the end of the ORK term of course they'd been ignored. This had the effect of being demotivating because I was being asked to make up these OKRs "because at this company we have OKRs" but then having zero time and zero motivation to pursue them since there were people waiting for my real work to be finished."

"Every time I've seen OKRs tried (over and over again in the span of a 30-year career), the "goals" are based on whatever the priority/flavor-of-the month happens to be when goal-setting is announced. I've never seen those priorities last an entire year, but I have been called to account for why I didn't personally meet the goals that I was pressured into setting "for myself" even though the priorities shifted over the course of the year."

"Concrete team stories are usually quite clear. OKRs force you to encode a bunch of them into objectives and key results. This produces utter nonsense if the duties and opportunities are generic or fragmented. Not every team can write a clear OKR which makes it obvious what's happening, especially if you servicing multiple departments."

"I used OKRs on several teams to varying degrees at Google. Not a fan.  It makes organizations slow and inflexible. I used to joke that as soon as another team was involved in something you needed to do it would probably take a quarter. why? Well what you wanted probably wasn't on this quarter's OKRs so it would be an uphill battle to get them to do it. You'd have to argue about getting it into next quarter's OKRs."

"OKRs causing slowdowns is a real issue, but is actually a problem of management and company as a whole. Teams want to be silo-ed and not bothered by anyone else, hence set their goals and just do them, while upper management never sets some actual objectives and roadmap which could have been mapped into cross team projects and goals. When goals become a religious quarter to quarter thing without allowing any deviation, then everything is slow."

"Despite the name and intention, in my experience, OKRs is a prime candidate for cargo culting culture into an org and using process as a proxy for actual focus on outcomes."

"I think the general trickiness is that OKRs are inherently backward-looking. A lot of technical improvements have to do with risk mitigation. The risk of nasty bugs (testing), the risk of future functionality being slow to develop because of poor architecture (refactoring), etc. But it isn't clear (to me) how to write OKRs for mitigating future risks."

"The executive team, with lots of support from HR, rolled out a really heavy, very process-centric OKR system and assumed that by announcing that Google uses OKRs and providing a portal that we'd start aligning. It was an abject failure - not because (IMO) OKRs are a bad idea, but because the leadership teams made the mistake of confusing process for communication. After the big announcement, it was mentioned only ONCE ever again. Seriously. My team (of six) and I made use of it, but it was very difficult to align it with the goals of, say, our chief revenue officer; someone we met about three times in four years. We went back to using team & personal goals, creatively using our backlog and one-on-ones because there was no input, no updates and no communication about the OKRs. The start-up failed because it wasted time chasing tactical low-value (tangential) deals instead of delivering against a viable, sustainable strategy."

"People who get shit done do so in spite of OKRs or other formalisms like Agile. OKRs do not help orient work towards what matters, maintain accountability, alert management to schedule slippage, or unify team efforts. OKRs are cargo cult metrics for middle management to bend the ear of higher management to argue and gladhand for bonuses & promotions."

"I have never been involved in an okr system that wasn’t an utterly pointless waste of time that no one but hr and back office people took seriously."

"We do quarterly OKRs. Quarterly deadlines are completely arbitrary and my actual deadlines aren't tied to the quarters. So I (and everyone around me) don't take them seriously. We take the actual deadlines seriously. The only thing OKRs seem to do is provide direction to the higher ups about what my team is up to."

"Refactoring is a really tough sell for an OKR. We use OKRs and we have had a couple quality initiatives in the past that were tied directly to OKRs and even then it’s hard to get that work prioritized. At the end of the day as long as users aren’t complaining product is going to index on features and value added. I’ve never been somewhere that would let you make a goal around redoing something that already works (even if it works like shit). I think the reason for that is it’s hard to come up with a key result that can be measured once the work is done — other than “it still works the same”."

"OKRs further entrench hierarchies in a way that is harmful to productivity and harmony. They allow for a whole middle layer of management that simply decomposes their KRs and passes them down. The people below them are ultimately the ones on the hook for delivering, and if the middle manager doesn't achieve their own KRs, they already have an agreement about which person that reports to them is to blame. In my organisation OKRs are being used as a sort of feudal system whereby the peasants work the land, but the credit is passed up the chain to the seigneur."

"OKRs are very dangerous when they are scoped beneath the team level to the personal level. Personal OKRs tend to create perverse incentives: “I am an amazing employee because I didn't care about my struggling colleagues and ignored them and delivered 10 times as much work as them!”"

"OKRs need to be understood as a management back-off to be effective, but this culture shift is relatively uncommon. If you look up the literature on setting good OKRs, you will find blog articles about SMART goalsetting or whatever, but very little about “OKRs are about treating your employees as research scientists. You are going to give them a goal to do research on, that is the objective, and you're going to open up the pocketbook and just say, how much grant money do you need to solve this objective. So that's why it's important that the objective makes the business money, you need to know how open the pocketbook is. Meanwhile, the KRs are important because research projects have a sort of inertia, by themselves they do not respect the Pareto principle to do the 20% work that drives 80% of the result. So you have to tell your researchers when it's okay to stop, they won't know that unless you tell them and they will keep tweaking to get that last 2% efficiency out of the system.”"

"Non-SMART key results anywhere in the chain allow opportunistic employees and/or managers to spin tales about how they're doing great regardless of actual results."

"One of the downfalls of OKRs is that in many cases the true objective for people and/or teams is not something that can be mentioned without being unspeakably impolite. For example, people won't write a political goal such as "I want my department to grow by X% so I gain prestige" or personal goal "I want to learn technology X because it will look good on my resume when I job-hop", even though these goals happen all the time."

"If the executive team does not publish company-wide objectives in time for downstream teams to build their own objectives upon them, then the downstream teams just do what they've been wanting to do anyway, and then spin a yarn about how it fits into the company-wide objectives when (and if) they arrive."

"A lot of organizational time is spent coming up with OKRs only for them to be either overridden due to the reality of running a business (gotta do what clients need, gotta do what you can to compete with competitors) or just by VPs/Directors deciding that something else requires the teams focus. Ultimately it seems like a whole bunch of busy work. “But you’re not doing OKRs correctly!” Sure, I agree to that. But what use is a system or process that’s so difficult to get right that most organizations fail? I would argue that it is useless."

"Emphasis on these metrics and their associated processes is an important part of a process driven organization, where you want everything to be consistent, and are willing to sacrifice efficiency (and job satisfaction), while carrying a heavy admin layer. This is probably true for most big companies."

"OKRs are rocket fuel for the psychopaths and narcissists in your organization because they are geniuses at playing that kind of game and they will use it to make themselves look good while making hard working people who are more interested in doing work and realizing the strategy look bad."

"OKRs for us (a mid-size? company, 150ish people) have been a disaster. They pit teams against each other, instead of aligning them with the business, by making them focused on their targets and nothing else. It's been a lot of "this isn't in my OKRs, why should I work on it?", making it both hard to adjust course ("why would I work on this important thing when it's not an OKR?"), and to get the teams to help each other ("why would I work on their target when I have mine?"). Right now we're trying a combination of company-level objectives (not KRs) and Kanban, where the teams just work on the next most important objective they can."

"I'm so tired of meta-work. Work that adds to the workload of already overloaded and stressed employees of a company. It feels like nonsense that everyone goes along with simply because they are all too terrified to say no, this doesn't help me get my job done."

"OKR’s are nothing but a rehashing of Peter Drucker’s Management By Objectives (MBO) - invented in 1954 and already ignored by MBA programs by the 1970s. Management By Objective is useless until one is talking about the business unit level where folks have direct impact on profit and loss. If its not already immediately obvious what numbers are relevant to your job, there’s rarely anything to be gained by groping for them in the dark corners of a middle manager’s quarterly performance ritual."

"Now having worked in a few smaller teams since my time at Facebook, 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)."

"The fundamental issue is that in almost all larger companies, upper management does not trust that their employees are either intrinsically motivated to do a good job, or are smart enough to determine what "a good job" is. So rather than having a chain of trust from upper management to middle management to individual contributors, they seek to create a measurable control system. This inevitably replaces people's intrinsic motivation to do a good job with an extrinsic motivation, which only poorly represents the company's actual goals. At this point, most people are no longer trying to do a good job, they're instead trying to make their numbers look good."

"You need good executives, and you need to be able to depend on executives who have good guts. You cannot automate your way into being successful, at the end of it all running a company is still pretty much a social endeavour, one that cannot be partitioned down to individual units, neither can its success or failure be explained by those individual units alone."

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

"What I've found is a slew of Product Mangers mostly just sit in between devs & users, without coordinating cross team, actually writing specs/tasks/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."

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


### Alternatives


"Do you have any alternatives to OKRs? Genuine question. We‘re using OKRs and I dread it, but it’s better than nothing. Hoping for everybody to magically on their own align with company goals doesn’t work either."

"How do you propose companies approach goals setting? Surely there has to be some way for a company to communicate to employees “Our goal is to grow 30%” and we will do this focusing marketing on a rebranding, focusing sales team on shifting to outbound sales model, product will build features x, y, z, etc. Very simplistic example but companies need some way to flow goals down to smaller groups of people down the chain, don’t they?"

"The author W. Edwards Deming has a ton to say on this. Lots of very practical advice on how to measure the right things, yet also avoiding relying too much on measurements. It is unfortunately quite complex and not easily digestible as pop management advice. I love the books "Out of the Crisis" and "Some Theory of Sampling"."

"I did not do any OKRs on an infrastructure team. Qualitative results were just as valued, and we had the quantitative knobs to dial when needed thanks to excellent internal tooling and service maturity. I found it ironic that we didn’t do OKRs despite using data to drive decisions."

"We use SAFe at my current job; 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."