Reminds me of the time I had an OKR to reduce page load time by some ridiculous amount. The speed wasn’t even bad and there was no theory about how exactly it would help the product. We didn’t sell ads or anything like that.
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.
OKRs are simply an extension of the fact that companies and departments need some sort of 3-6 month roadmap. That is to ensure cross-department and external communication can be done somewhat smoothly. Waterfall used to do this inherently. Now we've got OKRs and SAFe.
The same can be said cynically: Companies are inherently not agile, any push towards fast and iterative decision making will generate a counter-force towards quarterly plans under a new name.
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.
The productivity targets are always increasing, but real productivity obviously can't. That creates a pressure to meet the goals through fraud.
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 have a comment with my own issues with OKRs but I do want to stick up for OKRs here: this really is a management problem and, let's be honest, they'd have fucked up any framework that was put in place (and a lack of framework would have probably been just as bad!)
Yes but it's always framed as a failure of either procedure or the people they manage that failed them. Management itself can never fail it can only be failed
Do you blame Word for documents that make 0 sense because the contents are incoherent? Because that's basically what's happening here. The OKR in question were non nonsense and contradictory, but that's completely irrelevant to if OKRs are useful or not.
Well, it should at least settle any claim that OKRs are useful in themselves. They need to be useful to be useful. "Useful things are useful" would make for a very short management book though.
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.
Sounds like they were doing it wrong. At a high level, senior management shouldn’t care about tiny optimizations like that, and their OKRs should be higher level. Your team should make OKRs that support those higher level OKRs in the best way it can, which is probably not those meaningless optimizations.
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.
Not sure what you mean by "fine", but OKRs in most cases can't work, because a key result means a number, and numbers can be gamed.
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.
That sounds to me like you haven't worked in a place that does OKRs right. The overriding thought should be "They are more like guidelines, anyway". Where I worked it was common for every single OKR to have a low completion score, and nobody batted an eye. Directions change, priorities change etc. The OKRs were still useful, to keep track of what everybody was doing.
But then they do performance reviews and ask to relate the stories to these OKRs.
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?
Performance reviews should be kept separate from OKRs. I view these two concepts as follows:
1. Performance reviews or performance management are tied zo an individual, their role and their career.
2. OKRs are Independent of the individual as they are driven by the company’s strategic and operational goals. While every KR is owned by an individual, this individual is responsible only for managing the measurement, coordinating collaboration and escalating to superior Objective or Key Result owners as soon as the Key Result is no longer on track.
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.
They're also a bit of an antipattern - agile is about learning and responding on the fly. Add an OKR and you immediately distort that and it turns out your agile methodology is just a couple of small waterfalls in a trench coat.
The only problem with "Measure what matters" is that if what matters is complex enough, it can't be measured. So the title could be reworded into "Fit a cube through a spherical hole" - assuming the diameter of the whole is same as cube's width of course.
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.
OKRs do not at all need to be one dimensional, the KR could be several measurements and also need not be quantitively determined.
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?
Things matter, and you can prove them mattering afterwards, but you can't set a metric/numeric as a goal and then expect it to be a good or productive goal.
I didn't think of it at first, but actually that's Goodhart's law.
> A single number just can't represent the result of something that matters
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
Watch-hours obviously matter, but so do other things like "are the best up & coming creators using us?" The danger is the tendency to focus on boosting measurable things at the expense of nonmeasurables.
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.
That's a really good example you just brought up, because if your goal is to get billion watch hours a day:
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.
So to describe the process. We would first brainstorm that watch hours is something we want to potentially be our OKR?
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.
No, we would figure out what we actually want to achieve (objective) and then (perhaps) arrive at that watch hours might be a useful way to measure our movement towards our objective.
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.
> 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.
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.
Have to add a different perspective here (the management one), just to try to give a potential explanation. I did pretty much the same thing to my team, though with a lot more background as to why. We were severely rocked by a Google search ranking update, and basically lost 70% of traffic overnight. We had no idea why, none of our metrics over the past years changed, but it all went to shit. In the days after, we set out a plan to try to recover this ranking, even though we had no idea what we need to do. Page speed was one of those metrics we set out to improve, and even though it wasn't bad, but it wasn't exceptional. As with other SEO stuff, there was no guarantee this will help, but we needed to try, along with a few other things. After we fixed it (along with a few other things), there was very small growth initially, and it took another 9 months for our SEO to fully recover, but we did fully recover. Was it Page speed? Who knows, but 30 million website visits were earned back one way or another.
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).
OKR is another tool for the managers not to feel useless. The problem is when they are also incompetent. OKR is an integral part of company brainwashing of employees. OKRs are good for the management people, but it should be not enforced on those who do the actual work, like engineers. They could set goals like, one coffee per week, report to the higher ups that coffee consumption is good, and thats it. ;)
This is because you're trying to actually achieve your OKRs. Everywhere I have ever worked we understood that OKRs are frequently not achievable, fudged the numbers are OKR grading time and the still frequently had red OKRs. At one point I used to push for actually specific, measurable, achievable OKRs but I quickly learned that nobody cares and it's a waste of effort.
People will never be motivated to go the extra mile by a standardized, bureaucratized process. It's not a problem specifically with OKRs, it's a problem with the whole concept that if HR can just put in this one simple system then doing so will be magically motivational and the whole company will go to ludicrous speed.
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).
The first time my company decided to implement OKR's I told my manager that I'm already motivated by my own standards, and using OKR's as a carrot on a stick that I know it's deliberately and exclusively out of range is absurd.
He was staring at me as if they invented penicillin and I was too dumb to appreciate it.
I worked at a company where every year we'd decide we were going to do OKRs or something similar, and we "were going to do it right this time".
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.
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.
I've worked with people that say the same thing, and they are usually very smart and high functioning.
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.
I find the out of range goals to be very demotivating. During the quarter they will hold our collective noses to the grindstone telling us to get this stuff done and hit certain dates and numbers. Then maybe once a year they will say they don’t expect us to hit any numbers that are set, in typical OKR fashion.
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.
I don't understand, isn't your team coming up with your OKRs yourself? If you have a manager who is assigning you OKRs, that's a management problem.
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.
Our OKRs are being dictated to us from several levels of management above us, who don't really understand what we even do. I know how it should work, but it's not the reality I currently live in, which is all part of the demotivation.
I see this type of backlash against process a lot here. But I don't think 'just good people' is the answer. A lone hero can do a lot, maybe a band of them kick real ass, but it doesn't really scale beyond that nor does it last. Furthermore, even the best make silly mistakes, you need to have a lot of mechanisms to both prevent and mitigate against the consequences of failure if that is important to your business.
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.
I'm not trying to say all process is bad and I'm not sure where you got that from my comment. So to clarify: instituting process only makes sense when you have consensus across teams that need to collaborate with each other on what that collaboration is supposed to look like. In other words, process only makes sense when people agree on what needs to be done and what to do. In a hospital setting, processes can be tremendously helpful in ensuring that supplies are restocked, that someone is always on-shift, that patients can be transferred from one department to the next without needing to know who exactly is on-shift. There is consensus on which supplies are needed and that departments need to have people on-shift. Mission clarity is almost built-in: patients need to be treated, and that treatment needs to happen as quickly as possible after it is determined that the treatment is necessary.
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.
I'm not sure your idea of "No Processes" works at significantly large orgs. Sure, hiring the best and filling gaps works on small/medium orgs, but once you get to 3k+ (Made up number) I find it hard that this will work.
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.
I think everything just has to be a large arbitrary tree of branches, with tasks going into subtasks until they are small bites enough to be divided amongst teams. Then you measure how these tasks are going and if required you change the tasks or branches.
Everyone can move around the tree to see which team is responsible for which task and how any task on the whole is progressing.
Well, that is quite top-down and organized. If it works, then great. But I wouldn't push everything into such a plan.
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?
I haven't ever seen anything like I described implemented the way I'd like to see if and the way I think it would work, so maybe it wouldn't work, but intuitively it would make most sense to me and I can personally imagine it working.
Couldn't agree more. It's a fantasy that there is a magic wand or a system that can make anything and anyone efficient and productive at everything. I agree with the author, some process is needed to have a group of people on the same page, but it's not the driver of good results.
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.
I think this is mostly the case except that it’s not about weak people, personal growth or even mostly about culture. If people aren’t willing to go the extra mile for you, that’s on you honestly. If you’re incentivising and looking after your people they’ll feel like they have a stake and be personally invested.
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.
> People will never be motivated to go the extra mile by a standardized, bureaucratized process.
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.
Same thing with SCRUM or all the other bullshit that people who can not actually bring anything to the table use to justify their payroll, while only making things worse for anyone else involved.
SCRUM is a great starting point for a team with dependable and medium to high performing members. It's important to remember that it is not a rigid framework, it is a starting point and a process to iterative improve the process. At some point you transcend SCRUM as we know it, and completely own the process. But there is not consultants salaries or SAFe in that, nor is management often completely on board with it, which means it is doomed from from the start, or at the very least crippled - earning the nickname "SCRUM-but"
If you view SCRUM as a rigid framework, you've already surrendered and completely missed the point of agile in general.
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.
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"
To me agile brings up a picture of Jean-Claude van Damme doing the splits.
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
People can for sure be motivated be simply, standardized processes, such as a % of revenues as commission. However, not everyone gets motivated that way and organizations could use different processes in places or also just say: we only want people motivated by X.
The problem with OKR and every other fad managment system weather it be agile. SaFE, or LEAN is that they are all essentially cargocults once the leave the orgnisation that spawned them.
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.
Hell yeah! And on top of that management rarely learns or understands that they need to think and design what their organization should be, nor that their power to introduce change is much more limited than they think.
Agile is everything to everyone because it's derived from an manifesto made up of non-actionable feel-good slogans but is very often used as a shorthand for a set of project management practices, that have an less then perfect real world track record.
> I think the biggest problem with OKR's laser focus on measurement, though, is that not everything should be measured, even if you can!
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 Te Ching starts with this line, which I adore:
> 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.
The Tao Te Ching makes for a great management book. I especially love chapter 17:
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.
That's the premise of Seeing Like a State, except that the State actively destroys anything that is unintelligible to it, and instead builds what can be measured.
By strange coincidence, that's on my library holds. To offer a random new edge on the tenuous graph: "Lying For Money: How legendary frauds reveal the workings of the world."
> The fo[u]rth step is to say that what can't be easily measured really doesn't exist. This is suicide.
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.
When things are growing, any nonsense is thought to be "the way". OKRs, matrixes, oh they must be so smart with all those "systems thinking". Somehow none of those systems work when things are going down. Look at Google and Intel today, none of those OKRs saved them did it?
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.
I think "OKRs" exemplify this best because after reading the wiki page I'm not sure that they exist. As pointed out in the article, it seems to be a term that describes ... nothing in particular.
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.
As I get into my late 40s, all I see is cargo cults anymore. Not just in tech, but everywhere. I thought we had people who knew what they are doing, but it feels like everything is being run by silver-tongued conmen now.
I really liked this post and it hit on a few problems I've encountered when trying to use OKRs: namely, what I'm going to call the "we know what we want to do, so just fucking do it" problem. I've been guilty of trying to contort things into an "OKR-like" view of the world when really, the answer was to just say "this quarter, we'll work on this task." It makes everything difficult when I'm then asked to turn this into a roadmap of things we'll do.
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."
Nowadays you can write up what you really need to do, then ask ChatGPT to make BS OKRs out of them, with numbers to sound just impressive enough, but really easy to achieve even when you do the correct things unrelated to the OKRs.
Honestly, I don't like this approach. I think it's better to just write down what needs to be done and say "this is what I'm doing." At least that's clear to everyone instead of everyone in the org trying to BS each other.
I mean that's from the individual perspective. The alternative is to start telling everyone that OKRs are BS, and then have everyone on one level above you do the same to have it make any difference.
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?
First up, I never said they were BS in all, I just said they're not a great tool for all situations.
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.
The way I've seen OKRs work so far was always the same:
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.
Helping teams know what to say "no" to is the real power of OKR.
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 requires the high level OKRs to not be vague BS, because otherwise the team wanting you to do extra work can justify everything. Like the exec level OKR might be something like "customer first", which literally any feature work could be justified under (or is often used as an excuse to try push out needed technical work)
Years ago I worked at a place where we were meant to set objectives to please HR. Instead, at the end of year we always found what we'd needed to work on had completely changed, so instead, we retrofitted objectives for the work we'd actually done. So, hacked the system / circumvented the spirit of it, but did a very effective end of year annual review i:e what have you actually achieved this year, are you/we happy with that, what do you ideally wanna achieve next year (with caveat that we can't necessarily predict what we'll actually need to do), any training or anything else you need to achieve that. I recommend this approach to anyone encountering OKR nonsense. Change your objectives after the event, to fit what you've done. Just make sure you got a decent list of stuff you've done. Its ridiculous. Think of a plumber for example. Should they specify how many toilets they're gonna fix next year? ;) Depends how many break, in what way they break, how hard they are to fix. I suppose, maybe you could average it out. But software is far more unpredictable.
They certainly are for me. I fill them out with my manager's help and then 100% ignore them because they generally have nothing to do with the things that end up actually needing to be done.
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.
FWIW in many companies and organisations, including large parts of Google (from personal experience), OKRs are not interpreted with the 70% benchmark, but more along the lines of "this is what we want to achieve, more or less - more is better, a bit less is acceptable, if we didn't mostly achieve what was specified in the KRs that's not good enough". Some objectives lend themselves easily to 70%+ targets, and others benefit from tighter control - that's context-dependent.
OKRs are good for solving the problem of communicating strategic decisions in a meaningful way in large organisations. Without such a device, it is common for people "on the ground" to not have a good understanding of the priorities of people several levels above them, with the result that they can do great work and still not move in the direction the company decided to move in. It is easy to misunderstand that and trash OKRs when you're the "leaf" in an organisational tree. But ask your manager, or their manager, or your VP or CEO, and they'll tell you that they need a device for effectively communicating to everyone in the org what the priorities are.
I don’t understand this. Why can’t they just tell them?
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)
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.
OKRs are nothing more and nothing less than a way of telling your organization what’s the most important thing we want to improve and how we are going to measure if it’s improving.
It really is just telling them and checking once in a while how it’s going.
Imagine that you are an executive managing an org with 3000 people in 4-5 levels of hierarchy. That's common in large companies.
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.
I can review the OKRs every day, and structure my plans for what to work on accordingly. Objectives tell me what is the strategic direction. If what I do doesn't help move in that direction I can stop doing that and do something else instead. Key results help me assess whether I am making progress. If I am not, I can stop doing what I was doing and adjust my plans. That's not perfect, but a lot better than getting to the end of the quarter (or, more commonly, semester) and realising that a few months of hard work have gone to waste because we weren't aligned to the strategy and so didn't achieve what we set to achieve.
That doesn't match my experience. Town hall style meetings are generally more frequent than OKRs and paid more attention to. My experience of OKRs has always been "set then once or twice a year and then immediately forget about them until the next time".
Yeah, executives need to understand how little influence they actually have. I think OKRs aren't really that much of a solution, as more of a stopgap. We need a new management paradigm that embraces this knowledge, rather than pretending it doesn't exist.
I think a fundamental problem with all management culture is that fundamentally, managers do not want plans to change. I suspect there's some systematic issue at work here, but in the kinds of people who are selected for these roles, how they're evaluated, and so on.
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.
From my experience, the opposite is true. Managers want to change, and most of the people they manage are extremely reluctant to changing anything, and if they do change it's often random and undisciplined. Tools like strategic planning and OKRs are how managers and executives implement change at scale.
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.
In my experience, the vast majority of companies that use OKRs do it incorrectly, misunderstand the point, and cause more harm than good. As a member of the management team, I was able to get my current company to leave them behind, by giving a well sourced presentation on what OKR is for and when/how to use them. After 1 quarter the lights went on and nobody wanted to use them anymore.
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.
I see only the problem of no ability to change the OKRs, otherwise the core idea of making a plan is right. Changing the goals should introduce a additional change process, because priorities change with new knowledge. I haven't see that done well yet. Maybe just having 6 weeks cycle OKR [1] instead could work better as in Shape Up?
In my experience, but I know I am unconventional, half-organized chaos. You do need motivated, good people for that so. The chaos bit is those people figurong out their stuff themselves, while the organized bit is szrict following up on deliverables, relevant deadlines, flexibility on not-so-relevant ones and, this is crucial, step in in to provide guidance, support decision maling and coordination between peoole and teams. If the latter means setting up a dozen 30 minute meetings between two people, the be it.
Only gets you so far so. And needs everyone being aware of customer needs and requirements.
"chaos" is what relatively unproductive people, or people-at-arms-length call it. "Doing the job" is another term.
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.
I think it's not so much the individual management technique that is the problem, it's the design of our organisations. SAFe, Lean, etc. are half processes and half organization design, but are generally really shoddy on the second part, and mostly shoddy on the first part.
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.
OKRs, and similar methods, are all doing the same thing. Define what you want to do and how you will measure it. The effort companies put into changing to the latest flavor of the week is mostly a waste of time. It makes upper management feel important, but creates chaos in the organization and a lot of lost time to process change, all to define what they had already defined, just with a new acronym.
OKR should be something those managers use, not things we programmers(well if you like, call me coder is ok, I don't care) should do. Because it's those managers manage our jobs. If no one can manage my job except me, I'd like to use OKR.
Used to think OKRs were total bullshit, until I started working on a project spanning multiple teams with cross-org dependencies.
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.
Bad org culture will be bad no matter the mechanisms. You can use OKRs to be toxic and you can use Agile to be toxic and you can use your own bespoke bullshit to be toxic. There is no management framework that can fix bad culture because its only a part of it. Incentives structure, existing culture, hiring practices, company life cycle, market conditions, etc all contribute to it and no amount of data can fix those. Managing a company is like parenting, if you think that you can replace attention, care and hard work with a framework you are doing it wrong.
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.
I actually think they are quite reasonable compared to a lot of the alternatives.
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.
Too many organizations are making OKRs much more complex than they need to be.
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.
You need _some_ system for accountability on goals and to cut down tasks to units that go through some workflow (specification, implementation, testing). That's all it can and should do. Beyond that it's only about motivated, capable people. You can't create culture with a methodology. You can bash all of them the sun if the org is just aping it and the culture is not there.
This seems oddly badly argued. Take the criticism of 70%, the author essentially poses the question "What do you mean by 70%" and goes on to illustrate an example of where it is extremely obvious what it means.
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!
> 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.
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.
Especially since for the migration example you can trivially set the ambitious goal by measuring not the % of users migrated (since you need all of them) but measuring the time or cost of doing so; e.g. set an OKR to finish it in X days or under Y person-hours or Z dollars of cost, and pick the values of X/Y/Z so that they're not "safe" but rather the values where you expect a 70% likelihood of meeting that goal.
I think people should implement their own ideas and systems first, prove it to us, and then preach about why a competing idea/system is wrong. To me, it makes zero sense to tell someone they're wrong, when those people are seeing results.
This is nonsense. You're allowed to criticize a system without having a solution. For what it's worth, I've worked at a few OKR driven companies and it sure seemed like a waste of time. Metrics and measurements shifted, goals changed as the product changed, and we wasted time measuring the thing instead of doing the thing. The measurements for OKRs never lead to meaningful action. Meaningful action was driven by customer interviews, market analysis, and R&D.
It makes complete sense if you don't strawman comments in bad-faith. This isn't about "allow" or "disallow" - there is no attempt here to abridge somebody's free speech.
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.
You are entitled to your opinion, but pro tip: Telling people they're wrong when a system is working for them doesn't get the point across. Often those same people are well aware that each system has its flaws and no system is perfect.
Of course, these things are assumed. Nobody actually claims systems to be universally applicable to everyone in every situation. So that is a bit of a nitpick, and not very substantive.
Sorry bud, no strawmen in sight. I was giving you an example of the system failing for me. This is a valid reason to criticize the system. If I had a solution that I had been able to test and validate then I would present it. In the absence of that, there's value in pointing out that it's not a panacea and it may not be valuable for others to jump on the bandwagon
> I was giving you an example of the system failing for me.
"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.
I in no way claimed that I proved OKRs are bullshit. I only stated that they have been ineffective in producing actionable data at the companies I've been at. If OKRs work for you, great. It doesn't mean that they are a universally good solution.
OKRs are bullshit because they rot the entire willpower-based culture of an organization and replace it with a mindless metric-optimizing machine. People should be judged by their ability to do a good job at their jobs, not by their ability to hit stupid metrics at the expense of everything else.
As far as I can tell being "data-driven" is completely toxic to long-term organizational health.
If the metric is stupid, then you're right that it is a waste of time to hit it.
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.
By one's intelligent opinions. You hired them, gauge to the best of your ability if they're doing the job you hired them to do, at a level you deem acceptable. Your boss should measure you the same way.
This makes sense in a small company context when, say, a competent CTO/CEO personally knows everyone and can resolve conflicts, bottlenecks, disfunctions quickly.
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.
i don't even think it does make sense for small companies, they can benefit hugely from setting clear, public commitments about what they're working towards
focus is one of the most important characteristics in a startup, because time is too short to waste.
I've seen this direct CTO work scale to a billion-a-year online business with hundreds of engineers :-)
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.
Honestly, I think the best you can get is having a competent manager who understands the work and people well and gets the need autonomy and trust from the company. That's hard though and there is no magic wand for the CEO to make all managers "good managers".
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.
You are fighting a straw man. Of course data-driven management or any kind of planning, at the extremes, has some awful manifestations. That's just bad application of these tools. Bad management. In many successful orgs people use their "willpower" and motivation and skill and originality to do work that is informed by data and follows strategic plans, agreed on in OKRs or similar devices.
I knocked out an OKR for my entire team in 1 day. It was dumb.
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.
> should you complete 70% of your goals to 100%? Or should you complete 100% of your goals at 70%?
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.
OKRs are subjective goals that have objective measures of success. Naming is a problem here, but the idea that a company shouldn’t have goals that are measurable is flatly wrong. In practice, OKRs seem to break down due to two problems: 1) choosing goals that have subjective or unobtainable measures of success, 2) failing to implement hierarchical and cross-department goals that build synergy rather than siloing.
my experience with OKR's is that it doesn't really apply to the product or specifically software engineering teams
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
Often OKRs are forced into engineering teams and the result is that they don't deliver value. However, there are ways of doing OKRs in engineering teams as well.
That tale is inspirational, the OKR aspect of it seems not important. You were having weekly engineering meetings regardless. You were giving positive reinforcement regardless.
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 point of OKRs is that doing the right thing is the most important thing for the business. But how do you know if you're doing the right thing if you don't set and measure goals? You can then reflect and learn from your success/failure. The whole point is to learn whether our assumptions were correct. Otherwise it's just gut feeling and wishful thinking.
Corporate america seems to love them, in small biz I never needed such things as we directly worked with customers and knew all the finances. There was a direct personal understanding of what was important and what wasn’t. That’s missing in Big Co. I’m not confident OKRs are a good replacement or not yet myself.
“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).
I mean, they had like 30 years of success after it was implemented , before the current troubles, so at least it's very unlikely that OKRs were the cause of the collapse (compared to hubris in deciding how much they needed to invest in product development once their primary competitor was on the ropes)
I’m not saying the processes are necessarily bunk (well, except digital SS is definitely hot garbage), but something about popularizing them is rotten. Like we are getting someone’s castoffs.
It seems to me that companies might want to implement OKRs as a way to align everyone on the same goals and check progress. The actual numbers aren't too important since everyone is free to miss their targets. OKRs don't give as much steering control as some might hope.
> Do too much, and you were sandbagging. Do too little and you're not a competent planner.
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.
Maximum 1 year before a large company announces proudly they came up with an LLM that sets OKRs for the whole organization. In some ways it would be hilarious to see hallucinated goals the LLM came up with but that would also feel pretty depressing
OKRs are just a tool. They can work pretty well if you have competent people and apply them correctly. But, that can be said of any other project management system, goal management system, gamification system... Some are worse, some are better, but most have books written about them that heavily feature survivor bias and correlations/causation bias.
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.
Essentially they are bullshit. Every company implementing OKRs literally has no clue what is going on in their business, so OKRs tend to be some disconnected bullshit where someone will pretend they have any relevance, when actually not a single person really understands why the company has customers, or makes money, etc.
OKRs are usually just pretending you have a clear understanding of that notion, which always is a lie.
There is money in fashions. Nowhere more so than in fashionable ways to manage companies, projects or work. Whenever some methodology is applied to some process, the precise way in which it is applied tends to vary. A lot.
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?".
It's not OKRs. It's management as a whole. Whatever they do it turns into bullshit, because they are all bunch of bullshiters. Waterfall, Agile, Sprint, Performance Reviews, doesn't matter what. They all turn into Bullshit because they are applied by bunch of bullshiters that usually have no clue what they are doing, but they would like to keep their job.
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.
What do you do instead to drive non-trivial goals that take a quarter or longer to accomplish?
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.
I think so much of the commentary misses the point. Goals drive focus, they help folks say no and ask "how does project x help get more sign-ups?". If nothing else it's a communication tool. If you want to get another team to do something, show them how they'll succeed at their goal and help yours too.
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?
the whole purpose behind an okr is alignment. a public, committed KR for % of users migrated helps a team get there faster than not having one, and signifies to everyone at all levels what's important and what's being worked on
OKRs are often done wrong. I would not go as far as call them "bullshit" or useless. Just because many people are doing something incorrectly, does not mean that there is no way of doing it well in a way that provides value. The biggest bullshit with OKRs is that many organizations go through the motions of doing OKRs, but are actually just making up numbers and sweating through the end-of-quarter presentation hoping no one asks hard questions.
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.
OKRs are not merely tools for creating a set of easily game-able measures for performance review bonuses. Rather, they are a strategic framework designed to establish focus, inspire and build cohesion within teams. The essence of OKRs lies in setting ambitious goals (objectives) paired with concrete, measurable actions (key results) to achieve those goals.
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.
Its bullshit consultant or middle manager speak for "I have no idea about anything but please let me justify my salary by something that makes things worse for everyone else"
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.