Contents:
- Objectives and Key Results (OKR)
- What is OKR?
- What is an objective?
- What is a key result?
- OKR systems
- OKR quotations
- FAQ
- Are OKRs heavyweight or lightweight?
- How long should I spend writing OKRs?
- How does OKR compare to other communication approaches?
- How does OKR compare to email or chat?
- How does OKR compare to task lists or work boards?
- Can you do OKRs for capabilities that are all-or-nothing?
- Should measurements and times be explicit or implicit?
- Are OKRs transparent?
- Comments
- For more information
Examples:
OKR stands for Objectives and Key Results.
OKR is a method of defining objectives and tracking their outcomes:
-
The Objective: what we want to achieve
-
The Key Results: how we want to know we are making progress
To create an OKR, one way is to use this sentence:
- I will (Objective) as measured by (this set of Key Results).
Purpose:
-
OKR connects objectives of organizations, teams, and individuals.
-
OKR connects objectives to measurable results, making people move together in the right direction.
-
OKR makes sure everyone understands what's expected of them at work.
History:
-
OKR was invented at Intel and championed by Andy Grove, Intel CEO.
-
OKR is in use by many companies, including Intel, Google, Microsoft, Twitter, and Uber.
Ground rules:
-
OKR items are visible to the whole organization, by default.
-
OKR visbility helps teams work together, and helps everyone know what others are doing.
Your objective should be:
-
Inspirational
-
Provide a sense of meaning and progress.
-
Skip anything such as a small percentage gain.
-
-
Relatable
-
Use language that your team knows and likes.
-
Skip abstract language and unfamiliar acronyms.
-
-
Timely
-
Aim for a clear sprint toward a goal, such as doable this month, or doable this quarter.
-
If it takes a year, your objective may be strategy, or maybe even a mission.
-
-
Actionable by the team independently
-
Your objective has to be truly yours
-
You can’t have any excuse of interdependence, such as "marketing didn’t market it."
-
-
Measurable by the team independently
-
You have know if you've succeeded, or it you're making progress, and how much.
-
You can't have any excuse of independence, such as "That other team didn't measure it."
-
For example, some good objectives:
-
Launch an Awesome MVP.
-
Succeed in raising Series A investment.
-
Transform San Francisco’s shopping habits.
See many more examples here
Key results take the inspirational language and quantify it.
Create key results by asking a simple question “how would we know if we met our objective?”
Typically you have 1-3 key results.
Metrics can be based on:
- Growth
- Engagement
- Revenue
- Performance
- Quality
For example, “Launch an Awesome MVP” might have KR’s of:
- Net Promotor Score (NPS) of 8/10
- 20% of users come back 2X in one week
- 10% conversion
For example, some good key results:
-
Sales numbers up 30%.
-
Raise a Series A investment of $1MM.
-
Double our userbase.
See many more examples here
All high-performance OKR systems have commonalities.
Ability to track results on a quantitative basis:
-
Key results are not general or subjective actions you plan to take.
-
They should always include numbers to make it clear how much has been achieved.
-
For example, if Mary’s objective is to improve her sales prospecting skills, one key result might be to spend two hours a week shadowing Jennifer, the team member who demonstrates the most prospecting success.
Ability for people to look at every day:
-
This consistency turns goal-setting into a habit and changes how people think about their work and approach their everyday to-dos.
-
It puts in place natural milestones that make you think about what you need to do next and aim high.
Ability to stretch:
-
You want objectives to be ambitious enough to push you beyond your limits.
-
When everyone does this, it forces tough conversations about what's truly needed to beat expectations.
-
Most people wouldn’t consider 70% to be a good grade, but for OKRs that’s just about perfect.
Andy Grove, CEO at Intel, first spoke about “Objectives and Key Results” (OKR) in his book High Output Management.
"A successful system needs only to answer two questions: Where do I want to go? The answer provides the Objective. How will I pace myself to see if I’m getting there? The answer gives us Key Results."
“The one thing OKR provides par excellence is focus.”
“We see a nesting hierarchy of Objectives: if the subordinate’s Objectives are met, the supervisor’s Objectives will be met as well.”
“To be useful a Key Result must contain very specific wording and dates, so that when the deadline time arrives, there is no room for ambiguity.”
“OKR is meant to pace a person – to put a stopwatch in his own hand so he can gauge his own performance. It is not a legal document upon which to base a performance review, but should be just one input used to determine how well an individual is doing. If the supervisor mechanically relies on the MBO system to evaluate his subordinate’s performance, or if the subordinate uses it rigidly and forgoes taking advantage of an emerging opportunity because it was not a specified Objective or Key Result, then both are behaving in a petty and unprofessional fashion.”
John Doerr, venture capitalist at Kleiner Perkins, wrote the book "Measure What Matters" to teach OKRs and why they help companies succeed.
"Objectives and key results are clear vessels for leaders’ priorities and insights."
"By clearing the line of sight to everyone’s objectives, OKRs save time and money."
"Transparency seeds collaboration."
"Continuous recognition is a powerful driver of engagement."
"Nothing moves us forward like a deadline."
"Healthy culture and structured goal setting are interdependent."
"Google uses OKR as a tool to empower people. People think it’s about accountability, and it does achieve that as a byproduct. However, it’s really a way to build a social contract in your organization."
"The Objectives are what you want to have accomplished. The Key Results are the “how” in “how you’re going to get that done.” What matters more than getting the best single answer is getting the team to agree in how you’re going to do what you set out to do (a.k.a. the “Key Results”)."
"The magic words are “as measured by.” If a Key Result isn’t measurable, time-related, if I can’t declare it done, then it doesn’t have the kind of fidelity or integrity that it ought to."
"OKR is not a silver bullet; it’s a powerful, clear, empowering communications tool to get transparency, some accountability, and a lot of enthusiasm about what it is that’s really important."
"This system works provided the leadership of the company embraces it. If the CEO of the company doesn’t believe in OKRs and won’t pursue them, I suggest you not try. If the leader of the organization or the team sets personal OKRs as well as group OKRs, I daresay this is the most powerful tool you can have to achieve operating excellence and high performance in your organization."
OKRs are lightweight. This is on purpose. OKRs are deliberately created to be lightweight goal tracking, that is effective for teams of all sizes, that provide high-level summaries with ways to know progress.
If you know what you're doing, in terms of your goals, your intentions for deadlines, and how you want to make progress, then writing OKRs should take you minutes. If you don't know what you're doing, or you want to communicate with more clarity among many teams, then you can spend more time honing them.
For example, here's how one company of a hundred people does it. Each month, each team, department, and chief officer spends one hour writing OKRs, and one hour reading everyone OKRs. Typically this is all fast and easy, because all participants have a good general idea of their own work goals, deadlines, and progress points, and the participants have good ongoing communications overall. All the participants are free to edit and polish their OKRs are they wish, based on feedback from other participants and based on better understanding from other OKRs.
OKRs summarize each team's few most-important goals, deadlines, and progress points. OKRs are quick, fast, easy, and light, which helps all the participants.
OKRs emphasize how to measure whether a key result is accomplished, and how to measure progress on it.
OKRs are intended to be visible to all the participants, so all the teams can understand all the top few goals.
If your teams are doing these kinds of ideas above, and communicating these among your teams reguarly by other communication approaches, then generally speaking you're already doing the conceptual equivalent of OKRs. Recall that OKRs are a concept, not a specific communication protocol (such as email or chat), and not a specific kind of interface (such as a task list or work board).
OKRs are different than team communication via messaging, email, and chat because OKRs provide always-up-to-date shared visibility and progress measurement.
For example, when a new person joins a team, then the new person can see all the OKRs, and do not need to dig through message archives, or email mailboxs, or chat channels.
In addition, OKRs are intended to roll up, so each team can have its own OKRs, which will roll up into a department's OKRs, which will roll up into the company's OKRs; this enables participants to quickly look at different levels of resolution of goals, which is very useful for balancing priorities among teams.
OKRs focus on the top few goals, deadlines, and progress points; task lists and work boards typically capture much more information, such as a total enumeration of all task items or work items.
OKRs aim to solve the problem of "how do we quickly communicate about teams' most important goals?"; task lists and work boards typically aim to solve the problem of "how do I capture every to-do item?".
Some web services are offering ways to blend OKRs with typical task lists and work boards, including ways to summarize goals, and track proress, and roll up task items and work items into the relevant OKRs. Teams can use these services to get the best of both worlds.
Yes. OKRs that are all-or-nothing are fine in practice, when you have ways to measure progress. For example the objective "Land a team on the moon" is all-or-nothing, and has progress indicators such as "Orbit a team around the moon", "Orbit a team around the earth", "Prove mission control performance during a crewed mission", and so forth. Each of those all-or-none items can have sub-OKRs, sub-KPIs, sub-metrics, etc. as you wish.
Explicit. An explicit measurement and explicit timebox work better than an implicit measurement and implicit timebox, because different teams might be using different measurements/metrics and different cadences/timelines/deadlines. For example, an engineering team may want to use uptime metrics and a quarterly cadence, whereas a sales team may want to use cashflow metrics with a yearly timeline, whereas a product launch team may want to use user engagement metrics with a launch-date deadline.
Yes. All OKRs default to be transparent, meaning they are visible to everyone in the organization. In practice, there might be very rare OKRs that are transparency exceptions, such as OKRs for maximum-security projects or maximum-secrecy research. Transparency and visibility build mutual understanding, and also can be significant for helping for inter-team goals, team-of-teams projects, cross-functional areas, and roll-ups.
Comments from: Hacker News 1 2 3 4 and related blog posts.
"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."
"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."
"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 (quaterly 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 strech 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."
"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."
"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."
Related:
- Wikipedia OKR
- The Art of the OKR
- How to make OKRs actually work at your startup
- Strategic Balanced Scorecard
- Key Performance Indicator
- The Fundamentals: Objectives & Key Results
- Quora: How do I write an OKR?
- How Google sets goals: OKRs
Posts:
Credit:
