15 ms·

OKRs from a development team’s perspective

317 points by thinksocrates 7y ago

vikramkr 7y ago
If the items in the backlog aren't related to the OKRs, then it's possible that they should be thrown our with the new cycle like the author says, but I wonder if it could mean that the OKRs need to be changed in certain situations as well. If there are things the teams value in the backlog that aren't part of any OKRs, and the dev teams are in some sense closer to the product than upper management, then that input should be filtered back up to be considered by upper management since the teams "on the ground" might be seeing information that the management doesn't have.
- thinksocrates 7y ago
  Great point. Could definitely point to leadership being out of touch with what really needs done.
- henrikschroder 7y ago
  In many companies, engineering puts out fires, prevents disasters, gets rid of tech debt, etc. In short, engineering does a lot of maintenance that is needed to keep the entire company afloat. If that work stops, the company will go bust. It's such an obvious key objective, it should be in every top-level OKR, yet it almost never is, which means that there's nowhere the engineering department can slot in that work. And how do you measure it?
jedberg 7y ago
Man I wish I had read this seven years ago! We tried doing OKRs on my team and it never seemed to work. We ended up just throwing it all away at the end of the quarter and listing what we actually accomplished. And I think it was because we were doing what the author says and shoehorning in our backlog into the OKRs! I was really soured on OKRs because of it. Now I want to try again doing it “the right way”.
- thinksocrates 7y ago
  Would love to hear if you're able to make it work by adjusting the details of how it's carried out.
dpcx 7y ago
We've been doing OKRs at my employer for a while. It's always really difficult for the development team to come up with ideas because we know that there's a higher than average chance that we'll get pulled to work on something that's unrelated to the OKRs we've come up with; and while everyone says we're not being judged on our OKRs, _someone_ is keeping track, otherwise they're not really useful. I'll be reading and re-reading this article for a while.
- thinksocrates 7y ago
  Thanks for another example of how OKRs aren't working for devs. A part of the inspiration to write this was that I noticed most developers feel that something is wrong with the OKR process, but they can't put their finger on exactly what.
- carc 7y ago
  This seems like there isn't buy-in to the OKRs across your employer. My company does OKRs and it's taken seriously by VPs as well as the devs. Here, it's very reasonable to say no to something (and have that be respected) because it's not contributing to your team's OKRs. If it's a VP or something and insists it needs to be done then that means the OKRs need to be updated to reflect the nature of this work.
- cdeonier 7y ago
  I work at at company that does OKRs as well. I think I've viewed both the symptoms you described and the common pattern described in the article of fitting an existing backlog to OKRs. I think one observation that I have is that OKRs are really a framework to help teams understand what direction/goal to head to and understand progress toward that goal. And really, this mindset needs to be adopted not just by the development teams-- it needs rigor and consistency from leadership as well. For example, the leaders are accountable for setting direction and describing what they think is important. If they then start asking you for things that aren't tied with an OKR, it's a perfectly fair question to ask leadership "Why are you asking me to work on this when you indicated it's not important to our company strategy?" If the team feels like they're going to be working on something unrelated to their OKRs, that's symptomatic of leadership not sending a consistent message on strategy or prioritization. I've also seen it from the other side as described in the article. I've seen development teams really struggle to initially understand OKRs and the value. As mentioned earlier, it's really designed to help clarify direction and progress-- if a team is ignoring the OKR and fitting their backlog, that's symptomatic that they're really not trying to understand the direction leadership wants to head. What I like about the author's suggestion is that it really forces the team to understand the problem the organization is trying to solve and think up solutions how to achieve it. Backlog bankruptcy is one way to do it, though there are likely some items that can still solve the problems outlined in the OKR. Those items just shouldn't automatically be transferred over without verifying they solve a problem that needs to be solved. Teams shouldn't be fitting problems to work-- teams should be fitting work to problems.
superfrank 7y ago
This put my thoughts on OKRs into words better than I ever could. At my last two companies, I've been beating the drum that the closer to an individual level you get the less useful OKRs are. The backward process of, "we know what we are going to do, how to we make it fit the OKR formula" drives me insane. Personally, I actually like OKRs at the organization or large sub org level. I think they are great at getting everyone moving in the same direction and letting everyone know what matters. My problem is that as you drill down into an organization you need to switch from the "Why are we doing this?" and "What are we measuring?" questions and instead as "Exactly how are we going to do this?" which doesn't really fit into the ORK structure. Personally, I find that once you get down to a group of about five people or less, creating a list of tasks is far more affective than OKRs.
- cpeterso 7y ago
  Spotify decided to stop using OKRs for individuals for these same reasons. They wrote about their experience here: https://hrblog.spotify.com/2016/08/15/our-beliefs/ https://hrblog.spotify.com/2016/08/15/our-beliefs/
- maxxxxx 7y ago
  Exactly. Individuals are far away from the actual organization goals. In my yearly review I have to categorize my achievements by stuff like "Supporting growth", "Fueling worldwide expansion", "Increasing customer satisfaction" and so on. I am very far away from any of these so either I indirectly support all of them or you could also say I support none of them. Just filling this out makes it clear that most of the company is about bullshitting each other.
  - 0x445442 7y ago
    This sums it up well. If all your achievements, with the exception things like professional growth, was not directly derived from these high level OKRs then middle management has failed in the assignment of work. The hilarious thing where I work is at the end of each week I have to manually enter the hours I worked and I have N charge numbers to split up those hours. If you read the line item for each charge number it's basically a synopsis of one or more OKRs. All this to say, from an engineer's point of view it seems with just a few tweaks in JIRA and Gitlab, review input could be created by running a report on commit history over the date range the review covers.
swanson 7y ago
> Objective – Increase Customer Retention > Key Result #1 – Lifetime Customer value increase from $N to $N+5 > Key Result #2 – Decrease Customer Churn Rate by 10% I'm a developer on a team. How am I supposed to know why customers are churning? I'm three levels removed from talking to customers when they cancel. I don't have a deep relationship to know how to add value to them. Someone needs to do the research, analysis, and leg work of finding potential areas to exploit. And then someone needs to have at least some amount of vision or inspiration about how to solve that problem. Or do whatever trendy new "design sprint feedback loop" brainstorming session someone is tweeting about. This is the kind of stuff I hear designers and "product people" talking about wanting to do. If you want to do that work and then loop in the engineering team to talk about feasibility and planning that seems fine, but the last time I worked in an environment with OKR no one seemed to have any brilliant ideas about how to, you know, actually achieve the Key Results. (Until these questions can be satisfactorily answered to developers, OKRs are going to be perceived as a buzzword, flavor of the month process air-dropped in because someone saw a blog post about it)
- maxxxxx 7y ago
  That’s a huge problem with the whole idea of providing value to the business. Some people can show real metrics but a lot of us are several layers away from anything quantifiable so either you have nothing to show or you have to make up some bullshit metric as I often see in resumes.
  - avip 7y ago
    Slightly off, but the whole "business value" in IT resumes is proper a US thing. Cross the border and you're good with just mentioning what you did, sans the (often imaginary) "impact".
- nlawalker 7y ago
  Yeah, this wasn't at all what I thought it would be about, which is the difficulty (impossibility?) of measuring developer impact against key results. When you're a salesperson, you don't have to agonize over how to illustrate that you've "Decreased Customer Churn Rate by 10%". When you're an assembly line worker, you don't have to find a way to figure out how you contributed to "produce 15% more widgets". You either accomplish these things or you don't - they are literally descriptions of your performance in your job. Either way, nobody cares how you did (or didn't) do it. When you're a developer, how are you supposed to show that you've helped "increase customer value from $N to $N+5"? Because "shipped the new version of the message queuing system" is not in anyone's list of key results. OKRs feel like "organized SMART goals", and so I have the same criticism of them as I do of SMART goals: they're just another way of conceptualizing goals around things that are already easily and directly measured. No one has made any progress in quantifying the contributions of roles that don't have direct percentage impacts on dollars earned or dollars saved.
msoad 7y ago
Metric-obsessed management systems often miss on quality.
- maxxxxx 7y ago
  Or they invent a lot of bullshit metrics because in reality a lot of work is very hard to quantify.
  - asark 7y ago
    The one place I worked that tried to do this, the developers mostly ended up doing things easy to measure. Turns out it's super-easy to measure views and shares so content marketing it is! Not exactly a good use of our particular abilities but it seemed to make everyone (who was pushing the OKRs) happy. Our real work could rarely be connected to any kind of OKR. Too hard to measure and, "this OKR thing seems cool, we should gather data for at least 2 years on X, Y, and Z for a baseline averaged across projects so we can create OKRs to improve them" didn't fly, obviously. So. Youtube videos and blog posts it was.
- malyk 7y ago
  If quality is important (it isn't always), then it should be one of the OKRs!
rocky1138 7y ago
This is interesting. I wonder how much of a depressing effect throwing away the backlog every time will have on contributions from people on the team who have good ideas but are not super vocal, e.g. "what's the point of saying my ideas when they'll just be thrown out next time we do planning?"
- jedberg 7y ago
  I think the hope is that management looks at the backlog and uses that to guide their OKR creation so that there is a meeting in the middle of the upper level OKRs and the backlog.
madrox 7y ago
Leadership is hard. Gaining alignment around goals is hard. Even if you state a goal, getting timely execution is really hard. OKRs are great in that they are specific and measurable, so you can have a concrete conversation on if performance is adequate. The problem with OKRs is goals can be hard to quantify, so it's attractive to simply make OKRs out of things you CAN measure. This is why we get companies that optimize for clicks at all costs, and twitter accounts that buy followers. If you're thinking about backlog bankruptcy, it's probably because your team is considered to be struggling. If so, it's attractive to think the process of delivering on the OKR is the problem. However, in my experience the real problem is that leadership hasn't done a great job of defining OKRs that properly align teams on the mission at hand. But good luck telling that to leadership.
- loteck 7y ago
  Completely agree, this post looks classically to me like a team toiling under leadership that picked OKRs as the measurement system for employees but not for leadership. How many OKR rollouts are plagued by lack of adoption in the C suites? Who here is shocked to find a system is malfunctioning because employees are trying their best to engage with it, but leadership can't or won't do their part? OKRs in particular are hugely reliant on leadership defining goals for others to align with. Measurements and progress are cultural. It either starts and continues from the top, or it's defective.
residentfoam 7y ago
OKRs could drive some value BUT in my experience they are hard to maintain and update. Most companies keep their OKRs in huge spreadsheets, some even have dedicated people to maintain that insanity. Teams then work with different tools, e.g: Marketing use Trello, Eng use Jira, you name it and now you have to trace back tasks from different tools to some OKRs defined somewhere in the cloud ... good luck with that. It's nearly impossible to measure and reconcile progress made on team/sprint basis with OKRs therefore you just shovel random numbers in the spreadsheet and management is happy. When an OKRs is updated good luck cascading the changes bottom <=> up . I have yet to find a company that has implemented OKRs in an effective way. Most of the time managers themselves tell you : "just write something .. it does not really matter" hahahah and there you go ... At the end of the day people have to do OKRs but they keep asking themselves ... why ?
- tadasv 7y ago
  Shameless plug, but check out my tool for managing OKRs outside of spreadsheets if this is something you're looking for https://simpleokr.com https://simpleokr.com
  - phiggins 7y ago
    we've been looking at gtmhub.com for a minute, are you considering a Jira integration?
  - fivre 7y ago
    Do you have a companion tool whose purpose is to convince Excel devotees that modern, domain-specific tooling exists, and that they should stop pushing Excel because it's terrible for many tasks? My problem is less that no tools exist to manage things outside of spreadsheets, but more that older management tends to take the position of "Jira (or whatever) is complicated and I already know Excel, and I'm in charge so we're using whatever doesn't require me to learn something new".
    - marcinzm 7y ago
      The problem with domain specific tools for project management is that everyone has slightly different goal, priorities and requirements. So you end up with a mess of a tool that barely works (Jira) or one that's missing necessary features. Then someone decides they could do it faster and better in Excel.
staticassertion 7y ago
OKRs just feel like waterfall with "metrics" slapped on to make it sound legitimate. The idea that I can predict what I should be working on for a full quarter, and know how to measure it in advance, is inane. Been working under this system for 1.5 years and I think it's nothing but a detriment. I did research into doing OKRs "right", watched videos, really tried to give it a fair shake, too.
- dvirsky 7y ago
  I look at them as a useful way to plan and estimate. It's okay if priorities shift or if you realise something will take longer, or that you actually need to work on something else right now and some KR will be pushed to next Q, etc. And it's perfectly fine not to meet some of your OKRs. I think of them as a compass rather than a paved road.
  - staticassertion 7y ago
    If it's ok to shift priorities 3 weeks into OKRs and push them to the next quarter why was it important to have them at all? Do you now need to measure the new work that's prioritized? It's totally fine (and encouraged, in fact) to not pass every OKR, but I don't see any point to them. All of the failures of waterfall that everyone has always been aware of, but with the additional work of stating how you'll measure it, so that finance knows who to pay more.
    - dvirsky 7y ago
      As I said, look at them as a compass - a map will be a better analogy maybe - this is what I want to achieve at the point in time I'm making my plans, and here's how I'm going to achieve it. As long as that doesn't change, it's useful to break down a vague goal into milestones and evaluate on occasion (my team does it every 2 weeks) how you're progressing. But it's okay for that to change, and then you just write new OKRs.
    - groby_b 7y ago
      If you have no idea where you're going, and no metrics at all, how do you reasonably pick any tasks? So, clearly, you have some goal. It's likely also measurable. If you pick it so specific that you can't stick to it, yeah, OKRs are nonsensical. But "make money" or "increase conversion rate" or "find market fit" are clearly meaningful goals, no? The difference from waterfall is that OKRs don't prescribe a "how". They describe a desired outcome. Guardrails within which you can be as agile as you want, just get some results.
kradroy 7y ago
We started using OKRs this past year. I can't tell you what our current OKRs are. We even create "sub-OKRs" that align with the higher level OKRs. It feels like a pointless exercise, because we do what the author describes: slap labels on items in our backlog that sorta-kinda relate to an OKR. The author's suggestions aren't terribly complete or practical. I don't know many teams who could just dump their backlog every quarter. You're going to have work that can't be related to OKRs. We do use the OKRs to drive our weekly meetings and sprint planning. One suggestion I have is just to accept all work isn't OKR related and reserve capacity for that work. If some PM or manager complains, push back.
- baxtr 7y ago
  This is exactly what we do. We reserve about 25% of every team's capacity for "other" stuff, e.g. maintenance. The PMs/leaders have to acknowledge for that when they compile their OKRs.
  - Terretta 7y ago
    This just means someone somewhere has an unstated objective that things be maintained. Make them write it down, and then your 25% capacity supports that.
    - baxtr 7y ago
      The O is clear. What’s the KR for you? (Driving a KPI from one number of another)
jph 7y ago
OKRs are excellent-- I manage a repo about OKRs where you can see examples and contribute ides. The article author is exactly right: use OKRs to drive your weekly team meetings. https://github.com/joelparkerhenderson/objectives_and_key_results https://github.com/joelparkerhenderson/objectives_and_key_re...
- hrktb 7y ago
  From the Google examples: > a team is encouraged to set as goals about 50% more tasks than they are likely to actually accomplish. > If a team scores significantly higher than that, they are encouraged to set more ambitious OKRs for the next quarter. I lived through this in Scrum sprints. There is a baked in incentive to sacrifice some iterations every once in a while to ajust the average expectation, while keeping an overall positive look. Otherwise without having used it seems to me that OKRs are another rather plain tool that works for clever organisations but fails when applied dumbly. Is there anything specific to it that makes worst case scenarii better ?
ltc5505 7y ago
Would it kill people to expand the acronym on first use? For example: "Most of the companies I’ve worked for in the last 5 years have used the objectives and keys results (OKR) system." I'm not sure why this common practice in text is seemingly disappearing on the web.
- asark 7y ago
  There's even a tag for it. Not that anyone cares about what HTML can do anymore.
alain94040 7y ago
If you're into OKRs, a friend of mine built a tool open to all: https://general-internet.zendesk.com/hc/en-us/articles/360013429514-Why-how-what-is-GI-OKR- https://general-internet.zendesk.com/hc/en-us/articles/36001... Interested in feedback.
deleted 7y ago
[deleted]
the-pigeon 7y ago
Making decisions based off an any metric is very dangerous and the downfall of many products. You MUST have a deep understanding of exactly what that metric is measuring and all of the things it doesn't take into a account. For a concrete simple example. An A/B test may sure that forcing users to create an account before seeing shipping charges increases order completion by 10%. But then it turns out you've reduced return visits to the site by 30% and decreased overall conversion rates due to damaging that funnel. Reality is very complex. Trying to boil everything down to a few numbers to make decisions based on seems like it simplifies things but often times you are just ignoring the complexities and flying blind by chasing metrics.
tmaly 7y ago
I saw the creator of OKRs, Andy Grove, speak years ago out at Intel in Oregon when I was doing an internship. I don't recall the product development group I was in using them. Maybe they were implemented at a much higher level in the company.
tzakrajs 7y ago
No mention of Key Performance Indicators? Why?
- dboreham 7y ago
  Everyone is too old to remember that this is what we called OKRs before? I forget what they were called before that..
- Terretta 7y ago
  MBO and KPIs are different systems stemming from different philosophies about how to frame objectives and how to measure what matters.
Apreche 7y ago
I write software that is used entirely internally by the company. We are building something completely new from scratch that is not yet live. OKRs were recently introduced at our company. The only OKR I can even think of is "get this thing functioning and in production". Just a boolean. I wanted to come up with something measurable, but what is there to measure? I don't understand how OKRs are appropriate for employees without the power to make business decisions. My only goals are to come into work, do what is expected of me, get paid, not get fired, and go home. I do not have power to decide anything with quantifiable results. If I did, writing OKRs and working towards them would be extremely easy. If I did have any power to make business decisions one of the first things I would do is make any employee without any power exempt from having to even think about stupid OKRs.
- yitchelle 7y ago
  Some ideas of what you can measure... Software is usually written to help reduce effort. Measure effort with and without the software. Reduce effort usually means better bottom line for the company which give you a great positive for your next performance review. Meaure the usual software engineering metrics, ie defect count, defect closed, velocity, delivery timing etc. I think that everything that we do in a company has a cost for the company. At the most basic level, you and I cost money as the company is paying us money for the work we do. You need to think from that perspective.
- alexhutcheson 7y ago
  Break it down into milestones. What's the minimum piece you could complete that would be usable by someone (even just a beta user to gather feedback)? What's the next incremental piece that would be useful after that? You can measure milestones completed, and you can also apply some type of scoring to the feedback you collect from your beta users. If your beta user feedback is "This is terrible, it doesn't do the key thing we need to do for our jobs!", that's actually a great outcome, because you can course-correct early, rather than having to revisit 1+ years of eng work to address the feedback. > My only goals are to come into work, do what is expected of me, get paid, not get fired, and go home. OKRs should just be the process of you writing down "what is expected of me" in a somewhat structured and measurable way. Team OKRs of "Hit milestones #1, #2, and #3 in development roadmap of system X" are fine, and are pretty common for greenfield projects. The main key is to have a "definition of done" for each milestone - does the milestone include documentation? Monitoring? Who decides that work is complete?
kenhwang 7y ago
My company has been using OKRs for several years now and the author perfectly describes what the engineering team does. We scan through our backlog, slap some nice OKR tags on items that are vaguely relevant, and then ignore the OKRs until the next quarter. The more politically savvy members of the team then spin some BS to make everyone buy that the work engineering is doing actually supports the OKRs. My personal opinions of OKRs are that it's possibly the most cumbersome form of waterfall without many of the few benefits of waterfall. It's really a tool for making leadership feel good about being bad at their job.
- astral303 7y ago
  I agree. OKRs are renamed MBOs. This is extrinsic motivation and a giant waste of time. At best, it’s a process-heavy priorities setting/strategizing mechanism. At worst, it causes unnecessary employee anxiety and distraction away from current business needs. Any measurement that is a metric (goals in OKRs) will cease being a metric. It will be gamed.
  - Terretta 7y ago
    MBO and OKRs are not (supposed to be) the same methodology. Their proponents decades back were of opposing views on how to manage.
deleted 7y ago
[deleted]
jrochkind1 7y ago
> I think it gives leadership the justification they need to declare that everyone is working towards the same goals, but I don’t think it leads to dev teams actually feeling like that’s true. The more important thing is whether it's actually true, not whether dev teams (or leadership) feels it's true, no? But the OP indeed seems to describe an environment where it is not actually true either. Clearly, thought and planning is needed on how people work, in a way that will be directed to actually addressing OKR's. The OP offers suggestions about abandoning backlogs, and focusing weekly meetings on OKR's, which seem possibly beneficial, but probably not sufficient. I think it probably requires more fundamental shifts in how the whole organization works, which are a lot harder than just publisizing OKR's.
m0zg 7y ago
OKRs are merely a mechanism for generating public commitment to goals. You get to have a bit of a say what those goals are, but fundamentally they're about holding your feet to the fire after you spent a quarter bullshitting on Reddit because nobody in the organization has a foggiest clue about what needs to be done. Understand OKRs for what they are, and you'll be a much happier developer. Don't treat them too seriously, use them as a productivity mechanism _for yourself_. Now, even if nobody knows what needs to be done, you can refer to your (approved) OKRs and do _that_, whether it makes sense a month after the quarter started or not. I don't know how it is now, but at e.g. Microsoft in the 00's you'd set your goals once a year. A month later those goals were completely irrelevant to what actually needs to be done. And Microsoft is objectively one of the most successful software companies in the world. Waterfall, agile, OKRs or yearly goals, it doesn't matter. The reality is always dictated by circumstances. What matters is that every single thing I worked on while there makes money now, and a couple make billions a year.
codingdave 7y ago
I've only seen this in large companies, not startups or software shops, but it was never a single layer of OKRs. It was a set at each management level. The CEO would define the top-level OKRs. Their direct reports would ask themselves, "How can I contribute?", and build a more detail set of their organizations OKRs, that rolled up to support the CEOs. Every layer of management down the chain did the same. And the individual contributors set personal goals that supported their direct manager's OKRs. No system is perfect, and this one had its annoyances. But it did tie everything from personal goals all the way up to the top-level corporate goals, which resolves many of the concerns from the article.
- loteck 7y ago
  The trick here is: what happens if the CEO is unwilling to pin herself down to specific goals, for any reason, but especially because she has no goals or is afraid to be seen failing those goals? Either leadership doesnt engage with OKRs, tasks are deliberately misinterpreted as goals, or unmeasurable goals are set. The rest of the company's OKRs then follow this example, and everyone suffers.
  - codingdave 7y ago
    In such a case, you have bigger problems than OKRs.
- cortesoft 7y ago
  This hasn't been the case in my experience at a 200,000 person company. The OKR's I hear about are so far separated from what my teams work on, that it is impossible to even pretend our work relates to it.
jofer 7y ago
So far, all companies I've seen that use OKRs operate something like this: Start of quarter - Management: We need to increase X. Dev: Okay, here's how I'll break that down... (key results) One month later - Management: Everything's changed... Y is the top priority now! Dev: Okay, that means we should focus on fozbuzzles. One month later - Management: Oh, man, what we really need to focus on is Z! Dev: Alright, we can do that if we de-emphasize X and Y. Let's get Z done! End of quarter - Management: You didn't meet any any of your OKRs other than Z! Dev: ...but you told me to drop X and Y... Honestly, I've never seen an OKR that was relevant by the end of a quarter... We finish them or not, but the objectives are always wildly different every few months and priorities change. Frankly, the start-of-quarter OKR system is incredibly disheartening... None of my major accomplishments or the primary focus of my work ever winds up being recorded, as only the items set at the first of the quarter are evaluated. I've worked at other places (outside of tech) where the emphasis was on recording what you worked on and why at the _end_ of the quarter. In my experience, it's smoother for everyone. I'm a bit surprised at the focus on quarterly, pre-set OKRs in tech... It seems like a more adaptive process would be better for everyone.
- superfrank 7y ago
  > Honestly, I've never seen an OKR that was relevant by the end of a quarter... We finish them or not, but the objectives are always wildly different every few months and priorities change. I think there are two types of priorities, "fires" and "nice to haves". Fires are high priority, unpredictable, and often need to be solved quickly. This is things like "our databases crash every morning" or "our AWS bill is too high and going to put us out of business". Nice to haves can still be needed, but they tend to take a back seat when a fire happens. Additionally, their priority tends to be much more subjective. This is things like "Our build process takes too long" or "our deploy process has too many manual step which leads to human error". OKRs tend not to last a full quarter because any tasks/priorities that you can schedule and make fit nicely into a 3 month period are "nice to have"s. I'm not saying they don't matter, but the timeline to get them done doesn't really matter so things get delayed or moved around. On the flip side, you can't schedule fires and you usually can't delay them either. The things that actually important enough that they can't get delayed tend not to fit the OKR framework.
maxxxxx 7y ago
Seems this tends to go exactly the way Scrum and Agile did. If done correctly by the whole company it works well. But in most cases it will probably be a mandate by top management and the rest has to come up with some nonsense metrics and objectives and just play a game. I think more and more any methodology will work if followed honestly and adapted to real world problems. In the end it's always the disconnect between what an organization claims to do vs what it really does. If that disconnect is small things are good, but in a lot of cases the disconnect is big.
Justsignedup 7y ago
As an engineer OKRs are a bit of a conflicting thing, and here's the reasons... - I don't decide what projects come my way. Product or management decides that. - My concerns are: "Is the company going to be around for > 6 months?" because if the answer is yes than my concerns are "In 6 months, make sure we don't hit a wall that will be a stop all development situation". I've seen it. - OKRs are always going to be goals of the company. My question will always be: What can eng do to actually affect these OKRs? Are customers leaving due to bugs? Eng will prioritize bugs. Are customers leaving due to lack of features? Eng will build features. Is the company about to run out of money? Eng needs to build as much and as fast as possible and ignore any long-term problems because we need to get customers. Basically either department heads need to take the current OKRs and transform them into department specific OKRs or they become meaningless. There needs to be engineering OKRs around things that engineering can affect. Not product OKRs which product will affect. Not sales OKRs which sales affects. Example of a product OKR: - increase customer conversion rates by 0.5% every 2 weeks for the next 2 months. Example of an engineering OKR: - enable product to A/B test - enable product to measure more data points to make decisions to reach their OKRs
blazespin 7y ago
OKR at an individual level work fine, but they need to be positioned as an individual OKR. For example, reduce bug count report by 10%. Or, increase LOC by 10% without reducing quality (defined as bugs, DRY, PR comments), increase documentation written by 10%, increase Slack karma by 10%, etc Obviously other metrics other than the OKR need to be maintained. PRoduct owner is responsible for OKRs that scope across stories implemented, not ICs. Or at least not junior ICs. Architect level IC for example should be able to complete more broad scope.
vinay_ys 7y ago
OKRs do force you to put down your company's priorities and metrics to measure their success. Unable to do that usually is a symptom of being too tactical and reactive and not having a strong strategy/vision. Company-level OKRs are only as good as your leadership team's clarity on strategy and long-term direction and conviction to largely stay the course for at least 3 month chunks. If you feel your company OKRs are bad or you are unable to connect with it, it is because your leadership team has not done the necessary homework to define and socialize it well. If you agree your company OKRs make sense but you are unable to connect it to your work, think of it this way: For a functional feature engineer, the team OKRs should clearly and directly connect the features they are working on to the company OKRs. If not, then you need to engage with your product managers to achieve that clarity. For a senior platform engineer responsible for evolution of tech platforms, it is critical to have a good sense of the direction in which business will evolve and expand. (Annual OKRs and strategy articulations are crucial for this). From this, you should be able to draw out a mind map of the kinds of features and capabilities needed by your platform. Then you can articulate this to your team to build those required enhancements to the platform while also ensuring immediate feature building activity is moving as productively as possible. If you are unable to connect the dots between the business OKRs and tech platform OKRs, it is usually a sign that there isn't a good functional model for your business domain and your tech platform isn't really a platform that supports that functional model. For architects, this should be the most important deep work – to keep the functional model of the business and that of tech platforms in sync. Without this common model, teams cannot collaborate effectively.
dijksterhuis 7y ago
OKRs seem like a fancy new version of KPIs. My single biggest issue with KPIs is that, for the most part, in a large company, one (or even several) metric(s) cannot cover the whole story. They are useful for very specific targets. I’ve ended up working towards KPIs which I’ve known have zero relevance to improving service because they are (a) poorly defined (b) irrelevant to the actual problem (c ) force a metric to exist where no sensible metric can. Unfortunately this tended to happen more often than not. OKRs have their place. But they don’t sound like something new (KPI rehash) and are wide open to misuse, just like KPIs.
- hj7n 7y ago
  Hi Dijksterhuis, Some organizations do indeed move from KPIs to OKRs. I personally think they are different tools for different purposes, and they could work well together. I believe KPIs are a great tool to define and monitor your business as usual, whereas OKRs is more about realizing your ambitions and pushing the company further ahead. If it helps, more info here: https://www.perdoo.com/blog/kpis-okrs-the-goals-that-drive-business-success/ https://www.perdoo.com/blog/kpis-okrs-the-goals-that-drive-b... Best, HJ
bezoisevil 7y ago
OKRs are so dumb
ibeckermayer 7y ago
Is there no limit to the bullshit dopey “management consultants” will come up with an acronym for? “OKR’s”? Oh, do you mean creating some objective and then working towards it as a team? Measuring progress through some empirical metric? You know, the same process humans have engaged in since the dawn of our species? What a load of garbage.
apinstein 7y ago
In our use of OKR, we was concerned about this as well. Having to use mental gymnastics to make things work is a bad sign. The way we thought about it was that OKR should not dictate 100% of effort. OKR is about prioritizing the changes that leadership wants to make at the productivity frontier of the organization. OKRs alone are not enough to direct company efforts. Leadership also needs to specify what % of energy should be spent on OKR vs other responsibilities. The OKR effort goal could be between 0-100 for different teams, or the company as a whole. For instance, a company that needs to pivot or will die is probably close to 100% OKR effort on all teams. This approach gets around the need to assign OKR to every activity and allows OKR to be more salient and less diluted as a tool for alignment and goal setting.
LittlePeter 7y ago
> Where OKRs become less useful is within the decision making process for an individual team. > Joe Cannatti Anyone else put off by the author quoting himself?
simplecomplex 7y ago
I’m so sick of the software industry expecting developers to do the work of the entrepreneurs for them without any of the upside. Why the fuck should I help the owner get rich by identifying how to grow their business by increasing conversion, retention, etc.? I don’t benefit at all. At my current company we have weekly meetings where the owners tell us all the business metrics we should be driving and ask for ideas on how to increase them. I’ve learned to say “I don’t have any specific ideas right now.” because it’s insulting they expect me to do their work and get nothing for it.

317 points by thinksocrates 7y ago

If the items in the backlog aren't related to the OKRs, then it's possible that they should be thrown our with the new cycle like the author says, but I wonder if it could mean that the OKRs need to be changed in certain situations as well. If there are things the teams value in the backlog that aren't part of any OKRs, and the dev teams are in some sense closer to the product than upper management, then that input should be filtered back up to be considered by upper management since the teams "on the ground" might be seeing information that the management doesn't have.

thinksocrates 7y ago
Great point. Could definitely point to leadership being out of touch with what really needs done.
henrikschroder 7y ago
In many companies, engineering puts out fires, prevents disasters, gets rid of tech debt, etc. In short, engineering does a lot of maintenance that is needed to keep the entire company afloat. If that work stops, the company will go bust. It's such an obvious key objective, it should be in every top-level OKR, yet it almost never is, which means that there's nowhere the engineering department can slot in that work. And how do you measure it?

jedberg 7y ago

Man I wish I had read this seven years ago! We tried doing OKRs on my team and it never seemed to work. We ended up just throwing it all away at the end of the quarter and listing what we actually accomplished. And I think it was because we were doing what the author says and shoehorning in our backlog into the OKRs! I was really soured on OKRs because of it. Now I want to try again doing it “the right way”.

thinksocrates 7y ago
Would love to hear if you're able to make it work by adjusting the details of how it's carried out.

dpcx 7y ago

We've been doing OKRs at my employer for a while. It's always really difficult for the development team to come up with ideas because we know that there's a higher than average chance that we'll get pulled to work on something that's unrelated to the OKRs we've come up with; and while everyone says we're not being judged on our OKRs, _someone_ is keeping track, otherwise they're not really useful. I'll be reading and re-reading this article for a while.

thinksocrates 7y ago
Thanks for another example of how OKRs aren't working for devs. A part of the inspiration to write this was that I noticed most developers feel that something is wrong with the OKR process, but they can't put their finger on exactly what.
carc 7y ago
This seems like there isn't buy-in to the OKRs across your employer. My company does OKRs and it's taken seriously by VPs as well as the devs. Here, it's very reasonable to say no to something (and have that be respected) because it's not contributing to your team's OKRs. If it's a VP or something and insists it needs to be done then that means the OKRs need to be updated to reflect the nature of this work.
cdeonier 7y ago
I work at at company that does OKRs as well. I think I've viewed both the symptoms you described and the common pattern described in the article of fitting an existing backlog to OKRs. I think one observation that I have is that OKRs are really a framework to help teams understand what direction/goal to head to and understand progress toward that goal. And really, this mindset needs to be adopted not just by the development teams-- it needs rigor and consistency from leadership as well. For example, the leaders are accountable for setting direction and describing what they think is important. If they then start asking you for things that aren't tied with an OKR, it's a perfectly fair question to ask leadership "Why are you asking me to work on this when you indicated it's not important to our company strategy?" If the team feels like they're going to be working on something unrelated to their OKRs, that's symptomatic of leadership not sending a consistent message on strategy or prioritization. I've also seen it from the other side as described in the article. I've seen development teams really struggle to initially understand OKRs and the value. As mentioned earlier, it's really designed to help clarify direction and progress-- if a team is ignoring the OKR and fitting their backlog, that's symptomatic that they're really not trying to understand the direction leadership wants to head. What I like about the author's suggestion is that it really forces the team to understand the problem the organization is trying to solve and think up solutions how to achieve it. Backlog bankruptcy is one way to do it, though there are likely some items that can still solve the problems outlined in the OKR. Those items just shouldn't automatically be transferred over without verifying they solve a problem that needs to be solved. Teams shouldn't be fitting problems to work-- teams should be fitting work to problems.

superfrank 7y ago

This put my thoughts on OKRs into words better than I ever could. At my last two companies, I've been beating the drum that the closer to an individual level you get the less useful OKRs are. The backward process of, "we know what we are going to do, how to we make it fit the OKR formula" drives me insane. Personally, I actually like OKRs at the organization or large sub org level. I think they are great at getting everyone moving in the same direction and letting everyone know what matters. My problem is that as you drill down into an organization you need to switch from the "Why are we doing this?" and "What are we measuring?" questions and instead as "Exactly how are we going to do this?" which doesn't really fit into the ORK structure. Personally, I find that once you get down to a group of about five people or less, creating a list of tasks is far more affective than OKRs.

cpeterso 7y ago
Spotify decided to stop using OKRs for individuals for these same reasons. They wrote about their experience here: https://hrblog.spotify.com/2016/08/15/our-beliefs/ https://hrblog.spotify.com/2016/08/15/our-beliefs/
maxxxxx 7y ago
Exactly. Individuals are far away from the actual organization goals. In my yearly review I have to categorize my achievements by stuff like "Supporting growth", "Fueling worldwide expansion", "Increasing customer satisfaction" and so on. I am very far away from any of these so either I indirectly support all of them or you could also say I support none of them. Just filling this out makes it clear that most of the company is about bullshitting each other.
- 0x445442 7y ago
  This sums it up well. If all your achievements, with the exception things like professional growth, was not directly derived from these high level OKRs then middle management has failed in the assignment of work. The hilarious thing where I work is at the end of each week I have to manually enter the hours I worked and I have N charge numbers to split up those hours. If you read the line item for each charge number it's basically a synopsis of one or more OKRs. All this to say, from an engineer's point of view it seems with just a few tweaks in JIRA and Gitlab, review input could be created by running a report on commit history over the date range the review covers.

swanson 7y ago

> Objective – Increase Customer Retention > Key Result #1 – Lifetime Customer value increase from $N to $N+5 > Key Result #2 – Decrease Customer Churn Rate by 10% I'm a developer on a team. How am I supposed to know why customers are churning? I'm three levels removed from talking to customers when they cancel. I don't have a deep relationship to know how to add value to them. Someone needs to do the research, analysis, and leg work of finding potential areas to exploit. And then someone needs to have at least some amount of vision or inspiration about how to solve that problem. Or do whatever trendy new "design sprint feedback loop" brainstorming session someone is tweeting about. This is the kind of stuff I hear designers and "product people" talking about wanting to do. If you want to do that work and then loop in the engineering team to talk about feasibility and planning that seems fine, but the last time I worked in an environment with OKR no one seemed to have any brilliant ideas about how to, you know, actually achieve the Key Results. (Until these questions can be satisfactorily answered to developers, OKRs are going to be perceived as a buzzword, flavor of the month process air-dropped in because someone saw a blog post about it)

maxxxxx 7y ago
That’s a huge problem with the whole idea of providing value to the business. Some people can show real metrics but a lot of us are several layers away from anything quantifiable so either you have nothing to show or you have to make up some bullshit metric as I often see in resumes.
- avip 7y ago
  Slightly off, but the whole "business value" in IT resumes is proper a US thing. Cross the border and you're good with just mentioning what you did, sans the (often imaginary) "impact".
nlawalker 7y ago
Yeah, this wasn't at all what I thought it would be about, which is the difficulty (impossibility?) of measuring developer impact against key results. When you're a salesperson, you don't have to agonize over how to illustrate that you've "Decreased Customer Churn Rate by 10%". When you're an assembly line worker, you don't have to find a way to figure out how you contributed to "produce 15% more widgets". You either accomplish these things or you don't - they are literally descriptions of your performance in your job. Either way, nobody cares how you did (or didn't) do it. When you're a developer, how are you supposed to show that you've helped "increase customer value from $N to $N+5"? Because "shipped the new version of the message queuing system" is not in anyone's list of key results. OKRs feel like "organized SMART goals", and so I have the same criticism of them as I do of SMART goals: they're just another way of conceptualizing goals around things that are already easily and directly measured. No one has made any progress in quantifying the contributions of roles that don't have direct percentage impacts on dollars earned or dollars saved.

msoad 7y ago

Metric-obsessed management systems often miss on quality.

maxxxxx 7y ago
Or they invent a lot of bullshit metrics because in reality a lot of work is very hard to quantify.
- asark 7y ago
  The one place I worked that tried to do this, the developers mostly ended up doing things easy to measure. Turns out it's super-easy to measure views and shares so content marketing it is! Not exactly a good use of our particular abilities but it seemed to make everyone (who was pushing the OKRs) happy. Our real work could rarely be connected to any kind of OKR. Too hard to measure and, "this OKR thing seems cool, we should gather data for at least 2 years on X, Y, and Z for a baseline averaged across projects so we can create OKRs to improve them" didn't fly, obviously. So. Youtube videos and blog posts it was.
malyk 7y ago
If quality is important (it isn't always), then it should be one of the OKRs!

rocky1138 7y ago

This is interesting. I wonder how much of a depressing effect throwing away the backlog every time will have on contributions from people on the team who have good ideas but are not super vocal, e.g. "what's the point of saying my ideas when they'll just be thrown out next time we do planning?"

jedberg 7y ago
I think the hope is that management looks at the backlog and uses that to guide their OKR creation so that there is a meeting in the middle of the upper level OKRs and the backlog.

madrox 7y ago

Leadership is hard. Gaining alignment around goals is hard. Even if you state a goal, getting timely execution is really hard. OKRs are great in that they are specific and measurable, so you can have a concrete conversation on if performance is adequate. The problem with OKRs is goals can be hard to quantify, so it's attractive to simply make OKRs out of things you CAN measure. This is why we get companies that optimize for clicks at all costs, and twitter accounts that buy followers. If you're thinking about backlog bankruptcy, it's probably because your team is considered to be struggling. If so, it's attractive to think the process of delivering on the OKR is the problem. However, in my experience the real problem is that leadership hasn't done a great job of defining OKRs that properly align teams on the mission at hand. But good luck telling that to leadership.

loteck 7y ago
Completely agree, this post looks classically to me like a team toiling under leadership that picked OKRs as the measurement system for employees but not for leadership. How many OKR rollouts are plagued by lack of adoption in the C suites? Who here is shocked to find a system is malfunctioning because employees are trying their best to engage with it, but leadership can't or won't do their part? OKRs in particular are hugely reliant on leadership defining goals for others to align with. Measurements and progress are cultural. It either starts and continues from the top, or it's defective.

residentfoam 7y ago

OKRs could drive some value BUT in my experience they are hard to maintain and update. Most companies keep their OKRs in huge spreadsheets, some even have dedicated people to maintain that insanity. Teams then work with different tools, e.g: Marketing use Trello, Eng use Jira, you name it and now you have to trace back tasks from different tools to some OKRs defined somewhere in the cloud ... good luck with that. It's nearly impossible to measure and reconcile progress made on team/sprint basis with OKRs therefore you just shovel random numbers in the spreadsheet and management is happy. When an OKRs is updated good luck cascading the changes bottom <=> up . I have yet to find a company that has implemented OKRs in an effective way. Most of the time managers themselves tell you : "just write something .. it does not really matter" hahahah and there you go ... At the end of the day people have to do OKRs but they keep asking themselves ... why ?

tadasv 7y ago
Shameless plug, but check out my tool for managing OKRs outside of spreadsheets if this is something you're looking for https://simpleokr.com https://simpleokr.com
- phiggins 7y ago
  we've been looking at gtmhub.com for a minute, are you considering a Jira integration?
- fivre 7y ago
  Do you have a companion tool whose purpose is to convince Excel devotees that modern, domain-specific tooling exists, and that they should stop pushing Excel because it's terrible for many tasks? My problem is less that no tools exist to manage things outside of spreadsheets, but more that older management tends to take the position of "Jira (or whatever) is complicated and I already know Excel, and I'm in charge so we're using whatever doesn't require me to learn something new".
  - marcinzm 7y ago
    The problem with domain specific tools for project management is that everyone has slightly different goal, priorities and requirements. So you end up with a mess of a tool that barely works (Jira) or one that's missing necessary features. Then someone decides they could do it faster and better in Excel.

staticassertion 7y ago

OKRs just feel like waterfall with "metrics" slapped on to make it sound legitimate. The idea that I can predict what I should be working on for a full quarter, and know how to measure it in advance, is inane. Been working under this system for 1.5 years and I think it's nothing but a detriment. I did research into doing OKRs "right", watched videos, really tried to give it a fair shake, too.

dvirsky 7y ago
I look at them as a useful way to plan and estimate. It's okay if priorities shift or if you realise something will take longer, or that you actually need to work on something else right now and some KR will be pushed to next Q, etc. And it's perfectly fine not to meet some of your OKRs. I think of them as a compass rather than a paved road.
- staticassertion 7y ago
  If it's ok to shift priorities 3 weeks into OKRs and push them to the next quarter why was it important to have them at all? Do you now need to measure the new work that's prioritized? It's totally fine (and encouraged, in fact) to not pass every OKR, but I don't see any point to them. All of the failures of waterfall that everyone has always been aware of, but with the additional work of stating how you'll measure it, so that finance knows who to pay more.
  - dvirsky 7y ago
    As I said, look at them as a compass - a map will be a better analogy maybe - this is what I want to achieve at the point in time I'm making my plans, and here's how I'm going to achieve it. As long as that doesn't change, it's useful to break down a vague goal into milestones and evaluate on occasion (my team does it every 2 weeks) how you're progressing. But it's okay for that to change, and then you just write new OKRs.
  - groby_b 7y ago
    If you have no idea where you're going, and no metrics at all, how do you reasonably pick any tasks? So, clearly, you have some goal. It's likely also measurable. If you pick it so specific that you can't stick to it, yeah, OKRs are nonsensical. But "make money" or "increase conversion rate" or "find market fit" are clearly meaningful goals, no? The difference from waterfall is that OKRs don't prescribe a "how". They describe a desired outcome. Guardrails within which you can be as agile as you want, just get some results.

kradroy 7y ago

We started using OKRs this past year. I can't tell you what our current OKRs are. We even create "sub-OKRs" that align with the higher level OKRs. It feels like a pointless exercise, because we do what the author describes: slap labels on items in our backlog that sorta-kinda relate to an OKR. The author's suggestions aren't terribly complete or practical. I don't know many teams who could just dump their backlog every quarter. You're going to have work that can't be related to OKRs. We do use the OKRs to drive our weekly meetings and sprint planning. One suggestion I have is just to accept all work isn't OKR related and reserve capacity for that work. If some PM or manager complains, push back.

baxtr 7y ago
This is exactly what we do. We reserve about 25% of every team's capacity for "other" stuff, e.g. maintenance. The PMs/leaders have to acknowledge for that when they compile their OKRs.
- Terretta 7y ago
  This just means someone somewhere has an unstated objective that things be maintained. Make them write it down, and then your 25% capacity supports that.
  - baxtr 7y ago
    The O is clear. What’s the KR for you? (Driving a KPI from one number of another)

jph 7y ago

OKRs are excellent-- I manage a repo about OKRs where you can see examples and contribute ides. The article author is exactly right: use OKRs to drive your weekly team meetings. https://github.com/joelparkerhenderson/objectives_and_key_results https://github.com/joelparkerhenderson/objectives_and_key_re...

hrktb 7y ago
From the Google examples: > a team is encouraged to set as goals about 50% more tasks than they are likely to actually accomplish. > If a team scores significantly higher than that, they are encouraged to set more ambitious OKRs for the next quarter. I lived through this in Scrum sprints. There is a baked in incentive to sacrifice some iterations every once in a while to ajust the average expectation, while keeping an overall positive look. Otherwise without having used it seems to me that OKRs are another rather plain tool that works for clever organisations but fails when applied dumbly. Is there anything specific to it that makes worst case scenarii better ?

ltc5505 7y ago

Would it kill people to expand the acronym on first use? For example: "Most of the companies I’ve worked for in the last 5 years have used the objectives and keys results (OKR) system." I'm not sure why this common practice in text is seemingly disappearing on the web.

asark 7y ago
There's even a tag for it. Not that anyone cares about what HTML can do anymore.

alain94040 7y ago

If you're into OKRs, a friend of mine built a tool open to all: https://general-internet.zendesk.com/hc/en-us/articles/360013429514-Why-how-what-is-GI-OKR- https://general-internet.zendesk.com/hc/en-us/articles/36001... Interested in feedback.

deleted 7y ago

[deleted]

the-pigeon 7y ago

Making decisions based off an any metric is very dangerous and the downfall of many products. You MUST have a deep understanding of exactly what that metric is measuring and all of the things it doesn't take into a account. For a concrete simple example. An A/B test may sure that forcing users to create an account before seeing shipping charges increases order completion by 10%. But then it turns out you've reduced return visits to the site by 30% and decreased overall conversion rates due to damaging that funnel. Reality is very complex. Trying to boil everything down to a few numbers to make decisions based on seems like it simplifies things but often times you are just ignoring the complexities and flying blind by chasing metrics.

tmaly 7y ago

I saw the creator of OKRs, Andy Grove, speak years ago out at Intel in Oregon when I was doing an internship. I don't recall the product development group I was in using them. Maybe they were implemented at a much higher level in the company.

tzakrajs 7y ago

No mention of Key Performance Indicators? Why?

dboreham 7y ago
Everyone is too old to remember that this is what we called OKRs before? I forget what they were called before that..
Terretta 7y ago
MBO and KPIs are different systems stemming from different philosophies about how to frame objectives and how to measure what matters.

Apreche 7y ago

I write software that is used entirely internally by the company. We are building something completely new from scratch that is not yet live. OKRs were recently introduced at our company. The only OKR I can even think of is "get this thing functioning and in production". Just a boolean. I wanted to come up with something measurable, but what is there to measure? I don't understand how OKRs are appropriate for employees without the power to make business decisions. My only goals are to come into work, do what is expected of me, get paid, not get fired, and go home. I do not have power to decide anything with quantifiable results. If I did, writing OKRs and working towards them would be extremely easy. If I did have any power to make business decisions one of the first things I would do is make any employee without any power exempt from having to even think about stupid OKRs.

yitchelle 7y ago
Some ideas of what you can measure... Software is usually written to help reduce effort. Measure effort with and without the software. Reduce effort usually means better bottom line for the company which give you a great positive for your next performance review. Meaure the usual software engineering metrics, ie defect count, defect closed, velocity, delivery timing etc. I think that everything that we do in a company has a cost for the company. At the most basic level, you and I cost money as the company is paying us money for the work we do. You need to think from that perspective.
alexhutcheson 7y ago
Break it down into milestones. What's the minimum piece you could complete that would be usable by someone (even just a beta user to gather feedback)? What's the next incremental piece that would be useful after that? You can measure milestones completed, and you can also apply some type of scoring to the feedback you collect from your beta users. If your beta user feedback is "This is terrible, it doesn't do the key thing we need to do for our jobs!", that's actually a great outcome, because you can course-correct early, rather than having to revisit 1+ years of eng work to address the feedback. > My only goals are to come into work, do what is expected of me, get paid, not get fired, and go home. OKRs should just be the process of you writing down "what is expected of me" in a somewhat structured and measurable way. Team OKRs of "Hit milestones #1, #2, and #3 in development roadmap of system X" are fine, and are pretty common for greenfield projects. The main key is to have a "definition of done" for each milestone - does the milestone include documentation? Monitoring? Who decides that work is complete?

kenhwang 7y ago

My company has been using OKRs for several years now and the author perfectly describes what the engineering team does. We scan through our backlog, slap some nice OKR tags on items that are vaguely relevant, and then ignore the OKRs until the next quarter. The more politically savvy members of the team then spin some BS to make everyone buy that the work engineering is doing actually supports the OKRs. My personal opinions of OKRs are that it's possibly the most cumbersome form of waterfall without many of the few benefits of waterfall. It's really a tool for making leadership feel good about being bad at their job.

astral303 7y ago
I agree. OKRs are renamed MBOs. This is extrinsic motivation and a giant waste of time. At best, it’s a process-heavy priorities setting/strategizing mechanism. At worst, it causes unnecessary employee anxiety and distraction away from current business needs. Any measurement that is a metric (goals in OKRs) will cease being a metric. It will be gamed.
- Terretta 7y ago
  MBO and OKRs are not (supposed to be) the same methodology. Their proponents decades back were of opposing views on how to manage.

deleted 7y ago

[deleted]

jrochkind1 7y ago

> I think it gives leadership the justification they need to declare that everyone is working towards the same goals, but I don’t think it leads to dev teams actually feeling like that’s true. The more important thing is whether it's actually true, not whether dev teams (or leadership) feels it's true, no? But the OP indeed seems to describe an environment where it is not actually true either. Clearly, thought and planning is needed on how people work, in a way that will be directed to actually addressing OKR's. The OP offers suggestions about abandoning backlogs, and focusing weekly meetings on OKR's, which seem possibly beneficial, but probably not sufficient. I think it probably requires more fundamental shifts in how the whole organization works, which are a lot harder than just publisizing OKR's.

m0zg 7y ago

OKRs are merely a mechanism for generating public commitment to goals. You get to have a bit of a say what those goals are, but fundamentally they're about holding your feet to the fire after you spent a quarter bullshitting on Reddit because nobody in the organization has a foggiest clue about what needs to be done. Understand OKRs for what they are, and you'll be a much happier developer. Don't treat them too seriously, use them as a productivity mechanism _for yourself_. Now, even if nobody knows what needs to be done, you can refer to your (approved) OKRs and do _that_, whether it makes sense a month after the quarter started or not. I don't know how it is now, but at e.g. Microsoft in the 00's you'd set your goals once a year. A month later those goals were completely irrelevant to what actually needs to be done. And Microsoft is objectively one of the most successful software companies in the world. Waterfall, agile, OKRs or yearly goals, it doesn't matter. The reality is always dictated by circumstances. What matters is that every single thing I worked on while there makes money now, and a couple make billions a year.

codingdave 7y ago

I've only seen this in large companies, not startups or software shops, but it was never a single layer of OKRs. It was a set at each management level. The CEO would define the top-level OKRs. Their direct reports would ask themselves, "How can I contribute?", and build a more detail set of their organizations OKRs, that rolled up to support the CEOs. Every layer of management down the chain did the same. And the individual contributors set personal goals that supported their direct manager's OKRs. No system is perfect, and this one had its annoyances. But it did tie everything from personal goals all the way up to the top-level corporate goals, which resolves many of the concerns from the article.

loteck 7y ago
The trick here is: what happens if the CEO is unwilling to pin herself down to specific goals, for any reason, but especially because she has no goals or is afraid to be seen failing those goals? Either leadership doesnt engage with OKRs, tasks are deliberately misinterpreted as goals, or unmeasurable goals are set. The rest of the company's OKRs then follow this example, and everyone suffers.
- codingdave 7y ago
  In such a case, you have bigger problems than OKRs.
cortesoft 7y ago
This hasn't been the case in my experience at a 200,000 person company. The OKR's I hear about are so far separated from what my teams work on, that it is impossible to even pretend our work relates to it.

jofer 7y ago

So far, all companies I've seen that use OKRs operate something like this: Start of quarter - Management: We need to increase X. Dev: Okay, here's how I'll break that down... (key results) One month later - Management: Everything's changed... Y is the top priority now! Dev: Okay, that means we should focus on fozbuzzles. One month later - Management: Oh, man, what we really need to focus on is Z! Dev: Alright, we can do that if we de-emphasize X and Y. Let's get Z done! End of quarter - Management: You didn't meet any any of your OKRs other than Z! Dev: ...but you told me to drop X and Y... Honestly, I've never seen an OKR that was relevant by the end of a quarter... We finish them or not, but the objectives are always wildly different every few months and priorities change. Frankly, the start-of-quarter OKR system is incredibly disheartening... None of my major accomplishments or the primary focus of my work ever winds up being recorded, as only the items set at the first of the quarter are evaluated. I've worked at other places (outside of tech) where the emphasis was on recording what you worked on and why at the _end_ of the quarter. In my experience, it's smoother for everyone. I'm a bit surprised at the focus on quarterly, pre-set OKRs in tech... It seems like a more adaptive process would be better for everyone.

superfrank 7y ago
> Honestly, I've never seen an OKR that was relevant by the end of a quarter... We finish them or not, but the objectives are always wildly different every few months and priorities change. I think there are two types of priorities, "fires" and "nice to haves". Fires are high priority, unpredictable, and often need to be solved quickly. This is things like "our databases crash every morning" or "our AWS bill is too high and going to put us out of business". Nice to haves can still be needed, but they tend to take a back seat when a fire happens. Additionally, their priority tends to be much more subjective. This is things like "Our build process takes too long" or "our deploy process has too many manual step which leads to human error". OKRs tend not to last a full quarter because any tasks/priorities that you can schedule and make fit nicely into a 3 month period are "nice to have"s. I'm not saying they don't matter, but the timeline to get them done doesn't really matter so things get delayed or moved around. On the flip side, you can't schedule fires and you usually can't delay them either. The things that actually important enough that they can't get delayed tend not to fit the OKR framework.

maxxxxx 7y ago

Seems this tends to go exactly the way Scrum and Agile did. If done correctly by the whole company it works well. But in most cases it will probably be a mandate by top management and the rest has to come up with some nonsense metrics and objectives and just play a game. I think more and more any methodology will work if followed honestly and adapted to real world problems. In the end it's always the disconnect between what an organization claims to do vs what it really does. If that disconnect is small things are good, but in a lot of cases the disconnect is big.

Justsignedup 7y ago

As an engineer OKRs are a bit of a conflicting thing, and here's the reasons... - I don't decide what projects come my way. Product or management decides that. - My concerns are: "Is the company going to be around for > 6 months?" because if the answer is yes than my concerns are "In 6 months, make sure we don't hit a wall that will be a stop all development situation". I've seen it. - OKRs are always going to be goals of the company. My question will always be: What can eng do to actually affect these OKRs? Are customers leaving due to bugs? Eng will prioritize bugs. Are customers leaving due to lack of features? Eng will build features. Is the company about to run out of money? Eng needs to build as much and as fast as possible and ignore any long-term problems because we need to get customers. Basically either department heads need to take the current OKRs and transform them into department specific OKRs or they become meaningless. There needs to be engineering OKRs around things that engineering can affect. Not product OKRs which product will affect. Not sales OKRs which sales affects. Example of a product OKR: - increase customer conversion rates by 0.5% every 2 weeks for the next 2 months. Example of an engineering OKR: - enable product to A/B test - enable product to measure more data points to make decisions to reach their OKRs

blazespin 7y ago

OKR at an individual level work fine, but they need to be positioned as an individual OKR. For example, reduce bug count report by 10%. Or, increase LOC by 10% without reducing quality (defined as bugs, DRY, PR comments), increase documentation written by 10%, increase Slack karma by 10%, etc Obviously other metrics other than the OKR need to be maintained. PRoduct owner is responsible for OKRs that scope across stories implemented, not ICs. Or at least not junior ICs. Architect level IC for example should be able to complete more broad scope.

vinay_ys 7y ago

OKRs do force you to put down your company's priorities and metrics to measure their success. Unable to do that usually is a symptom of being too tactical and reactive and not having a strong strategy/vision. Company-level OKRs are only as good as your leadership team's clarity on strategy and long-term direction and conviction to largely stay the course for at least 3 month chunks. If you feel your company OKRs are bad or you are unable to connect with it, it is because your leadership team has not done the necessary homework to define and socialize it well. If you agree your company OKRs make sense but you are unable to connect it to your work, think of it this way: For a functional feature engineer, the team OKRs should clearly and directly connect the features they are working on to the company OKRs. If not, then you need to engage with your product managers to achieve that clarity. For a senior platform engineer responsible for evolution of tech platforms, it is critical to have a good sense of the direction in which business will evolve and expand. (Annual OKRs and strategy articulations are crucial for this). From this, you should be able to draw out a mind map of the kinds of features and capabilities needed by your platform. Then you can articulate this to your team to build those required enhancements to the platform while also ensuring immediate feature building activity is moving as productively as possible. If you are unable to connect the dots between the business OKRs and tech platform OKRs, it is usually a sign that there isn't a good functional model for your business domain and your tech platform isn't really a platform that supports that functional model. For architects, this should be the most important deep work – to keep the functional model of the business and that of tech platforms in sync. Without this common model, teams cannot collaborate effectively.

dijksterhuis 7y ago

OKRs seem like a fancy new version of KPIs. My single biggest issue with KPIs is that, for the most part, in a large company, one (or even several) metric(s) cannot cover the whole story. They are useful for very specific targets. I’ve ended up working towards KPIs which I’ve known have zero relevance to improving service because they are (a) poorly defined (b) irrelevant to the actual problem (c ) force a metric to exist where no sensible metric can. Unfortunately this tended to happen more often than not. OKRs have their place. But they don’t sound like something new (KPI rehash) and are wide open to misuse, just like KPIs.

hj7n 7y ago
Hi Dijksterhuis, Some organizations do indeed move from KPIs to OKRs. I personally think they are different tools for different purposes, and they could work well together. I believe KPIs are a great tool to define and monitor your business as usual, whereas OKRs is more about realizing your ambitions and pushing the company further ahead. If it helps, more info here: https://www.perdoo.com/blog/kpis-okrs-the-goals-that-drive-business-success/ https://www.perdoo.com/blog/kpis-okrs-the-goals-that-drive-b... Best, HJ

bezoisevil 7y ago

OKRs are so dumb

ibeckermayer 7y ago

Is there no limit to the bullshit dopey “management consultants” will come up with an acronym for? “OKR’s”? Oh, do you mean creating some objective and then working towards it as a team? Measuring progress through some empirical metric? You know, the same process humans have engaged in since the dawn of our species? What a load of garbage.

apinstein 7y ago

In our use of OKR, we was concerned about this as well. Having to use mental gymnastics to make things work is a bad sign. The way we thought about it was that OKR should not dictate 100% of effort. OKR is about prioritizing the changes that leadership wants to make at the productivity frontier of the organization. OKRs alone are not enough to direct company efforts. Leadership also needs to specify what % of energy should be spent on OKR vs other responsibilities. The OKR effort goal could be between 0-100 for different teams, or the company as a whole. For instance, a company that needs to pivot or will die is probably close to 100% OKR effort on all teams. This approach gets around the need to assign OKR to every activity and allows OKR to be more salient and less diluted as a tool for alignment and goal setting.

LittlePeter 7y ago

> Where OKRs become less useful is within the decision making process for an individual team. > Joe Cannatti Anyone else put off by the author quoting himself?

simplecomplex 7y ago

I’m so sick of the software industry expecting developers to do the work of the entrepreneurs for them without any of the upside. Why the fuck should I help the owner get rich by identifying how to grow their business by increasing conversion, retention, etc.? I don’t benefit at all. At my current company we have weekly meetings where the owners tell us all the business metrics we should be driving and ask for ideas on how to increase them. I’ve learned to say “I don’t have any specific ideas right now.” because it’s insulting they expect me to do their work and get nothing for it.