Contents:
- What is OKR?
- What is an objective?
- Examples
- What is a key result?
- OKR systems
- OKR quotations
- FAQ
- 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.
Comments from Hacker News and related blog posts.
"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."
"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."
"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."
"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”."
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:
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent