If you're following this advice, you are either purposefully choosing goals that you do not know how to achieve, which is a problem, or purposefully choosing goals whose achievement relies on way too many externalities over which you have little control, which is a problem.
I'm not saying external factors shouldn't be considered, or that we should only set goals that are within comfortable reach.
Rather, I'm saying the uncertainty should be accounted for differently. It should be baked into our goals, not treated as if it only matters at the OKR level.
Imagine if you were to plan a sprint, and your story points did not factor in uncertainty at all. Then, you committed to a sprint size that also did not take into account uncertainty. But your stakeholders agreed that a 30% sprint failure rate was acceptable.
Now imagine baking in uncertainty into your estimates and then committing to a sprint size you can realistically hit. Add stretch goals if you want. Doesn't that seem more sensible?
Purposefully choosing goals that you don’t yet know how to achieve is one of the powers of OKRs; they’re not meant to be limited to project plan-style marches towards a known outcome.
Take the classic YouTube “one billion hours in daily user watch time” by the end of 2016, which was about a 10x multiple over their 2012 stat. There’s no way they knew how to reach that goal, but the objective helped them to align and constantly make small decisions in support of that goal (instead of other conflicting goals, each of which could be argued to be good for Google in a different way).
Did somebody in the room say, "We've crunched the numbers, and our best estimation is that if we orient all our resources toward achieving this goal and put forth our best possible effort, we'll be able reach 5x."
And then did somebody else in the room say, "I agree. So let's be extremely audacious and shoot for 10x"?
Either the first person was miscalculating or the second person was being unreasonable.
If you know how to do 4x, but think 10x is epsilon away from “best possible”, you set a 10x objective even if you only know how to hit 4x.
As per the spirit of parent's question - either you're assuming something impossible, or you're setting a goal to achieve something that is possible (in which case why haven't you scoped it out clearly & sanely).
I think the analogy to a sprint plan is perhaps misplaced: the point of an objective is not to break down the work for planning purposes but to capture the strategic imperative.
Instead it’s that you set targets in the various key results, normalize them to a 0-1 scale, and if you’ve achieved an average of 0.7 over all of the key results, then that would still be a measure of success.
We do the latter and there is deep suspicion if you are hitting 100% on your OKRs. I always thought of them as signifying direction versus destination, is this incorrect?
Over the past 20 years that describes the vast majority of my goals. That's how you get paid big bucks - by taking on goals you don't know how to achieve, and then achieving them, or at least making a good enough try. Colloquially this is known as "problem solving", and hard stuff is expensive.
There really are some metrics that are strategic. But when your manager is asked to have 20 OKRs just because your manager has to have 20 OKRs and then you get asked to have 20 OKRs that is a distraction.
(In terms of strategy there might be one thing or three things you REALLY need to do.)
At one place I worked I was expected to create OKRs for my own personal and professional development and I felt offended by it because it was out of phase with my own needs.
Today I do a lot for personal and professional development and it is highly strategic, it's motivated by being better at what I do for work but also about getting the social opportunities I want and where I think technology is going over the next ten years.
Because it is strategic I am continuously finding that a project I started a year ago has given me exactly the resource I need right now for a situation I had no idea I'd be in.
Like hell I need to fill out a form in some artificial format for my boss about it.
This has been a point of struggle lately in my career; I know exactly the source you’re quoting and it’s paid dividends in my own ability to deliver and manage teams when I was an engineering manager
I’m finding a lot of frustration lately-having intentionally gone back to working as an individual contributor-with jobs where a leader takes on a massive undertaking of a task, or decides to start picking at a particularly nasty process/business/engineering scab, making it my priority, but giving no guidance on what “done” means or looks like (aka: acceptance criteria). Even when I blatantly, directly, and simply ask.
It’s difficult to know where you stand in terms of an OKR deliverable when you have a definition of “done”, but stakeholders are preventing any kind of hand-offs or closure to the project when they have a different definition of “done” but are avoidant in sharing what it is and where your deliverable comes up short.
Got an open-ear and open-mind on ways to better ‘manage up’ on this tangent.
It's an essential part of integrating with a team that you are able to get good requirements. Maybe you can get them to express requirements in a way you like. In some cases I've gotten written requirements that were inadequate but developed some process like "ask a few questions", "write my own version of the requirements and send it back for approval")
In the situation I’m dealing with presently, I don’t necessarily need this stakeholder to take any action other than make a decision on two similar options with different outcomes only they have the business authorization to make.
For my part, I’ve documented, and shared documentation with the stakeholder, and had multiple sessions with them about requirements and next steps to complete this project, and asked them repeatedly if there was anything that prevented us from moving to the next step. Each time the answer is no. By every measure I’ve tried so far, it seems there’s no question marks or missing inputs from me on actually executing the next phase of this work, and the stakeholder understands the options/risks/trade offs by their own admission…
Yet when I ask “then what is your decision on these two options for the next step?”, we end up going back to questions if the previous requirements have been met-which we already found a consensus that they were and the stakeholder suggesting we aren’t ready until those are met.
a forced analogy: it’s like you and your friend are working together to build a custom bike, your friend knows a little about bikes, but asked you for help because you really know bikes, and after you finish putting the bike together, the last thing to do is wrap up the handle bars, so you ask your friend what color grip tape they want, but they start asking you if the tires have been inflated.
All too often I’ve taken the other person at their word: “we want to reduce time to approval”, “we want all these features”, “we want to reduce operating expenses”. However, when time came to implement a plan to hit those goals, it turned out those weren’t the actual objectives.
A combination of sales, negotiation, and an attempt to identify the actual underlying need (belonging, recognition, autonomy, etc) has increased the hit rate.
But, at the end of the day, we’re monkeys wearing pants trying to squirt ideas at each other via flapping meat. Let’s just be amazed that communication between people can happen at all :)
If that doesn't work then you have three options: escalate to their boss, live with it, or quit.
Cycles are why people are afraid to get lost in the wood at night.
Theseus escaped the maze of the Minotaur because he had a tool to avoid cycles.
You need to document cycles as soon as you notice them and be polite but firm and ready to have the same conversation over and over again, documents in hand, making it clear that there are a few difficult issues that aren't staying resolved.
Sometimes you need a written and/or practiced explanation of something difficult that you or your customer have a hard time remembering.
Sometimes the customer really wants things that are contradictory and that's a common situation, in the long term the contradiction is resolved, sometimes you might be in a "pick 2 out of 3 situation" and might be able to try a few different pairs of 2 you can live with.
It is is one thing to be in a state of confusion that is tractless, but frequently there are a small number of persistent problems and those have to be kept on the surface.
Is this a decision that could easily be reversed? If that's the case, then if a bad decision is made, well it could be reversed pretty quickly. If this is the case, then I would just try to gently recommend the option that seems right to you. You might even suggest to the stakeholder that it's their idea and give them credit for coming to a reasonable conclusion.
You've solved the software engineering problem, now you need to solve the social engineering problem.
During the year (or quarter), your picture of what's useful and feasible becomes more and more precise. So your OKRs that you wrote at the beginning are worse than your current knowledge of the true goals. It's really bad to cling to your old misconceptions of what was important when you wrote those OKRs.
Finally, the desire to quantitative-ize every OKR is beyond harmful. Does your organization really not care about anything qualitative? Well, it shows in your products. And no, you can't measure quality by surveying your users and averaging the results.
You shouldn’t stick overly stubbornly to bad goals, but any updating of goals in the time period should be carefully considered as well.
I agree with you on the quantitative mania. I'm not that clever but even I can frame almost any bias so it's "backed up by data". If "listen to the science" is today's new religion, our "evidence-based decision" is an opinion in disguise.
If it does show in the product, shouldn't there be a way to quantify it?
It seems to me that the problem with OKR is that it's hard to formalise goals, the same way it's hard to formalise requirements when designing a product.
Does not imply it's not desirable to do so.
The next iPod or iPhone won't happen due to an OKR.
I definitely agree! Seen more than one company go down from this. I guess part of the issue is that established companies have a tendency of being too risk averse to dare chasing the global maximum.
I think what they are arguing is that businesses sometimes define objectives 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 and each pulling the business in different directions.
I agree that it is quite business language heavy. My understanding could be wrong, take it as a non-business guy's interpretation.
Objective: End the war with the Machines
Key Result: Neo is delivered to the Source so he can set us all free
Q. What's missing?
1) Rescue the Keymaker from the Merovingian
2) Blow up the power station and the emergency backup to disable the alarms
3) Infiltrate the building and have the Keymaker unlock the right door
And without that third bit you're lost. It's good to have a goal, it's good to have things you can check to see how far along you are, but you need to map out what must be done to achieve forward progress also. A lot of companies confuse the journey for the destination and set OKRs without mapping out how that may be done. Or maybe they leave the how to lower levels, who I guess set OKRs of their own and delegate the how to their subordinates, etc.? I dunno.
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?
A boss says "I want you to make me more money!"
When you ask "How?"
His answer is "Your job is at stake."
And when it all hits the fan, blame and fire the "bad apples" (low level employees), not the people who created the incentive system that turned thousands of low wage earners into "bad apples".
2. How do you grade people fairly ? Most companies will not be able to resist connecting your key results to commission/bonus. As a result ,employees setting truly audacious goals will be disadvantaged. If it is truly audacious, it means it has a smaller chance of success. Sooner or later, people will try to game the system if they don't want to be hurt by the system.
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.
I think you can sum up some of this blog post as discussing the difference between strategy and tactics. OKRs are tactical objectives that help you achieve your strategic goals. Is that a fair summary?
Other observations about OKRs that I would have liked to see included are:
- The article calls out how Measure What Matters and OKRs only work if the key results are legitimate metrics, real numbers as opposed to boolean flags: continuous system outputs. But at scale, some subteams just put their tasklists into OKRs as boolean KRs, make up a nebulous objective to cover them, and reimplement the same flawed systems that OKRs were meant to replace.
- Often OKRs are scoped beneath the team level to the personal level. This is very dangerous. The unit of production is not the individual but the team. You tend to create perverse incentives when you go one level lower, “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.” Tutorials just don't have this perspective!
- 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.
Agreed. My very first impression of OKRs was to see tham as business level User Stories. You state a desired outcome with enough detail to be clear and then get out of the way to let skilled people solve the problem with a little creative autonomy.
In the same way OKRs can float off into mission statement territory, they can get rendered ineffective in the other direction by being too prescriptive.
I'd like to see a follow-up article titled:
"Stop Letting OKRs masquerade as Work Breakdown Structure"
While I agree that any distinction of strategy vs tactics was missing in the blog, I think the ORKs are too high level to qualify as tactics. Tactics are directly actionable. In that light, he may be wrong about OKRs not being strategy - they just need someone to figure out the HOW for each one and then it should all come together.
But I don't think it'll work.
Once you see it happening to you or a friend you can begin to cast backward through your memory to identify other times when the same thing was happening but you just didn't have a name for it.
I'll throw quarterly & yearly performance reviews on to that pile.
"Objectives and key results is a goal setting framework used by individuals, teams, and organizations to define measurable goals and track their outcomes. The development of OKR is generally attributed to Andrew Grove".
the problem with these approaches is that people more easily follow a checklist and don't take time to understand the principles or even just do a trial and error approach to it for the sake of moving forward, so you end up with a roadmap masked as a KPIs list with non measurable KR and people being really confused about what's going on.
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.
It's simple, it just works, and I think this guy is just trying to be contrary for the sake of it.
- Non-SMART formulated 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.
- The executive team does not publish company-wide objectives in time for downstream teams to build their own objectives upon them, so 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.
- Lack of responsibility, nothing happens if you fail to meet your KRs. Also nothing happens if you beat your stretch goals btw.
- Reorganizations every six months make a year-long planning cycle meaningless in the first place.
- The whole company failed the planned OKRs for the year so badly that the executive team just decided to not mention them ever again "for morale reasons". (True story)
- And many more.
Don't get me wrong, OKRs can be a powerful tool in small enough teams where the Principal-Agent problem is not yet rearing its head in force. But to say that it "just works" and has no problems is simply false.
It's also become a bit like "Agile". Take ten companies doing some sort of OKR process, and I bet most of the overlap is in name only.
If we cannot simply set goals for the next 3 months with any diligence, what business do we have setting pie-in-the-sky 5 year plans?
This is pretty common in growth companies and new leaders that are still finding their rhythm for managing an executive team.
Sometimes there's absolutely value in the OKR process even if it's abandoned mid-game, such that it forces people into a mode of thinking and organization that helps them coalesce their ideas into more manageable and actionable plans.
But then what does it mean if you didn't hit your numbers? Was your progress along the right path? Are you closer to being able to hit targets next year? Those execs couldn't tell you. Hell, even if you did hit your numbers, it was hard to get any sort of answer about how that tied in to what the company wanted to do next.
If you are working against a goal for 3 years, no wonder it becomes your defacto strategy.
Come up with an objective, innovate in order to achieve it, keep yourself from going too far off track by tracking the results against thresholds you decided at the beginning (rather than adjusted or invented to match what's actually happening.) And somehow resist the temptation to invert the flow, where people justify what they're doing as fitting into an OKR rather than the OKR motivating their choice of what to do. (That's the part I'm getting wrong right now.)