This is the key of the article:<p>“ Those successful companies aren’t successful because they use OKR’s. They use OKR’s because it is designed to leverage the empowered product team model.
And as I have tried to make clear with years of articles and talks, the empowered product team model is a fundamentally different approach to building and running a tech-product organization.”<p>Amen to this. Google is an example company that claims to have had great success with OKRs. But let’s not forget that before OKRs, they had empowered teams, a growing market which they disrupted and grew, and a unique culture.<p>My bet is they would have done spectacularly well without OKRs, using some other method as well. You can’t say that OKRs caused Google to succeed, and they certainly won’t be enough to turn a company or org around, like the author argues.
I've worked with OKR's at large e-commerce companies, small tech incubators, consultancy firms and "Unicorn" stage startups. At each stop OKR's were absolutely worthless.<p>What I really appreciate in reading this article is that they were absolutely worthless for the reasons this author has stated: there was no real empowerment behind them. Most often they were used for personal development since I had no meaningful say in my actual work. It's always a stretch to put personal development in terms of OKR's: "I'll write two blog posts this quarter." "I'll run one lunch and learn"-- ok those are fine activities but we hardly need OKR's to grow as engineers-- and just imagine how annoying it is to be at quarter's end struggling to write a blog post when you find out midway that you're enjoying learning in an entirely different manner.
Biggest complain I have with Marty Cagan is he always describes the perfect product organization and says anything else is shit.<p>Well you can't choose your execs, you can't choose your culture,.. so thank you for describing what is the ideal world, but almost no company will be able to apply your advice.<p>Again in this article he doesn't explain how to replace OKR, but just says, if OKR doesn't work then your culture is the issue
My company is adopting this. They just gave a big company wide meeting/sales presentation on this. I ended up tuning it out after a few minutes. Maybe that was a mistake but I am just so sick of the corporate gobbledygook dog-and-pony show. At the risky of sounding ignorant, these corporate productivity systems feel like cottage industries invented by consultants to sell to management looking for a reason to justify their salaries to investors.
I’ve always found it shocking (well not that shocking honestly after years at 10 person startups to 5,000+ people companies) that you get these folks who read “measure what matters” or some cherry picked Andy Grove stuff & decide “this will fix our velocity and other problems”.<p>Like no, hard no. OKRs are great, I personally love them but if your company has deeper issues a set of OKRs won’t help and likely hurt as it obfuscates the underlying issues that exist.
> ... still continue to tell them the solutions they are supposed to deliver – nearly always in the form of a roadmap of features and projects with expected release dates.<p>This has always been my experience with OKRs. They were implemented by directionless companies with weak management as an attempt to bring structure, but the real reason there was no structure or coherence is that nobody in leadership agreed about what the company should do.<p>They ended up being such vague, arbitrary, and ambiguous goals, like "dominate this sector" or "become a leader in that vertical", or "hire x engineers by y time" that they were effectively meaningless. What does dominate mean? What are these new engineers going to do once they're here? Nobody had answers to these questions, yet achieving the OKRs was paramount.<p>I'm sure there are examples where they work well, but I suspect this author is onto something and the companies that use them successfully would be well managed with or without them.
Most of the teams I've been on at Google don't even bother with OKRs. The ones that did, it was a bit of a dog and pony show, a poor substitute for just doing some regular iteration task planning.
It <i>feels</i> like OP has made a bit of a straw man out of OKRs. More charitably, perhaps we did not get our information from the same place - all I know about OKRs is from reading "Measure What Matters" and implementing it in my own company. Reading this article makes me feel like someone took an incredibly simple idea and decided that what it needs is more complication.<p>From TFA: "most companies are not set up to effectively apply this technique". Yes. And if you read the above book, you'll learn that this is sort of the point. You WILL fail at your first few OKR cycles, but you're supposed to use those experiences to change your company into one that CAN set and achieve objectives.<p>If you think your company is one where OKRs won't work, all the more reason to do them.<p>OKRs are about creating and communicating strategic short-term objectives across the company, so they remain top of mind. And that's 80% of what you need to know! The objections to OKRs mentioned in the article don't make sense to me, because it seems to follow a different definition of what OKRs are.
The summary is "your company may not yet be worthy of OKRs". This kind of has the whiff of other religious movements in tech like REST and Agile: if it's not working for you, you just aren't doing it right. Try harder and hope to one day be worthy.
My only experience with OKRs has been having to do more OKR-management homework separate from the actual work I do, which is the same 'coding stuff off the product roadmap supplied by a different department' as always.
My CEO tried to explain to me that the "key result" part of OKRs didn't need to be measurable and then cited my colleague's as better examples despite none of them having written anything that could be used to hold them accountable. When I ask him if he's read High Output Management he just says "It's on my reading list". I'm leaving soon.
We just started using them.<p>We're a small org that's mostly experienced consultants and contractors. They're energetic, proactive and independent people.<p>We've adopted OKRs to basically get everyone pulling in the same direction, but without being prescriptive about how the work gets done.<p>I'll report back at the end of the quarter on how it's working out, if anyone's interested :)
One of our senior leadership people read the book, got in his mind that we need this at the company, got together the managers of all departments, they figured out some OKRs and now everyone’s off working on implementing them.<p>Some of them are rather impossible, like teaching all devs on how to do devops within 2 months, so they can be self sufficient.
OKRs seem a brilliant way to silo your teams and shut down any cross team collaboration.<p>OKRs become a shield to deflect any external request that doesn't precisely align with a measure.<p>Not a fan.
OKRs are just a tool, but having been the founder of many startups, comes a moment when you need a tool to align your team towards a clear goal.<p>I understand most of the comments but as you grow your startup will come a time when it becomes useful when you have 70+ and even more thousands of employees. The bigger the company the harder it is to manage, google famously hated management and ended up with OKRs. My understanding from a couple of ex-googlers is that now most people are just gaming the system and aiming at a 0.7 score so I'm not sure if they are still as useful as they were at google.<p>OKRs / KPI etc are not magic, at the end of the day the article is right, the team is what matters, how teams align and communicate with each other is what OKRs can help with (I find them better than the old top down KPIs personally) I was asked by a startup to explain OKRs and I kept getting the CEO to ask me questions related to them not making sense (e.g some teams argued that goal X did not make sense to them etc...) For me this was not an issue with the OKRs per se, but OKRs helped to show very clearly that the organization was not well structured for the general goals, so worst case if OKRs don't work you should be able to tweak things and measure the impact (that's the all idea : measuring to improve)
I personally like OKRs, as I find them a valuable counterbalance to 1) daily standup, which can promote short term thinking, and 2) yearly "goals" in performance reviews, which, when evaluated in a binary way as completed/not completed, can deter people from taking on more ambitious and ambiguous tasks.<p>My big worry about OKRs is that they will descend into the same shitstorm that ruined SCRUM. Daily standups were never intended to turn into a daily opportunity for micromanagement and application of deadline pressure, but this is exactly what they became. And I can't say it was an external corruption of the process - the dangers are inherent to the technique. I always felt that saying standup and scrum are good, you just have to be careful someone external to the process doesn't corrupt it don't turn into micromanagement is like saying nitroglycerine is good, you just have to be careful some chemical reaction external to the process doesn't cause it to suddenly and unpredictably combust. The instability is inherent to the substance.<p>There was also a mini (or not so mini) industry of industry consultants helping people "do agile", that elevated "processes and tools" over "individuals and interactions", kind of how the 10 animal commandments in animal farm ended amended to mean the opposite of how they were written down.<p>I see a danger in point in OKRs, in that they're a great way for a manager to turn a casual projection into a committed estimate. I see the inversion of "Customer collaboration over contract negotiation" all over again here. The developer (or employee) is lulled into a belief that we're all friends and can trust each other, the "customer" (or client or boss) is lawyering up with a contract, and when time comes, the developer's feet will be held to the fire with firm commitments, and subjected to daily deadline pressure and micromanagement (because agile).<p>All I'm sayin' is, this could go sideways. But then again, so can any job.
Tell people what's important and what isn't. How innovative. OKRs are for managers who are incapable of telling their staff what's important.
The downside of OKRs is that it incentivizes everyone to sandbag their efforts and then stick to that effort.
Also no one is going to stick their neck out on goals which are ambiguous or lack clarity. There is just no incentive - in fact there's a massive dis-incentive.<p>If you have a startup with less than 300 people and you have good communication and goal setting, don't use OKRs. Use KPIs and then nehlp your teams to keep iterating.<p>Input management is so much more effective than output management but it needs visionary leadership. Read: High Output Management - Andrew S Grove (ex Intel CEO).
> The Role of Leadership
> And finally, and really the root of the problem, is that in the vast majority of companies I see that are struggling to get any value out of OKR’s, the role of leadership is largely missing in action.<p>Here, here!<p>OKRs are being rolled out at work, and there's a pretty clear managerial vacuum. You could call it the KRO: leadership makes a request that trickles down to line staff for projects and goals, then each layer of management tries to glue them into a coherent Objective.
> The main idea is to give product teams real problems to solve, and then to give the teams the space to solve them.<p>First, there's a dearth of high quality engineers in the industry. They've been gobbled up by SV companies with large paychecks and promises of "fuck-you money" paydays. Everyone else gets developers in the range from above average to bad.<p>Product teams only work with high quality engineers across the entire product. Why? Because if they're shitty, there's no bound to creep of shit code, call it "shit creep" (see footnote 1)<p>How do you fix a shitty product team, other than replacing the entire team, or product with hopefully a better team?<p>Sure, feature teams are more limited in scope and their abilities, but they at least constrain the shittyness to a feature. If the feature needs to be replaced, the team can just be replaced, not the entire product.<p>(1) We've all had to deliver shit code from time to time. The thing is the good engineers know it's shit and refactor it as soon as they can.
Not very sure if OKR should replace the KPI in most of IT companies since OKR mostly aims at developers. I've experienced one company that request their employees to do OKR weekly and monthly. It actually helped a lot at the beginning coz everyone is curious and energized.<p>But after a few weeks, indolence came out because someone forgot to submit the OKR. And other members also do the same thing. Pretty much of a "broken window effect". The workload was very high, so OKR wasn't attached any importance. Or maybe we did it in a wrong way.<p>It doesn't mean that we might not have to align with OKR, but the method of implementing the OKR insistently and continuously should come first before it takes places.
Good piece<p>I worked at a company that used OKRs but the teams weren't set up in a way that people had responsibility for the things that their OKRs wanted them to do, and it produced very little (thankfully the teams were generally good and it wasn't a disaster, but it was a waste of effort).<p>If the OKRs aren't embedded into the sales teams as well (which basically means you can't have separate sales teams) then it likely fails.
OKRs?<p>Quote: "OKR’s are first and foremost an empowerment technique."<p>Don't empower anyone. Instead work on getting rid of / minimizing / improve on anything that dis-empowers. This is usually easier, cheaper and far more straightforward. Not always easy to get rid of disempowerment but you can at least put things in place to minimize it. Empowerment is barely measurable in real terms. All the metrics are indirect. Even turnover doesn't accurately measure it. Dis-empowerment on the other hand is a stinking mess. Follow your nose. Or your heart.<p>Quote: "Manager’s Objectives vs. Product Team Objectives"<p>One of these needs to be fired / removed / re-evaluated. If the manager is fighting the team then who's more in alignment with the overall vision? Why would you tolerate a manager that is fighting their team? Or vice versa? If the team members are across leaders and there's issues then there's some misalignment that needs to be fixed. Now. Iceberg! Change direction or sink!<p>Pointless drama and deliberate friction created in large organizations is why they squash innovation. Its why they do mindbogglingly stupid things. Its also why a manager or executive can benefit when a team fails, even their own. Incentives can be so screwed up that if a division fails, a number of people in the division cheer because their individual incentives are all green. This is too common.<p>Another quote: "The main idea is to give product teams real problems to solve"<p>You're doing WHAT?! How can you possibly tolerate non-real problems? Why would this be even necessary? That's like saying, "it gives them a way to generate profit". Really? That's a thing you're going to add?! As if its some new thing? What?!<p>Quote: "Passive manager"<p>What is this creature? How can you passively manage anything? Not even drunk people are passive. Only when they become unconscious do you start to have passivity. I've met managers who's teams zip along with the manager gone for a month. This isn't rare and its still not passive if adult supervision is in place. Why? Because an active manager puts processes in place to monitor and optimise what is going on. This is active management.<p>Quote: "Stop doing manager objectives and individual objectives"<p>Correct. Any mismatch means pointless friction. Why was this tolerated? Perhaps because drama at the bottom and middle keeps people too busy to notice the silliness at the top? Maybe. Regardless, it sounds expensive: How's that productivity going?<p>Quote: "Leaders need to step up"<p>Sure, and they should be allowed to lead. Which is often NOT the case. Plenty of managers leave team leaders in the dark about key aspects about what is going on and what is planned. Leading means choosing a direction. How can you know the direction to choose if you don't know the destination? This applies generally as well. Instead of expecting leaders to step up, why is there a step in the first place? Shouldn't there be a level playing field? Sort out organisational mess so its as level as possible - remember the bit about removing disempowerment? I wasn't kidding. Here's a symptom: the need to step up when no step should exist.<p>Ugh!<p>Go for enabling and self-directed team members that can tolerate and operate successfully with adult supervision. This kind of supervision requires managers, directors and team leaders as well.<p>One last thing: Get rid of deadlines and use due-dates instead. Not just wordplay. We need to be using project X on date Y. Make it happen and don't drop dead doing so. Change the mindset to fit this approach. Those deadline crunches? Not good. Dropping dead after a due-date means something went very wrong. Everything must be re-examined to avoid it in future. The mess has to be cleaned up. Supports put in place. Additional followups scheduled and kept. This works for projects as well as childbirth.<p>Ok. I feel decaffeinated and that is dis-empowering. Time for coffee. See? Fixable.
Agree that the method is not guaranteed to be a success-maker. Our experience adopting in a small healthcare thinktank was difficult -- the pattern didn't really fit our present and future workflows very well.
> <i>Please upgrade to a supported browser to get a reCAPTCHA challenge.<p>Why is this happening to me?</i><p>I see this at the bottom of the page, and I’ve been seeing it more and more. I’m using the Duck Duck Go browser on iOS.
I really ought to read an OKR book, because the telephone-game version I hear about seems problematic.<p>For example, Austin's <i>Measuring and Managing Performance in Organizations</i>[0] gives a helpful 3-party model for understanding how simplistic measurement-by-numbers goes awry. He starts with a Principal-Agent and then adds a Customer as the 3rd party; the net effect is that as a Principal becomes more and more energetic in enforcing a numerical management scheme, the Customer is at first better served and then served much worse.<p>As a side effect he recreates or overlaps with the "Equal Compensation Principle" (described in Milgrom & Roberts' <i>Economics, Organization and Management</i>). Put briefly: give a rational agent more than one thing to do, and they will <i>only</i> do the <i>most</i> profitable thing for them to do. To avoid this problem you need perfectly equal compensation of their alternatives, but that's flawed too, because you rarely want an agent to divide their time exactly into equal shares.<p>Then there's the annoyance that most goals set are just made the hell up. Just yanked out from an unwilling fundament. Which means you're not planning, you're not objective, you're not creating comparative measurement. It's a lottery ticket with delusions of grandeur. In Wheeler & Chambers' <i>Understanding Statistical Process Control</i>, the authors emphasise that you cannot improve a process that you have not first <i>measured</i> and then <i>stablised</i>. If you don't have a baseline, you can't measure changes. If it's not a stable process, you can't tell if changes are meaningful or just noise. As they put it, more pithily:<p>> <i>This is why it is futile to try and set a goal on an unstable process -- one cannot know what it can do. Likewise it is futile to set a goal for a stable process -- it is already doing all that it can do! The setting of goals by managers is usually a way of passing the buck when they don't know how to change things.</i><p>That last sentence summarises pretty much how I feel about my strawperson impressions of OKRs.<p>[0] <a href="https://www.amazon.com/Measuring-Managing-Performance-Organizations-Robert/dp/0932633366" rel="nofollow">https://www.amazon.com/Measuring-Managing-Performance-Organi...</a><p>[1] <a href="https://www.amazon.com/Economics-Organization-Management-Paul-Milgrom/dp/0132246503" rel="nofollow">https://www.amazon.com/Economics-Organization-Management-Pau...</a><p>[2] <a href="https://www.amazon.com/Understanding-Statistical-Process-Control-Wheeler/dp/0945320698" rel="nofollow">https://www.amazon.com/Understanding-Statistical-Process-Con...</a>, though I prefer Montgomery's <i>Introduction to Statistical Quality Control</i> as a much broader introduction with less of an old-man-yells-at-cloud vibe -- <a href="https://www.amazon.com/Introduction-Statistical-Quality-Control-Montgomery/dp/1119657113/" rel="nofollow">https://www.amazon.com/Introduction-Statistical-Quality-Cont...</a>
BD needs to generate enough sales to keep the engineers stressed out. When you don't have that, you end up with politics. OR the company is pre PMF, and everyone needs to operate in that mode.
I didn’t read the article. Is it because OKRs don’t work anywhere at all, and are only successful when they are ignored? At Google that’s certainly the case; the better a group is at paying lip service to OKR planning, the more work they actually get done.