OKRs Are Bullshit
blog.appliedcomputing.io
blog.appliedcomputing.io
We ended up achieving our goal by greatly reducing the quality of all images to almost nothing, such that they looked like a rorschach test, and measuring performance on a fast internal network. Management was so happy they bought a white sheet cake and had the graph of improvement drawn on it in icing.
The next quarter, customers started to complain and a new OKR was set to improve image quality by 50%. So we just reverted all the prior changes, and once again victory was declared.
This company operated like this for the entire year I was there. I finally had to quit because I started to question my own sanity. Ever since that experience I have PTSD whenever someone says the word OKR.
We're also getting very close to a "no true scotsman" argument. If something has been tried several times and the outcome never came out as expected, maybe there's something more to it than that it wasn't implemented completely right. Not everything that's good in theory is useful in the real world.
I mean, you are lucky they were not into SAFe or you might have quit the field altogether.
1. Frequently you can't know ahead of time what is a good number to have. You can only pretend to know what is a good number, and people do pretend as if it can be done and everyone plays along with this bs.
2. You can get to that number in multitude of different ways, in many cases by not actually making the product better.
3. You might in the middle of progress realise that the path should be completely different, but now you are tied to that OKR.
They just don't make any sense at all, and at best they can take focus away from what should intuitively matter. "I know I should do X to actually benefit the product, but I do Y because this is what gets us to the Key Result.".
OKRs can be actively harmful because they take focus away from what matters, and you can't put a single number on those things.
OKRs when planning also focus you to plan poorly, again instead of figuring out how to conceptually make the product better, you set those arbitrary metric restrictions which can only stray you away from what you should actually plan to do.
it just means you think you are smarter than person who decided on Y, which may be true or maybe not true regardless of OKR process.
> You can only pretend to know what is a good number, and people do pretend as if it can be done and everyone plays along with this bs.
there are many business decisions based on educated guesses, not just OKRs.
The whole premise of deciding on Y or the methodology how it was decided was invalid in the first place.
> there are many business decisions based on educated guesses, not just OKRs.
Yes, but you can present ideas much better with simple words than forced numbers. You should take educated guesses, but you shouldn't force things into some sort of measurable numbers, unless they specifically make sense in that context.
Essentially goals and tasks should be what they are, specific to those goals and tasks and not forced into some specific format of a measurable number.
this is absolutely hilarious given the title of John Doerr's book responsible for introducing OKRs to the masses
a clear sign of an implementation error
You can measure very specific and repetitive things, e.g. some sports statistics, but even in sports it becomes obvious you can't put a number on everything.
A single number just can't represent the result of something that matters. It's like trying to hash a part of what matters and then trying to see if the hash generated is higher or lower.
I just fundamentally disagree with this. One of the most famous examples is the youtube team working towards a billion watch-hours in a day. Does that not matter to youtube?
And if it's impossible for something that matters to be represented by a number, what does matter? I'd love to hear examples of what matters in your companies
1. Why are you doing this? Is it to get more ad revenue?
2. Considering this metric, how do you know that the extra hours you are getting is the kind of traffic that brings ad revenue? Maybe it's children or folks from poor country. Maybe it's actually costing more than it was previously.
3. Maybe you are getting the same people to watch more, but it won't make them pay more. You are just increasing your server costs. And making those people addicted to your platform.
4. Maybe the algorithm that you produce is actively harmful to people by making them take too much screen-time leading to potential regulations from the government.
5. Maybe the content you provide is of really low value, and in the long run will make your audience really low value.
6. Maybe you just pay too much for that extra traffic, so it's not worth it.
Very simple example when doing ads. If my goal is to get 200% more clicks, and I have been so far advertising in US only, I'll just now make the destination to be India instead. I will get tons more clicks, but I will get less payments than before.
> And if it's impossible for something that matters to be represented by a number, what does matter? I'd love to hear examples of what matters in your companies
If you want a number, profit obviously matters, but everything below that, can mostly be intuitive unless it obviously fits some sort of numerical idea. In such case building a great product matters, but it's much more difficult to measure what makes a great product, so you need this intuitive discussion and people who have great intuition for building a good product. Profit will follow performing this strategy.
You should measure, monitor, use data to be informed and analyze results, but you should not have these as primary goals to strive for. You should use this data to improve your intuition.
And then we brainstorm all the constraints and potential pitfalls and finally we think what the reasonable amount of watch hours is based on those constraints?
E.g. we first run by the constraints that these watch hours must still keep the same base level of ad revenue per watch hour, demographics proportions must stay similar, etc?
I do feel however despite that there will be quite many different ways to game this number that you couldn't think of before hand. And there's also a spectrum of "level of gaming". There's a spectrum of non obvious gaming to very obvious. So whoever is striving towards that goal will still be incentivised to find the level of gaming that is not obvious enough for everyone, but might still be fundamentally not good.
So then you have to spend a lot of your time to make sure this OKR couldn't be gamed, but you still probably won't be able to stop it from being gamed even if you spend very, very much time on preventing it.
If it is too much likely to be gamed than perhaps it is not a good metric or it needs other metrics alongside. If everything we can think of in terms of measuring if we get to our objective is too easily/too much game-able, then perhaps the objective needs revisiting.
Having things gamed to the extreme is also not such a big issue usually because in the end you also watch things like profit. During the ZIRP frenzy that got a bit forgotten in some places, so gaming was perhaps more of an issue. You can also switch objectives and measures if they turn out to be wrong/not useful.
I just don't buy that this does the same thing OKRs do.
Cross-org alignment
Public commitments and priorities (ie ability to say no to other stuff)
Measure progress/success
Often the nonmeasurables eventually show up as measurables, but after too long a time delay to fix mistakes. So you could alienate creators while juicing the current numbers, and find a few years later that all the good content has gone elsewhere.
The above didn't happen at YouTube, but it's the sort of thing that can happen. An example of something that did happen: Facebook found that rage-bait political news created a lot of clicks, but led to people getting fed up and leaving the platform after a while. By the time that was reflected in the traffic stats, it was too late to get them back. But fed-upness wasn't something they could easily measure, so it got ignored.
There is no way something that matters cannot be somehow "measured", otherwise how would anyone detect the thing in the first place? Or am I misunderstanding you and this is about things that matter but are not known to matter?
I didn't think of it at first, but actually that's Goodhart's law.
Is that my bad luck with the corp then?
Because it's a combination hundreds or thousands of people incorporating this system. Are they all incompetent, or does this company in particular have incompetent people?
This implies that if you were replaced by someone else, they would inherit your OKRs but not your performance management including your performance reviews, personal development goals and career aspirations.
One way to do this is by rating performance based on both contributions to OKRs owned by the individual as well as those of others and rating performance as high only if both are exceptional.
It goes to show how utterly insane management types can be, and how they need to be hemmed in with empiricism and held to account for wasting time.
More people should learn from Deming instead: https://en.wikipedia.org/wiki/W._Edwards_Deming
SAFe is one form this counter-force can take, characterized as using a lot of complicated verbiage which makes it an easy sell for consultants.
I'm not saying this is wrong. Maybe quarterly plans on a fundamental level is what companies in our market economy is. Perhaps we shouldn't be agile on a company level. But let's at least be clear about what the strategy is.
https://en.wikipedia.org/wiki/Stakhanovite_movement
I have a vague understanding of what the movement was, but I'm unsure how you are relating it back here.
Are the degenerated attributes related to the "puffery" and "theatre".
Stakhanovite is the most benign fraud (pooling productivity). There was a Microsoft engineer that outsourced his job to several engineers in India. I bet he seemed very productive.
There are less benign frauds. Boeing and their suppliers let quality slip. Wells Fargo met account opening goals by opening accounts without asking the customer.
I think, unfortunately, the pendulum in American corporate politics is swinging away from Deming, at the moment. Growth through making good and reliable products is getting difficult to sustain, which leads to the capitalist/financial lens to be applied to problems. The results are predictable: outsourcing, and "slogans, exhortations, and targets for the work force", and generally a lack of leadership or vision for the product. Better for short-term growth to be worse but cheaper.
I can easily see from an employee's perspective, they could react like you, "why the hell am I doing page speed shit, we're already fine, this is bullshit". Especially because the entire field of SEO sounds like total random guesswork to a lot of engineers. But I expect the team to have the common sense not to completely fuck up the product in the mean time and/or fake results, even if the metric we're measuring and improving is page speed. I don't think that's an OKR issue, that's just not giving a shit issue that no management approach can solve (on both sides, since the management spent no time explaining why page speed is important to improve).
Easy to say, but hard to do. I have also had my OKRs dictated to me by upper/middle management. Sometimes I think I was the only one in the room who read Measure What Matters.
There is no replacement for good people. Not in leadership positions, and not in IC positions. Recruit for strengths, hire for culture, train for gaps. No process, least of which OKRs, can make up for recruiting weak people, people who don't fit your culture, or people not interested in personal growth (i.e. filling gaps).
Also, every time some new-manager-on-the-block decides that we have to implement "agile" everything just goes downhill from there.
I don't even know what "agile" means anyway, what about "nimble" or "dextrous" instead, as long as people are not understanding each other, they all mean "let's fuck shit up every 2 weeks"
Because that’s what it feels like trying to manage expectations from management va stakeholders whilst also having daily meetings to discuss our effort and how we can remain lean and agile all the while building up tech debt
He was staring at me as if they invented penicillin and I was too dumb to appreciate it.
My struggle at work is usually _reducing_ my standards for quality, performance and customer satisfaction to match those of management & colleagues, because caring more than everybody else is a recipe for burnout.
These type of people really need to work on their own startup where they can dictate the quality of work vs selling the product. It's the only way they will understand how to make the compromise between high standards and other long term product decision consequences.
We'd spend weeks in meetings coming up goals and things we could measure, and end up with something like, "increase foo from X% to Y%". Here, "foo" is a placeholder for something or other, but the X and Y are not. We would literally leave them as variables, under the impression we'd fill them in eventually.
A year later, we'd look at them again and see that we never filled in the numbers. Then repeat. It was pretty wild.
The fad wore off before we agreed on how to write OKRs and we never spoke of it again.
If a game is setting me up to fail, I don’t want to play that game. My productivity has gone in the toilet ever since our management started pushing their brand of OKRs.
In all the teams I been in we have whiteboard sessions where come up with ideas. Then we slowly move ideas into the ones we want to work on, our Objectives.
Then for those Objectives, we set a qualifier to determine if that thing was done, the Result. Next we rank these Objective/Results by priority and we remove ones that will probably not get done, boom OKRs. Not difficult.
In my experience, these ideas - broadly detailed processes, not just OKRs - are pushed very strongly by ambitious people who don't want to actually work or get good at something. So they push the idea that we should have processes everywhere that solve problems on their own.
Just because something was formulated once, does not mean it's not evolving and not improving with learning and new findings. It's nearly 30 years old at this point. The SCRUM guide is vague, and only provides basic roles, event, and definitions. The SCRUM alliance explicitly state that SCRUM is a starting point, and following the Shu Ha Ri principle a good team will eventually transcend the starting point. But you need to be disciplined when starting and learn it as it is defined.
In my experience the main issue with SCRUM is actually with the team members. Either they're not dependable or too low performing to be give the freedom and self-management it requires to succeed, and management is not willing to foster the necessary environment and/or get the right people.
I don’t think anyone would argue that investment banks have great culture from the outside or be motivating their people by the virtues of their higher purpose etc. but the incentives are there, and they work very effectively to get people’s commitment.
Just imagine operating a hospital on the maxim that you 'only' need good people and process is evil. I know this is a bit of a straw man, I just want to make it clear that eradicating all process in favor of 'good people' isn't the answer.
So what is? A good process can really help a lot in working together. I've worked with a mix of medium to good people, who continuously adapted the process to make it work and it helped, a lot. Medium people can do good work. And good people don't have as many obstacles.
It is essential that the people who are responsible for executing also have the mandate of adopting or at least adapting a process to their context. A good process can save a lot of brain cycles and prevent all kinds of organizational waste. Its like automating away a lot of the overhead of working together and achieving goals collectively.
But if the script doesn't work for a use case or with certain parameters, you better change it or just not run it to a fault.
Everyone can move around the tree to see which team is responsible for which task and how any task on the whole is progressing.
On the other hand, I've worked in such a disconnected 'bottom-up' org that after about 8 years, finally the CEO told us he didn't like the business model we had been developing and specializing in. The end result was like 90% of senior devs resigned. We were clueless. Maybe a little goal setting would have helped?
Performance evaluation, a lot of the time in corporate environments, but especially in engineering, has no such consensus. It is not even possible to achieve such consensus when people are not clear on what they are supposed to do, which is because the business is not clear on what it is supposed to do, which is actually a good thing because we learned, decades ago, that making year-long plans in an attempt to achieve that clarity ended up ossifying businesses instead of letting them be responsive to market conditions.
So no, most businesses are not like hospitals, where the notion of "responsive to market conditions" is completely ludicrous when demand is inelastic, prices outpace inflation year-over-year, most customers are dissatisfied with value-for-cost, and there is almost no accountability to the customer with the rare exception of malpractice suits.
No matter how hard you try you will never get the best people, and may not even want that. Sometimes you just need soldiers and soldiers need process.
You cannot hire only best people because that is not possible. There are too many companies competing.
Only thing manager can really do is to fire toxic and highly underperforming employees asap - this is basically only thing I expect from a manager.
As much as anything else, standardization & bureaucratization & Taylorism are most generally forces of stability & predictability & control. A well.managed company does not go extra miles. It goes exactly as many miles as the company said it would. If everything is working well.
In bad times and in desperation, extra miles are what keep things together, what plugs leaks and patches tares.
I believe so strongly in extra miles, in going overboard, and pouring in extra. In making things better than they had to be. But these extra miles are, in my view, owned & done by individuals. Extra miles are what competent happy craftspeople do when they are enjoying their craft; embellishing & exceeding.
The extra mile is almost always a person's own thing. It is almost never something management or the org can pursue. The org can set conditions: create space & permission & happiness. And when these positives align, then we see real extra miles.
> There is no replacement for good people.
And giving them time and space to put in some extra miles.
The problem is that organisations that feels the need to import management dogma's are trying to avoid doing the hard and potentially ego-destroying for upper management task of examining why they arent getting the performance from their mid management they want, by simply copying in the surface aspect of someone more succesfull,
Add to this that there is a surpricingly small number of people both in management and programming that have ever managed a project from cradle to grave at all let alone done so successfully and you get a culture of management consultants that have never been with a project long enough to watch the pretty facade crumble diue to a lack of solid foundations.
btw, agile is not a management system, and a tech worker who thinks that it is raises a huge red flag to me
That reminds me of a quote on overemphasizing quantitative data:
> But when the McNamara discipline is applied too literally, the first step is to measure whatever can be easily measured. The second step is to disregard that which can't easily be measured or given a quantitative value. The third step is to presume that what can't be measured easily really isn't important. The fo[u]rth step is to say that what can't be easily measured really doesn't exist. This is suicide.
> It is a short, fatal step from the statement, "There are many intangibles and imponderables that we can't put on our computers," to the statement, "Let's measure what we can and forget about the intangibles." This step poses an even greater danger to us in the future than in the past.
—Daniel Yankelovich, "Interpreting the New Life Styles", Sales Management (1971)
> The tao that can be told is not the eternal Tao
“The Tao” here means “the rules / way to live your life”. Essentially, the point is that if you try to write down a set of complete rules for how to act - either in life generally or at work, well, that ain’t it.
This is always my problem with OKRs. They’ll always inevitably lead you away from what you actually should / need to do in a given moment if you were in tune with your wisdom. Instead of trying to codify what leaders do, we should practice staying present to what’s actually going on and practice wisdom - for whatever that means in the current context.
Yes, another way to say it is that the map is not the territory.
PS, I would personal interpret tao to be something like 'life' or 'the universe', rather than rules.
What I take away from that chapter is to incorporate wu wei¹ into your actions. It has helped me tremendously.
Great rulers are hardly known by their subjects,
Then come those the people draw near and praise,
Then those the people hold in fear,
Then those the people revile.
When one lacks trust, one finds no trust.
Reluctantly, without boasting;
Perform actions, accomplish deeds;
The people will say it happened naturally.This is a summary of science and medicine practically since the Enlightenment. Is it a wonder that anti intellectualism is so rampant in North America now?
Intellectuals are assholes. You can really only trust the handful of us who defect, and even that has limits.
Writing code & making products is extremely multi-domensional. And most of these dimensions aren't easy to rank.
Look, I really appreciate the photos we have made on the back of science &s experimentation. But in the act of creation there seems to be countless intangibles, little directions & flourished that build to set a very subtle implicit course. I see so much compromise for only doing things right now that have direct immediate results, and the people who argue and push that way have always seems like bullies (sometimes willfull sometimes ignorant).
I really think you should step down off that ledge you are on, willing yourself to abandon. It doesn't seem right, it doesn't seem justified. You yourself are using a hard line to disregard & discard (which seems to be what you are apoplectic over), which is also ungraceful.
There is so much more to life than that which can be measured.
It's the same thing with CEOs. I don't remember which book it was, but it showed how the CEO changing didn't matter at all but was just natural market cycles.
Consider coaches of two sports team: if they're both equally good, their effects wont be noticeable from the performance of either team.
In a competitive environment, leadership ought wash-out if its any good. It's only bad leadership which will be noticed.
Modeling reality properly is hard. Cargo cults are less cognitively expensive to establish.
Every serious industry since at least the days of Toyota's rise has used metrics. I don't think the tech industry has ever shown me something that has improved on what traditional industries use. The only change is the underlying processes of the tech industry are too chaotic to harness (what management process gives us Google? Given that we have literally 1 Google do we have enough evidence to reject it being built with a different management style? No. On the other hand Toyota could only exist with Toyota's management style.) and so any amount of management quickly becomes futile.
Time will pass, we'll hit the boring part of the S curve in processor improvement and then management culture will start to be a factor. And the industry will be a lot more boring, less growth focused and care a bit more about consistency and reliability.
I do think it's worth remembering that John Doerr's implementation of OKRs at Intel actually did include binary goals. I remember reading the book and seeing "complete design and begin fabrication of chip X by Y date" (I'm paraphrasing because I don't feel like going through the book to find it). Yes, the higher-level objective was "establish Intel as the top chip maker" but that, by necessity, included "actually make the chip."
You are asked to provide OKRs, everyone else are doing it and the only way not to do it is if you start your crusade or I guess just say "no" and see what happens?
Next, I'd say it depends. Sometimes an org is new to OKRs so gets pretty zealous about using it for everything. In this situation, assuming the org is trying to learn, the management needs to go through the pain and figure out what does/doesn't work.
Sometimes there's enough braindead thinking in the org, in which case, there's not much to do but I'd argue sending ChatGPT nonsense is probably worse than telling everyone OKRs are BS. You're better off doing your best and hoping for the best. If you're caught engaging with management initiatives in bad faith then I don't see it ending well.
Top management defines a strategy for the company.
Each department (commercial, marketing, product, etc.) create department OKRs from the company OKRs.
The year/term starts.
Each department comes to the implementation teams (product, IT, BI, support, etc.) with a HUGE list of poorly defined objectives or tasks.
The implementation teams only have limited capacity and can only deliver maybe 15-20% of what everyone wants. No one actually thought of checking if the objectives have any reasonable possibility of being delivered at all during the term.
Optional drama to decide what's going to be actually worked on might happen.
When the term ends, and if communication isn't a disaster between the departments, some MVPs are delivered.
A new term starts, and either the previous objectives are continued, or they're simply forgotten in favor of new ones.
Rinse and repeat.
edit: formatting and typo.
You do that by having the entire organization's O and KR roll up and cascade down. My Objectives directly roll up to my parent organization's Key Result. My parent org's Objectives rolls up to their parent's KR, and so on to the top. Then, you have the top-level check downwards if the sets of OKRs still make sense in their entirety.
Unfortunately, I have never seen any organization I was with ever do this...
That 70% figure is simply to suggest that you should set stretch goals. One good thing that can come out of setting outlandish goals is that it forces you to take a revolutionary rather than evolutionary approach. I would not say you should do this for everything, but it seems to have worked for Google.
How does it being an OKR make the communication more effective?
(Note: I mean this literally. I’ve never worked in an organization with OKRs, all I know about OKRs comes from HN. I want to understand your point better, not criticize it)
You get to "talk" to the enire team perhaps a once a quarter, in some town-hall event where most people aren't really listening, and maybe send a mass email every now and then, which no-one reads. You get to talk to your immediate management team more often, and they talk to their reports, and so on, but of course whatever message you've had is greatly diluted, sometimes comically so, like in a game of telephone.
People are not robots, their understanding and communication is very ... creative. And context-dependent. And self-motivated. So that's not effective. Most people need to engage with the message you have - your priorities, changes in direction, specific goals - on a daily basis. Otherwise you are not really giving them any direction. And so you need some device to enable that. And OKRs are a part of the solution.
Have you considered seeking assistance from professional counsellors?
But seriously, I don’t understand the OKR cult. The whole “update and align” thing is worse than any religion.
Or do people really wake up each day and ask, what am I supposed to be doing at work?
Of course, in practice, your mileage may vary.
My experiences with OKR's is that they are an cargo cult practices covering the lack of good coherent strategy, the exception to this is things that looks like OKR's but evolved differently within the organization rather then being adopted top down by a set of management consultants.
It really is just telling them and checking once in a while how it’s going.
I guess change requires you to be able to argue for change, and against the status quo, and management culture is the opposite of this.
Whilst the super-structure of management culture exists, all these systems will be corrupted to fit it. They aren't fundamentally engaging with any real-world incentive structure.
I'd say most people are adverse to change. Probably key people at c-level and some people across the hierarchy are not.
I'm talking about when there's been a plan established, and when that plan needs to change. Since managers are the implementers, in my sense of the term, not the planners -- they are highly change-adverse.
Whereas plans are implemented "on" the people who are best placed to say change is needed, and managers are typically unable to incorporate this feedback. Perhaps because they cannot persuade the planner c-suite above that change is required.
My underlying point was more about how organisations need to be analysed in terms of these incentive structures, say, in more Machiavellian terms -- and what happens with "Manifesto types" is they have no analysis of this, and instead come up with various dogmas that just become corrupted to align with organisational practice.
I think it's indeed the case that the higher up the hierarchy you go people actually tend to be less averse to change. But also that they do not receive feedback from the people doing the work that can be extremely useful for directing that change, and so they end up sticking to plans that are suboptimal.
At the extreme, people in management can be dogmatic and deaf. But often, they do understand the need to listen and update their plans, and that's just not easy to achieve.
The best orgs and managers find creative ways to enable this bi-directional exchange and let their planning benefit from the input of the people who engage with the work day-in-day-out and have the domain expertise and fast feedback loop.
Here are the biggest mistakes I commonly see.
1. Use OKRs are for quarterly or year targets. No, OKRs are for managing big changes to things. Never for Business as Usual activities.
2. Require every team to write OKRs for every quarter / interval. See number 1.
3. Focus on the Key Results instead of the Objective. If the Key Results can be achieved without achieving the Objective, that's a broken OKR.
Overall, I think OKRs are a tool that has its uses but its misuse causes far more problems than its absence.
Update: typos
So they all work as well as they can depending on what your situation and goals are.
Only gets you so far so. And needs everyone being aware of customer needs and requirements.
I've had to remind people several times not to apologise for "causing chaos" when the outcome of this supposed chaos is that the project was successful. The purpose of your job is success, not the perception of others that their charts lacked forewarning of all the unknowables needed to successful execute anything.
Chaos in many cases is just what you call the experience of looking at a chart, or a model of any kind, when you're familiar with the reality it's supposed to depict
I think it was Jim Collins in Good to Great starting with the idea that it's super important to "get the right people on the bus...and the wrong people off the bus". Which he expanded to the idea that motivated, skillful people don't actually need that much management, and that it is the mediocre and worse performers that do.
Team topologies as a way to design your organization is a good start, TPS for processes, but with really taking to heart the kaizen and autonomation parts. And things that maximise autonomy and facilitate communication.
* projects with fixed time and variable scope, look at Shape Up by Basecamp for one example, or MoSCoW method for a simpler model
* giving team the ownership and autonomy
OKRs are effectively a quarterly negotiation to get alignment across teams so that large, complex, projects get done on time.
They create accountability and the ability to escalate up the chain when a team you have a dependency on isn't prioritizing what you need to unblock your project.
Generally, if you think OKRs are bullshit, it means they're being applied at a too granular level, or misapplied in an organization that doesn't require strong collaboration across team or org boundaries.
It "seems" easy and obvious when you're a leaf node how a team, org, company should be run and coordinated, but when you actually try and do it, and lead, it's nowhere near as easy as it seems.
OKRs, misapplied, suck. But there has to be some way to get large groups of people to align on specific targets. Effectively something like them have to exist.
There is a heavy lifting issue hiding behind using OKRs as a tool: you need to build an organization that is able to held teams accountable, and has a working escalation chain.
The prerequisite for OKR is that your organization is driven by objectives which cascade from C-level down to teams, and then all the way back via feedback loops, instead of VPs and directors micromanaging every link of the chain on the go. Drive-by style of objective setting, when things get randomly thrown at random teams, is another problem that needs to be resolved first.
Your OKRs will fail without building this kind of management culture. And you’ll be surprised how many orgs are not working that way, and insane amount of resistance people in the org have when you try to implement these (logically efficient) practices.
If you don't need to improve comms or prioritization then OKRs are of limited value.
It gives a good framework for going from business’ overall goal down to what are we going to do with this product the next four months?
I am asked to set my yearly goals in January and in December I have to argue how I met them. With okrs being tertiary you get a bit more manageable time horizon, while maintaining half year and yearly goals.
There are a few silly things about the framework, like how goals should be unobtainably optimistic and that phrasing of goals are not “improve user satisfaction”, but “I want to make the user cry of joy when opening product”. It’s stupid, but user stories also dictates silly phrasing.
But as the article and comment section shows, it’s no cure for stupidity or bad managers.
The fundamental idea of OKRs is actually useful: define a few high-level goals the organization wants to achieve, and for each goal define a few key outcomes that will materialize if the goal is achieved.
Good OKRs help with focus and alignement, particularly in large teams.
We can keep our OKRs simple:
- Key Results don’t necessarily have to be measurements, as long as it’s possible to evaluate them in an objective way.
- OKRs don’t have to be cascaded deep down to the individual level.
- No spreadsheet is needed either. You can just have your OKRs in Notion, Confluence, or similar.
- And OKRs don't have to be stretched if it's not part of the company's culture.
It's almost a malicious compliance attitude towards OKRs. Ok so the objective was to migrate, we got to 70%, well I guess then we're just going to stop doing any more work on it and cause an obviously preventable bad situation.
Of course the goal is 100% migration, and if you get to 70% migration you've done well but not hit your stretch goal, of course you're then going to still spend time doing it.
The real question is what is the alternative to OKRs? Is the author literally just advocating for not setting objectives? How do you propose to align what the engineers are doing with what the company needs? Are we suggesting we don't create metrics to measure our progress towards those objectives? Yes, there is some overhead in creating ways to measure the results, but the alternative - not measuring the results - is terrible!
This is a misunderstanding of 70%. The idea is 100% should be a very high standard e.g. increase revenue by $3bn this year, such that even if you hit 70% you'd be happy. I don't think it's specifically about stopping people slacking off and more about pushing people to think differently about the problems they need to tackle. For some things, this is really helpful (such as increasing revenue, customers, etc.) In these cases, if you reach the end of the quarter and stop doing the things that were aiming for that stretch goal, everyone should still be pretty happy with what they achieved.
It falls over when you want to do something concrete (like migrating users). It's not a stretch goal at all, it's just the requirements! The 70% target simply doesn't apply in the slightest to this type of work. It's not an argument against setting objectives, just pointing out that OKRs—as taught—doesn't work for this type of work.
Anyone can criticize anything. It takes genuine effort to create a new system that works across an industry - if you think you can do better, go for it - I'll cheer you on.
The belief that there can be is a root cause of bad systems like OKRs.
I said it isn't universal and cannot be universal.
"In this scenario that only I know the details of, here is my opinion, and my opinion is correct, which proves OKR is bullshit". You're simply stating your feelings, which nobody can discuss/examine. That isn't an example of anything.
Maybe it’s just me, but it seems to me reviews/goals are just ways to humiliate employees and show them whos the boss
As far as I can tell being "data-driven" is completely toxic to long-term organizational health.
But what if a company in question is a relatively big, 1000s of employees, and something is clearly wrong in the org. Both managers and employees are friends, seemingly competent, have all the explanations at hand and all the right excuses.
And nothing gets done.
focus is one of the most important characteristics in a startup, because time is too short to waste.
Problems come when a company goes public and now there's no single personal that can accept responsibility for technical commitments. This when a decision-making system has to be put in place, and maybe a way to assess how teams are doing, etc.
Maybe we keep introducing these approaches as an industry because it makes the worst cases less bad, even though it hurts teams and individuals doing well already because ultimately pushing the floor up makes a bigger difference. Not sure if that overall change is objectively better in total or only seems that way because the horrifically bad teams are what catches your attention.
Management involves soft skills and subjective judgement. You cannot eliminate that and pretending that you can kills companies.
Part of the OKR process is defining meaningful goals (Objectives) and ways of measuring progress towards them (Key Results). If you do this part decently, the metrics won't be stupid.
Once you have metrics that are not stupid and your team agrees that they will advance you towards your goal, it's kind of smart to do the work to move the metric. Not at the expense of everything else, but if this goal is deemed a priority, then it's OK to put it ahead of many other things.
Being blindly data-driven can be toxic. Not measuring anything means you might be flying blindly. I've seen it first hand.
There is a lot of value in combining objective measurements with sensible management.
The OKR was that everyone earns a certificate in this achievement frame work for stuff they demonstrated they know how to do. All I had to do was submit the evidence for them. Then I sent instructions to the rest of the department on how to do use the system as request their first certificate. Now they have me heading up the department effort until they hire in someone who's 3 levels above me.
70% of the key result is supposed to be a good, attainable goal, with 100% of the key result being the "stretch" goal.
> the response is always, in classic "no true Scotsman" style, "well, you're just not doing OKRs correctly."
No, there's a definition of what a KR is. And in my experience, most companies fail to set KRs, instead writing down what amounts to nothing more than a goal as it usually fails to be measurable. (A discrete boolean "we did it, or we didn't do it", isn't a KR. There's no 70% of a boolean. TypeError, operation is not defined for bool.)
> I guess my question is: if nobody in the industry does OKRs "correctly", why are we still trying to do them at all?
I have no idea. That'd be the bullshit.
If you're C-suite, enforce whatever goal-setting framework you want upon your company, but stop trying to make a silk purse out of a sow's ear.
like, whatever the CEO is doing and whatever the HR team is doing or whatever the sales team is doing are not processes that affect or should include the engineering teams in that way. The OKR process - in its unfalsifiable glory - doesn't really have the utility to all teams.
for example "don't do binary goals" is just a waste of time
then there are some implementations where personal OKR's are the final end of the cascading concept of OKR's, and that's a waste of time too. oh like learn rust? or like go hiking? pass leetcode hards so I get the f* out of here? its not the company's business but done on company devices or collaborative tools for all or an admin to judge
then there's the "if you meet your goals then you weren't ambitious enough", okay tell that to the product manager who is reducing the story points per sprint every two weeks because the team as a whole can't meet any goal and that's the PM's most innovative reaction
and then you're going to spend half the quarter doing OKR rituals on top of that, christ
I recently wrote up a little account of how I used an OKR around linter errors to get a team to take quality more seriously. It worked surprisingly well: https://koliber.com/articles/reduce-tech-debt-with-okrs
It's not that OKRs such. It's that they are often done in a ham-fisted fashion.
Its like because your team were subjugated by a hamfisted OKR feifdom, you conformed a goal into an OKR.
Would you have ignored this issue if the OKR didn't tell you to go find something to be an issue? Was the maturity of your development team driven by your drive to find a problem, and then the root of the problem, because the OKR told you to find something?
“The development of OKR is generally attributed to Andrew Grove who introduced the approach to Intel in the 1970s”
Yes, let’s copy management strategies from a company that is currently trying to disintegrate. Worked so well for Six Sigma (GE and Motorola both fell apart just a couple years after SS hit its apex).
It was pure waste.
See... one must carefully calibrate OKRs such that only 80% of them are accomplished.
Do too much, and you were sandbagging. Do too little and you're not a competent planner.
You cannot imagine the stupid horse shit that would wrap every quarter as managers would try to manipulate outcomes to look like they hit 80% dead on.
BS processes with BS metric targets lead to BS outcomes. In this case, the management is too scared of their own performance reviews (a process) to be unable to take risks (<80% complete) or to accept success (>80% complete).
They would much rather spend months massaging 1 quarter's OKR to fit the 80% bounding box than do any work end-to-end that helps the business.
What will they do eh?
The OKR book assigns most of Google's success on OKRs. Assuming there is an alternate reality somewhere, where Google chose SMART goals in that critical point in time. In that timeline Google of today is one floor below Yahoo in some random Verzion corporate building.
I haven't seen a goal management system yet that I cannot destroy with bad management and misaligned incentives.
OKRs are usually just pretending you have a clear understanding of that notion, which always is a lie.
How many times have you heard "we use <methodology>" followed by "well...our version of it anyway". Of course, whenever someone admits to not strictly following orthodox doctrine there are howls of "you are not doing it properly".
I've been a software developer a long enough to take neither the peddlers of fashionable methodologies, nor the people who decry them as utter nonsense, very seriously. It is odd how people tend to confuse wishful thinking with reality when they start to get a bit hot under the collar arguing about these things.
I've seen OKRs work and not work. I've seen scrum work and not work. I've seen kanban work and not work. You can't really predict what will work for a given team, doing a given project in a given organization. You try, you adapt and if something works, then great.
Two things never cease to amaze me: 1) delusional or blind leaders who think that some methodology works for them just because they like to think so, while their employees hate their life. And 2) people who think that some orthodox system of thought invented outside their organization is going to work without modification.
The problem isn't so much OKRs. It is the failure to either make it work in your organization *or* find something else that does. I've worked in places where OKRs worked supremely well. I've worked in more places where OKRs didn't work at all. Mostly because people got caught up in the ceremony and didn't really stop to ask "does this help us accomplish what we need to accomplish?".
Generally people on all levels are incompetent most of the time, but in management your incompetence just have a bigger blast radius, while the consequences of it are vague and much easier to blame on something else.
They never deliver. I never do OKRs. We all win.
How do you plan the work? How do you motivate yourself and your team? How do you show progress? How do you communicate with other teams on whom you depend to hit your goal?
OKRs are one tool to do the above. There are others. Curious how you do it.
The opposite of a system like this means - every VP has an initiative they're trying to push and now there are 50 new projects to maintain and eventually sunset.
> should you complete 70% of your goals to 100%? Or should you complete 100% of your goals at 70%?
explicitly addressed in various articles and books. you average your scores across objectives and KRs to get a score. So the answer is both, looking for average score of 0.7
> if your key result is "migrate 100% of users to the new system" and you only migrate 70%, guess what? Now you're stuck maintaining two systems in perpetuity
so you're going to migrate all of your users in a big bang moment?? hell no. it'll be bit by bit no matter what. of course you're maintaining two systems, that's a sign of a good migration, not a bad one. the KR just helps you get done with it faster
of course there are valid criticisms of okrs, and many (most?) teams get them wrong.
but saying "okrs are bullshit" has become a common trope for new-age companies who use that as a way to differentiate themselves. do you really think Andy Grove and John Doerr are bullshit artists?
that's a company/people problem, not a tool problem
that's the theory behind okrs in general
1. Pick a contentious topic that everyone knows something about.
2. Intentionally misunderstand what you're doing.
3. Claim it's all bullshit.
4. Adopt a defensive stance: anyone saying you're doing it wrong is guilty of a "no true Scotsman" argument.
5. Blog about it.
One of the things that is wrong with OKRs is that people often focus on the wrong thing. There is a lot of room in how to do OKRs. People pick some of the fringe things and focus on them as if they are the most important thing.
This article cites two of such things.
While many people do say that OKRs should be ambitious, there is no fundamental rule that says that OKRs need to be ambitious. It's perfectly OK to do OKRs where you aim for 100% success. Or you can use OKRs to get the ball moving and overcome static friction on an initiative and be happy at the end of the quarter that things got moving. Or you can aim for 70% completion like many people do. The key thing is that "aiming for 70%" is not a defining characteristic of OKRs. It's one way of doing them, but it is not a defining feature of OKRs.
The article also says that OKRs need to cascade. Again, this is flavor of doing OKRs. OKRs should support higher-level organizational goals. However, making them cascade perfectly through multiple levels of an organization is "hard mode". In many companies, there is a stated top-level goal, and then OKRs need to support it in some way, without necessarily cascading. That's fine. It's also perfectly OK to use OKRs in isolation in some department to advance toward an important goal, even if no one else in the company uses OKRs.
If these are not defining characteristics of OKRs, then what is?
Here's how I implement OKRs on my teams. These are the three golden rules of OKRs:
1. The objective (O in OKRs) sets the direction in which you are going
2. The key results (KRs in OKRs) are the rulers which measure your progress
3. MOST IMPORTANT: You must update your OKRs every week, come hell or high water. If you cannot update the value, add a note about what kept you from updating it, and spend time working on that. This rule is the forcing function that will make your OKRs work well eventually.
Start like that. It's hard enough to follow these core rules. Adding alignment, flowery language, reach goals, and whatever else comes on top of it makes OKRs more complicated. Once you get the basics down and you get a feel for OKRs, you should improve your OKR game. But start small.
So yeah, the way many organizations do OKRs is bullshit. However, OKRs are not bullshit in general.
I'm kind of passionate about OKRs in engineering. I've spent a decade at 15Five building a system for tracking OKRs, and getting teams to use them well. Here are some things I wrote about how to get OKRs working in an engineering team.
https://koliber.com/articles/opinionated-essential-guide-to-...
This framework encourages teams to think beyond the status quo and strive for exceptional outcomes.
The success of OKRs depends heavily on the culture of the organization and the mindset of its members. They require a team that is not only willing but eager to tackle ambitious challenges—teams that view 'impossible' goals not as deterrents but as opportunities for innovation and growth. This mindset shift, from seeing goals as mere targets to viewing them as a path to organizational and personal development, is what differentiates OKRs from other goal-setting methodologies.
Furthermore, the keywords 'functional' and 'team' are critical. A functional team, in this context, means a group of individuals with a clear understanding of their roles, responsibilities, and how they contribute to the collective objectives. The term 'team' emphasizes collaboration and shared responsibility for outcomes. OKRs are most effective when they are embedded within a culture that values transparency, accountability, and continuous learning.
You may argue that OKRs can be manipulated for short-term gains or to superficially meet targets. However, this criticism overlooks the fundamental purpose of OKRs, which is not just to achieve specific metrics but to foster a culture of ambition and continuous improvement. When implemented with integrity and supported by effective leadership, OKRs can transform the way organizations approach their goals, driving innovation and performance across all levels.
If you don't have a cohesive functional team, you have bigger cultural problems to solve than OKRs implementation.
I can't tell if this is satire.