13 ms·
Why OKRs might not work at your company
- gregdoesit 6y agoThis is the key of the article: “ 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.” 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. 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.
- codesuki 6y agoThanks for the tldr. Maybe good to always add that when posting a link :) Also from the article: "You can’t take your old organization based on feature teams, roadmaps and passive managers, then overlay a technique from a radically different culture, and expect that will work or change anything."
- sukilot 6y agoRegardless of whether OKRs are meaningful or important (IMO they aren't), Google had OKRs in 1999, less than a year after founding, before AdWords. They didn't have notable product teams before OKRs.
- staticassertion 6y agoGoogle seems terribly run, frankly. I wouldn't use them as an example of good process, organization, or really anything other than that being early to advertising and being the internet's front page for ~20 years is a great way to make money
- packetlost 6y agoThis. Google seems to not have anyone with a cohesive vision or even anyone that knows how to build a platform or maintain a product. I personally would like to know what's going on with the product owners at Google, because it really seems like none of them talk to each other. Google is a fantastic engineering company, but terrible at building products.
- staticassertion 6y agoI don't know that they're a fantastic engineering company. I don't know what Google is great at - a few things, which feel like they're successful almost because they're treated as separate from the rest of the organization. OKRs are one of many parts of that, in my opinion.
- mahmoudimus 6y agoGoogle engineering is fantastic and respectable. What gives the impression that it is anything else other than excellent?
- staticassertion 6y agoMy personal opinion is that Google has some really strong engineers, and some pockets of engineering are truly exceptional. That is it. The impression is based on lots of anecdotal experience. I know many people at Google, I use many Google products, I talk to other industry leaders about their impressions of Google.
- deleted 6y ago
- ck425 6y agoIs Google success because it's a well run company in the first place? It's obviously not terrible (I'd personally love to work there) but life is a lot easier when you have the biggest cash cow ever plus a few smaller ones. In general I'm skeptical whenever anyone wants to copy Google as their advantages and disadvantages are so far removed from a typical company and always were. I don't think they're a particularly good company to model for most companies.
- garyrichardson 6y agoBack when it was popular to have a flat structure or no managers or whatever I started suggesting "Every type of management works until money gets tight." I think the principle still applies, but a more useful/general version is pick your structures and processes around resource availability (good vs bad times): Good Times: pick something that can amplify abundant resources. There is going to be less bureaucracy around decisions and spending so move quickly and place lots of bets while you can. Bad Times: pick something that works with meagre resources. You're going to spend more time justifying spending.
- brogrammernot 6y agoI’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”. 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.
- chetatkinsdiet 6y agoMost times they don't even read the books. They just stop at "what doesn't get measured doesn't happen." Great, that leads people to measure all sorts of stupid stuff like lines of code to production. Who cares if it isn't something that contributes to a thing that someone's going to use.
- nickfromseattle 6y agoThe last company I worked for had a problem with the service, it lost their clients money. Their solution was to make everyone in the management team read a 'business book' per week, and discuss it in weekly meetings.
- tomrod 6y agoAgree 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.
- akmarinov 6y agoOne 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. Some of them are rather impossible, like teaching all devs on how to do devops within 2 months, so they can be self sufficient.
- scaryclam 6y ago"teaching all devs on how to do devops within 2 months, so they can be self sufficient" There's so much wrong with this key result it's incredible :( One big reason that OKRs can fail is just flat out bad OKRs. Teaching all devs to do "devops" within two months ignores the actual issue that they seem to be trying to solve (which I'm guessing is that not having sufficient ops is hurting the company and velocity). It's far too easy to fail and puts pressure on individuals rather than letting the team find the right solution.
- the_other 6y agoThis has flicked a lightbulb on for me. If your teams are fairly self-organising, if you are small-a agile and building your process as you discover more, you can plan in things like “dev A will spend 50% of this sprint learning dev-ops, without doing feature work or tech debt; and 10% shadowing dev B who already does Ops”. That seems actionable, and measurable. Over two or three sprints/iterations/retrospectives, you’ll probably be able to measure the impact of the training (more successful releases, higher uptime, or more story points covered because ops is less a bottleneck etc).
- sukilot 6y agoBefore OKRs did you have any plans or goals or strategy? How do OKRs relate to devops timelines?
- emptysea 6y agoSimilar story at my place. New executive hired who loves OKRs. Ends up not changing anything because the engineering OKR is “work on the product roadmap” aka what we’ve always been doing. Only lasting impact is there are a few more slides in the company wide meetings.
- polote 6y agoBiggest complain I have with Marty Cagan is he always describes the perfect product organization and says anything else is shit. 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. 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
- sukilot 6y agoIf your business relies on a blogger for its operating strategy, you are doomed.
- inopinatus 6y agoPithy and funny, but counterpoint: we've all surely noted businesses for which this would've been an improvement.
- djohnston 6y agoIt's like the Martin Fowler of business organization
- tempodox 6y agoI had the same thought. What good is the nicest theory when all the practical implementations you can find basically abuse the name for something that is quite the opposite? https://martinfowler.com/articles/agile-aus-2018.html https://martinfowler.com/articles/agile-aus-2018.html
- ryanmarsh 6y agoWell you can't choose your execs, you can't choose your culture Can you choose where you work?
- andrewingram 6y agoThere's some idealism, but the rub with OKRs is that it's obvious that it requires a culture of individual empowerment, at least it always has been from my perspective. It's been a baffling reality of my own startup experience that OKRs get introduced by management teams that aren't willing to truly delegate decisions to individual teams (and perhaps individuals); despite the fact that the entire framework they just introduced, requires this in order to have any real value. After all, what's the value in a tool aimed at providing alignment in decision-making, if nobody actually gets to make decisions? So yeah, idealism, but of a form that's worth aiming for.
- aey 6y agoBD 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.
- leetrout 6y agoWhat is BD, OR and PMF?
- apollo_ 6y agoProbably business development and product market fit. The "OR" I think was just an emphatic "or"
- bretpiatt 6y agoBD = Business Development, aka sales PMF = Product Market Fit Unsure on the OR.
- quickthrower2 6y agoIt think that's just a regular old Or gate.
- aey 6y ago(BD -> Eng Stress) ^ pre PMF
- dboreham 6y agoTell people what's important and what isn't. How innovative. OKRs are for managers who are incapable of telling their staff what's important.
- chetatkinsdiet 6y agoEasy enough in a small org, much more difficult in a big org. Part of the point of OKRs, when done right, are that it shows how the thing you're working on today ladders up to the big thing that drives the entire company forward. That said, in reality it's rarely executed well or with any precision whatsoever. I worked at a 1000 person place whose top level OKRs were so vague they were garbage. You could have created any feature whatsoever and shoed it into those.
- habitue 6y agoThe 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.
- deleted 6y ago[deleted]
- irjustin 6y agoI'm trying to grasp what's wrong with that. That statement is true for every set of system/values. A set of systems won't work for 100% of the cases because that system was designed around a particular team. And there are times it won't work well. Whether the system is good/effective has nothing to do with "you aren't doing it right" part. The "you aren't doing it right" can be applied to literally everything.
- habitue 6y agoThe common thread is that they're frameworks which promise to be very general and be applicable everywhere, but which in practice "everyone does wrong". If no one can actually successfully use your framework the right way, maybe the framework isn't as generally useful as it purports to be.
- irjustin 6y agoAh got it. Having gone through scrum and OKRs I agree with the idea that people tend to sell them to be 'generally' useful at least on the surface. But once we started doing training/testing towards scrum, it's very clear we needed change as an organization. Some people ended up leaving as a result because it's not everyone's cup of tea. I can't say the same for OKRs because I joined and it was already in place pretty effectively, but I imagine it to be similar.
- crooked-v 6y agoMy 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.
- xtracto 6y agoThat's why as a manager I always set my teams okrs to be aligned with whatever crap business is going to place in the scrum stories. I've seen tech OKRs that are things like "reduce tech debt" or "decrease loading time" or "reduce downtime" but without hard tangible stories in sprints, it's just wishful thinking.
- the_other 6y ago> That's why as a manager I always set my teams okrs to be aligned with whatever crap business is going to place in the scrum stories How could it be any other way (and work)?
- xtracto 6y agoIt doesn't, but it is still done. A friend of mine who worked at IBM told me that they had "quarterly goals" that were stuff like "learn a new language" or "improve testing" or any other utopian idea, but their week-to-week sprint stories were completely perpendicular, so at the end of the quarter during the performance review the only people that achieved some of their goals were the ones that stayed to work on evenings and weekends (extra time) to do something related to their goals.
- andrewla 6y agoI 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.
- djohnston 6y agoIts a 2 minute read, go see for yourself
- pitayan 6y agoNot 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. 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. 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.
- jldugger 6y ago> OKR mostly aims at developers Ops can totally have OKRs. Fewer incidents, faster resolution, faster deploy times, longer log retention, decreased AWS spend, the list of objectives I can think of off the top of my head is quite long. Same for project managers: on time projects and reporting, better estimates, faster issue triage, more a/b experiments, more features launched. OKRs done well are effectively a method of improving KPIs by recursively breaking work up into subtasks.
- pitayan 6y ago> OKRs done well are effectively a method of improving KPIs by recursively breaking work up into subtasks I strongly agree. (thumb up) Well, of course Ops can have OKRs as an HR evaluation method. KPI's shortcoming is obvious, most of the results need to have a quantified indicator which is not very appropriate for engineers' situations. But it still can be used as a complementary of OKR to provide clear numbers or date time as a target. I just guess that iterating the OKR every week and month is quite challenging. And most of the OKR stays unchanged even after months of iterations. HR and managers need to figure out the way to keep everyone update their OKR effectively.
- jldugger 6y agoIMO, OKRs should be quarterly targets. Enough time to meaningfully make and measure changes repeatedly.
- bb88 6y ago> The main idea is to give product teams real problems to solve, and then to give the teams the space to solve them. 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. 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) How do you fix a shitty product team, other than replacing the entire team, or product with hopefully a better team? 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. (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.
- CoolGuySteve 6y agoYou will enjoy your career much more if you quit it with this inverse Lake Woebegone philosophy. The idea that all engineers outside of a few Silicon Valley companies are mediocre is laughable if you've ever worked at a FAANG. People pick all sorts of jobs for all sorts of reasons.
- rukuu001 6y agoWe just started using them. We're a small org that's mostly experienced consultants and contractors. They're energetic, proactive and independent people. We've adopted OKRs to basically get everyone pulling in the same direction, but without being prescriptive about how the work gets done. I'll report back at the end of the quarter on how it's working out, if anyone's interested :)
- adamsvystun 6y agoI am totally interested! But how will you report back?
- rukuu001 6y agoI’ll reply here!
- sfgweilr4f 6y agoOKRs? Quote: "OKR’s are first and foremost an empowerment technique." 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. Quote: "Manager’s Objectives vs. Product Team Objectives" 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! 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. Another quote: "The main idea is to give product teams real problems to solve" 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?! Quote: "Passive manager" 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. Quote: "Stop doing manager objectives and individual objectives" 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? Quote: "Leaders need to step up" 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. Ugh! 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. 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. Ok. I feel decaffeinated and that is dis-empowering. Time for coffee. See? Fixable.
- jacques_chester 6y agoI really ought to read an OKR book, because the telephone-game version I hear about seems problematic. For example, Austin's Measuring and Managing Performance in Organizations[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. As a side effect he recreates or overlaps with the "Equal Compensation Principle" (described in Milgrom & Roberts' Economics, Organization and Management). Put briefly: give a rational agent more than one thing to do, and they will only do the most 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. 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' Understanding Statistical Process Control, the authors emphasise that you cannot improve a process that you have not first measured and then stablised. 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: > 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. That last sentence summarises pretty much how I feel about my strawperson impressions of OKRs. [0] https://www.amazon.com/Measuring-Managing-Performance-Organizations-Robert/dp/0932633366 https://www.amazon.com/Measuring-Managing-Performance-Organi... [1] https://www.amazon.com/Economics-Organization-Management-Paul-Milgrom/dp/0132246503 https://www.amazon.com/Economics-Organization-Management-Pau... [2] https://www.amazon.com/Understanding-Statistical-Process-Control-Wheeler/dp/0945320698 https://www.amazon.com/Understanding-Statistical-Process-Con..., though I prefer Montgomery's Introduction to Statistical Quality Control as a much broader introduction with less of an old-man-yells-at-cloud vibe -- https://www.amazon.com/Introduction-Statistical-Quality-Control-Montgomery/dp/1119657113/ https://www.amazon.com/Introduction-Statistical-Quality-Cont...
- cmrdporcupine 6y agoMost 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.
- gorpomon 6y agoI'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. 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.
- kmclean 6y agoThis is totally my experience with OKRs as well. At my last company they were a feeble attempt by micromanagers to manage a bunch of teams into being self-managing. But at the end of the day they were giving us solutions not problems to solve, which obviously didn't work out well. Most of the software we wrote missed the mark and didn't get used.
- hedora 6y ago> Please upgrade to a supported browser to get a reCAPTCHA challenge. Why is this happening to me? 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.
- markalexander 6y agoAn educated guess: reCAPTCHA has become (partly) passive, using whatever tracking data Google has about your behaviour. So, if your browser blocks the tracking, it causes issues. I assume that's what the DDG browser is about.
- jldugger 6y ago> 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. Here, here! 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.
- rufusroflpunch 6y agoMy 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.
- hapticmonkey 6y agoThe core concepts behind OKRs (and others like it) are pretty good. The problem is that almost all of these methods require managers to cede power and control over to the developers. And that rarely seems to happen. So as a developer it just becomes another layer of bullshit to deal with. It pretty much boils down to: Set well defined, well reasoned, and slightly ambitious goals...communicate them to your developers...and then leave them the hell alone to try and accomplish them.
- keeptrying 6y agoThe 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. 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. 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).
- codemac 6y agoConsidering High Output Management literally advertises Management By Objectives, I'm confused how that is a citation for your point about KPIs vs OKRs, they should not look that different. If you're doing OKRs without some type of indicator, kpi or otherwise, I don't see how you're achieving key results.
- Marazan 6y agoOKRs seem a brilliant way to silo your teams and shut down any cross team collaboration. OKRs become a shield to deflect any external request that doesn't precisely align with a measure. Not a fan.
- GauntletWizard 6y agoI'm certain you've got experience to back up this view of them, but you should consider that it's not a failure of OKRs, but of management setting OKRs, that what your teams OKRs weren't aligned with other teams. I've had similar experiences, but I've also had explicitly cross-team OKRs and OKRS that were broadly set on "Respond to needs of customer teams X, Y, and Z" that were among the most successful that I or others on my team picked up. Collaboration should be a goal. A management structure that doesn't explicitly make it one is at fault, and they would have failed regardless of the organizational methodology they chose.
- Marazan 6y agoIn my experience that still just pushes off the problem one layer. Now you've defined who the team can and can't interact with to an even greater degree than not having anything and it totally kills 'spontaneous' collaboration. I am absolutely no rejecting the notion that maybe my company is very bad at doing OKRs but for me they have always resulted in "working to the metric" and have totally inhibit team autonomy - you become ruler by the KRs. EDIT: the first time my company tried OKRs a company culture of collaboration and experimentation was brought to a shuddering halt as everyone stopped trying to do what was best for the business and started trying to hit their OKRs instead.
- jpadkins 6y agoSo you believe collaboration is good, even when it comes at the cost of measurable results? I feel the opposite. There is too much cross team collaboration that "feels good, doesn't do good". OKRs cuts through the BS, and makes you evaluate if your collaboration is actually doing anything measurable. Focus typically has this effect.
- peignoir 6y agoOKRs 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. 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. 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)
- daveungerer 6y agoIt feels 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. 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. If you think your company is one where OKRs won't work, all the more reason to do them. 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.
- quadrifoliate 6y ago> 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. I know this is HN and you could totally be Drew Houston; but I'm going to go out on a limb and say that your company has fewer than 500 employees. The problems the OP is describing are, in my opinion, usually present at a large, bureaucratic company. There is no strict size definition for this (I've seen incredibly bureaucratic 50-person startups), but Dunbar's number [1] is a good rule of thumb. > 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. Once you get into a bureaucratic company, it's largely about avoiding failure or the perception thereof. Since you own your company, it's easy for you to take this overall view of "if it failed, it failed". Any mid-level manager or individual contributor is going to be incentivized to avoid the perception of failure since it's super-bad in a large organization. Google is often used as a counterexample, but I'm not entirely sure that Google is a company that's good at making products. Also, Google uses the approach of "Hire extremely smart people and throw a truckload of money at them" approach which most companies under discussion (including yours) likely don't; which (IMO) is a far better predictor of success than OKRs. > 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. This is the No True Scotsman fallacy. The reality is that the "cascading" nature of OKRs often gets lost in translation and doesn't take into account macro-level changes in your specific vertical. Yes, the company's goal is to become a leader in the field of underwater baskets; how does this translate to me rewriting that terrible frontend code that the cofounder's buddy wrote in 2007 and has never been touched since? Doing that translation will become more difficult year by year due to how technology evolves; and most people in "leadership" suck at doing that translation well. That's what the article is talking about. [1] https://en.wikipedia.org/wiki/Dunbar%27s_number https://en.wikipedia.org/wiki/Dunbar%27s_number
- Mindwipe 6y agoGood piece 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). 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.
- Warren08Byron 6y agoIf you are really in need of getting a best result about your credit report am using this opportunity to introduce you to this Notorious, Wonderful and Bankruptcy Problems Solver Hacker. You will never get to know until you gave him a trying space to proved him self and let his job speak, He help me hack my FICO score and also help me with some adjustment on my Report too. all you need is e-mail PERMANENTCREDITREPAIRER@GMAIL.COM you’ll be guided to your success destination.
- Warren08Byron 6y agoIf you are really in need of getting a best result about your credit report am using this opportunity to introduce you to this Notorious, Wonderful and Bankruptcy Problems Solver Hacker. You will never get to know until you gave him a trying space to proved him self and let his job speak, He help me hack my FICO score and also help me with some adjustment on my Report too. all you need is e-mail PERMANENT CREDIT REPAIRER @ GMAIL (.) COM you’ll be guided to your success destination.
- tomjen3 6y agoObjectives and Key Results for those who are confused.
- trwhite 6y agoMy 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.
- andrewingram 6y agoI've definitely seen it where objectives don't need to be measurable, but the results are what you measure to let you know if you're going in the right direction. Sometimes you might have objectives that look like results (like a top-line revenue target), but yeah... Good luck :)
- kmclean 6y ago> ... 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. 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. 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. 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.
- geebee 6y agoI 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. 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. 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. 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). All I'm sayin' is, this could go sideways. But then again, so can any job.