[HN Gopher] Thoughts on OKRs
___________________________________________________________________
Thoughts on OKRs
Author : joeblubaugh
Score : 230 points
Date : 2022-05-18 13:47 UTC (9 hours ago)
(HTM) web link (joeblu.com)
(TXT) w3m dump (joeblu.com)
| beebmam wrote:
| Never seen OKRs be anything but a disaster. Probably never will
| see anything else.
| msoad wrote:
| Whenever I see a website making the SIGN UP button bold and big
| but SIGN IN small and faded I am reminded how toxic OKRs are and
| how it end up hurting the user and eventually the business.
|
| Making people mistakingly create new accounts indeed helps you
| hit your # of sign ups goal but at what cost?
| ad404b8a372f2b9 wrote:
| Objectives and key results (OKRs). It's baffling that software
| engineers don't understand they have to define a variable before
| using it.
| bezospen15 wrote:
| OKRs are a joke made up by MBA product focused types to try and
| remain relevant
| 21723 wrote:
| _I want to compare OKRs to Performance Reviews and Roadmapping.
| They're all worthwhile ideas that can bring discipline and
| structure to the chaotic world of business, all dreaded by their
| participants for some reason._
|
| It's not mysterious, why those things are hated.
|
| In business, there are innate conflicts of interest. The company
| wants to suck as much out of people, and pay as little, as it
| can. You want... something else. Not to be exploited. To have a
| career. To make more money. Doesn't matter. The company is a
| paperclip maximizer and you are made of atoms it can use for
| something else. When you write OKRs, you have to generate
| information that will only be used against you--never for you.
| You have to pretend that you're doing this out of some sense of
| mutuality when, in fact, the situation is inherently adversarial.
|
| You might have a decent manager. Great. That happens sometimes.
| However, all these devices exist as ways for companies to make
| managers unable to protect their own people. That's why "Agile"
| time-tracking exists. That's why there are two management
| structures (product and people management) for reptilian
| executives to pit against each other. That's why performance
| reviews with failure quotas exist. For your boss to be able to
| protect you from the company is the last thing the company wants.
| neogodless wrote:
| Uh, please see https://news.ycombinator.com/item?id=31420938
| (Stop using grey text). Especially on a grey background. My eyes
| don't have enough life in them to try to read this.
|
| (Yes this is off topic and about formatting and it's boring.)
| commandlinefan wrote:
| Ironically, you're being downvoted and right now your text is
| grey.
| [deleted]
| joeblubaugh wrote:
| Yeah, maybe I should reconfigure the default theme to light
| mode and try to add the CSS prefers-color-scheme media query.
|
| For now, if you want, you can click the circle in the upper
| right to toggle to light mode.
|
| Thanks for the feedback!
| tomrod wrote:
| I second your discomfiture at gray text.
| deepsun wrote:
| Firefox has "Reading mode" button right in URL box. Both on
| desktop and mobile. Enjoy!
| neogodless wrote:
| Thought of that after posting and closing the tab. But I
| don't feel like going back. It makes me angry that people
| think making text as hard to read as possible is good design.
| But it's just my opinion, and it's OK for people to have
| differing opinions. I just choose not to spend my time and
| eyeballs on their content.
| cyberlurker wrote:
| Am I the only one that saw "jibe" at the end of the article,
| thought it was incorrect, looked it up, and discovered I have
| been using "jive" incorrectly instead for years?
| timcavel wrote:
| fh973 wrote:
| OKRs are also a tool for communicating priorities and agendas in
| all directions of the hierarchy.
|
| I think they work reasonably well for that. They're succinct and
| the key results force them to be grounded on some reality that
| people can relate to.
| whywhywhywhy wrote:
| "We're introducing OKRs, they're for your benefit so you know
| where to focus and can track how you're improving and the team
| success, they wont be used to judge your salary"
|
| 6 months later
|
| "So yeah that's the most we're gonna offer you for this raise
| because your OKR score was only..."
|
| Every time.
| quickthrower2 wrote:
| Yeah. Objective: Pay rise. Key Result: Pay. Strategy; Apply.
| djur wrote:
| My experiences have tended more toward "everybody stresses out
| about OKRs for a couple weeks every quarter and then you might
| as well have deleted the file because nobody will ever, ever,
| ever talk about them again".
| cletus wrote:
| I used OKRs on several teams to varying degrees at Google. Not a
| fan. Here are my complaints:
|
| 1. It makes organizations slow and inflexible. I used to joke
| that as soon as another team was involved in something you needed
| to do it would probably take a quarter. why? Well what you wanted
| probably wasn't on this quarter's OKRs so it would be an uphill
| battle to get them to do it. You'd have to argue about getting it
| into next quarter's OKRs;
|
| 2. OKRs can be structured in such a way that you can grade quite
| well while having achieved absolutely nothing;
|
| 3. Teams can be held to different standards. Some get easy OKRs.
| Some get harder OKRs. So it's still subject to the political-
| perception problems inherent in such organizations;
|
| 5. It is largely for show for upper management. I've been in 2
| hour planning meetings where a bunch of teams speak for 2 minutes
| about what they're working on. This might be useful for
| directors+ but is really a waste of the time of 50-100 other
| people. This is a problem with status meetings too;
|
| 6. Even grading OKRs can be subjective and political. I recall
| one famous example where someone ( _cough_ Vic _cough_ ) said
| they had a goal of 100M users. They actually only got to 10M.
| Grade? 0.7.
|
| There was a running meme at Google about feedback that went
| something like this: This project would've failed without this
| person. It failed anyway but it definitely would've without this
| person.
|
| I like this meme because it illustrates how the same set of facts
| can be used to argue how someone did a good job or a bad job and
| the difference between the two is whether or not the org likes
| them. The same set of facts can be summarized as "this probject
| failed to ship" and "we failed fast, learned a lot and will take
| those learnings into future projects".
|
| OKRs suffer from exactly those same problems.
| commandlinefan wrote:
| > what you wanted probably wasn't on this quarter's OKRs so it
| would be an uphill battle to get them to do it
|
| Everywhere I've ever worked - OKRs or DPMs or Goals or whatever
| you want to call them or not - I've had a set of work that's
| assigned to me via JIRA tickets or Bugzilla tickets or some
| kind of ticket tracking system, and I've also had a constant
| deluge of co-workers asking for my help with something or
| other. The longer I work there, the greater the deluge of both
| requests for help and volume of work assigned. Every day I've
| ever come into work in my life (besides the one-two month
| "honeymoon period" when I start a new job), I have to decide
| between ignoring my coworkers pleas for help or slipping the
| deadlines on the individual tasks assigned to me.
|
| Over the course of the past three decades, I've tried both ways
| - first, focusing on my assigned tasks and second, dropping
| everything every time I get a request for help. I've found
| that, overall, the second way works best. I have to constantly
| apologize for constantly missing deadlines, but if I keep
| turning away coworkers, not being enough of a "team player"
| shows up as a nastier mark in my performance reviews than
| always being behind on tasks.
| theptip wrote:
| For sure #1 is a big problem. But are OKRs causing this, or are
| the big companies that are using OKRs just fundamentally slow
| and inflexible? (In other words, are OKRs a symptom rather than
| a cause?) Thinking about how to coordinate 100k engineers, the
| trade-offs are pretty brutal. Startup-style "move fast, break
| stuff" simply doesn't scale well.
|
| I'd like to see some case studies here. Anyone got examples
| they like? I hear patio11 talking about Stripe a lot, and he
| says stuff like "could we deliver something faster?" which I
| think gets at an urgency for results, interested how they
| coordinate the layers and orgs.
|
| I think it's plausible that OKRs forestall agility and
| innovation as-used. But (at risk of invoking the "no true
| Scotsman" argument), maybe these companies are just doing OKRs
| wrong? OKRs are supposed to be abstract enough that you can
| change your plan if something better comes along. So if your KR
| is tightly coupled to a particular implementation then you
| can't pivot in the face of new information. A quarter is a long
| planning horizon for small/medium sized companies! But if your
| KR is loosely-coupled, then it leaves room for new approaches.
| This balance is hard! The maximally-loose O/KR for many
| companies is just "succeed/increase share price by X% QoQ".
| This doesn't give you any direction.
|
| I think at their best OKRs provide bi-directional information
| flow; both giving a way to make output from the lower levels
| more legible to the upper levels, while also making the
| objectives, desires, priorities of the upper levels more
| legible to the lower levels. I think any replacement has to
| achieve both of these things too.
| dougdonohoe wrote:
| > 1. It makes organizations slow and inflexible. I used to joke
| that as soon as another team was involved in something you
| needed to do it would probably take a quarter. why? Well what
| you wanted probably wasn't on this quarter's OKRs so it would
| be an uphill battle to get them to do it. You'd have to argue
| about getting it into next quarter's OKRs;
|
| This. It's not a joke either. At a previous job, we wanted to
| use the G Suite API to access calendar data from GCP, but that
| required help from the Info Sec and Cloud teams (we didn't have
| the right permissions to do it ourselves). We got push back for
| asking for help because it wasn't in those teams' OKRs. So we
| effectively gave up for an entire quarter and then some.
|
| Even so, how does one write an OKR for a scenario like this?
| Objective: be able to access GSuite API from tool Foobar so it
| knows about everyone's availability. Key result: Umm, can
| complete a feature everyone wants?
| theptip wrote:
| Putting this in a separate reply as it's a separate train of
| thought.
|
| > Even so, how does one write an OKR for a scenario like
| this? Objective: be able to access GSuite API from tool
| Foobar so it knows about everyone's availability. Key result:
| Umm, can complete a feature everyone wants?
|
| The key thing about an objective is that it is a high-level
| goal. You've written the implementation into the O, which is
| a bit of an anti-pattern.
|
| It's a bit hard to extrapolate exactly what the context was
| for your feature, but let's say your team owns an internal
| tool that orchestrates a business ops system that manages a
| task queue for "agents"; say "review these potential fraud
| cases that the system flagged".
|
| As this is an existing system that you're trying to improve,
| not a new product, your team's objective for the Q might be
| attacking the main stakeholder-facing pain point with
| "Improve response time for manual review tasks". A KR that
| measures this might be "P50 latency for handling fraud
| reviews is reduced from 5d to 1d". (This formulation gives
| you a progress bar -- "0% complete" is >=5d, "100% complete"
| is <= 1d. You can easily build a dashboard for this, which is
| the holy grail for KRs.)
|
| Now, based on the observation that most of your significant
| delays for this process are due to tasks being scheduled on
| agents that are on vacation, an initiative that you propose
| to progress the KR is to add calendar-awareness to your
| service's scheduling process. But, there are a bunch of
| possible initiatives that could move the needle here, and so
| as a team you get together and figure out which are going to
| have the best bang-for-buck.
|
| Formulating the OKRs like this gives the team freedom to
| figure out exactly how they are going to solve the problem,
| while also communicating to the rest of the org what you're
| working on (and giving the org a chance to say "isn't <other
| objective> way more important?". And turning the
| implementation into a precise KR gives you the opportunity to
| discuss with stakeholders whether P50 is really the metric
| they care about, or if the business would be better served
| with P99 or some other way of measuring things. These metric
| discussions can be annoying, but at their best they can
| uncover subtle differences in expectations.
|
| Note -- this is quite process-heavy; you wouldn't go into
| this much detail with a two-pizza-team startup! But if your
| team is dedicated to this internal tool in a company of tens
| of teams, then this level of detail might make sense for you.
| djur wrote:
| What's worse is when that team gets around to it next
| quarter, and then in their research process they realize
| another team needs to be involved, etc. Eventually you have a
| two-week project that doesn't get delivered for a year.
| theptip wrote:
| But this does reveal an organizational problem right; either
| the security teams have it right and their current work is
| more important, in which case maybe they are under-staffed
| and need more slack. Or maybe they failed to add a KR for
| "perform timely security review" if that is a service that
| they provide to the org. If you're blocked, you should be
| able to raise this up and learn something as an org.
|
| Or maybe the KRs are correct as written, but the security
| teams have it wrong and their KRs should be deprioritized
| only favor of delivering yours. When KRs clash you need to
| have a conversation and resolve the conflict in the way that
| maximizes value for the business.
|
| Ultimately prioritization of work always involves trade-offs,
| and there needs to be some mechanism for handling these. No
| system can handle 100% of cases without adding human
| judgement.
|
| To me it seems the pathology in your example is that everyone
| was just sticking to the KRs, instead of coming to the best
| business outcome (and if your request was not prioritized,
| you should be able to understand the reasoning used to decide
| that). I can see how OKRs could be used as a shield to hide
| from those difficult conversations, but it's not clear to me
| that they necessarily make things worse; if you didn't have
| OKRs maybe your teams would be finding other ways to avoid
| working on things that they don't want to help with.
| higeorge13 wrote:
| #1 is a real issue, but is actually a problem of management and
| company as a whole. Teams want to be silo-ed and not bothered
| by anyone else hence set their goals and just do them,
| engineering managers just care about their teams or don't even
| communicate between them to check for cross team projects, and
| upper management never sets some actual objectives and roadmap
| which could have been mapped into cross team projects and
| goals. And goals become a religious quarter to quarter thing
| without allowing any deviation, and then everything is slow.
| kiloreven wrote:
| My current employer use OKRs to align the different levels of the
| org and to help each team structure their work. We use an
| approach that is mostly owned on the lowest level; company
| leadership set long and medium term objectives for the company,
| area/department heads set goals for each 4-month period, and each
| team gets to work out their own OKRs for the next period. The
| team objectives do not not need to match area objectives 1-to-1;
| area objectives are mostly guiding.
|
| I started rather recently, and I'm in my second OKR-period
| currently. This has been my first experience with OKR, and so far
| it's been on the strong side of positive; we get some guiding
| principles to work towards (but nothing too concrete or checkbox-
| final) and it works well. Sure, we won't be able to solve
| everything we write down, but our team is aligned on our own
| direction and a course that we control ourselves , to a large
| degree, but still within the overall goals of the company.
|
| In my experience, software engineering is about 20% creating the
| solution, 15% tuning and debugging the solution and 65%
| understanding the problem.
|
| Within this perspective, the work of talking through the problems
| that your team is working to solve, and contextualizing why
| you're solving them, is highly valuable and counts towards
| understanding the problem. The process of defining OKRs, within
| the correct frame of reference and expectations, can work very
| well for this.
|
| IMO, using the backlog to define upcoming work can enrich this
| process as well; it brings context, but should not becone the
| final OKR "product" alone.
|
| I've only ever encountered OKRs on a team level, but I cannot
| grasp the value they bring as individual goals. The real value in
| OKRs lies in the process leading up to defining them, not the
| objectives and results themselves.
|
| A recurring theme in the horror stories I've read regarding
| corporate strategies is that they tend to be implemented with a
| goal of rigidity rather than fluidity. And making rigid processes
| that aren't compatible with team autonomy brings with
| helplessness and alienation between the goal-setters and those
| working to deliver.
| lostdog wrote:
| > The real value in OKRs lies in the process leading up to
| defining them, not the objectives and results themselves.
|
| I couldn't agree more, and the article is headed in completely
| the wrong direction.
|
| Companies fail at using OKRs when they are rigid about treating
| OKRs as a measure of successfulness of the team. In my
| experience, the true goals almost always become clearer as the
| quarter progresses, and hitting the OKR objectives you set
| months ago is a sign that your team is not flexible enough to
| solve the real problems. Oversimplifying your work into key
| results also hides the true status. It overemphasizes
| measurable, but meaningless, metrics over truly checking the
| work for quality.
| chopete3 wrote:
| /s
|
| The best thing about OKRs
|
| People: It helps companies dump as many people/contractors as it
| can afford into a pod. Result: It supports this[0] kind of
| development process
|
| That said, there will always be one or two genuine workaholics in
| every pod who write enough code to show something tangible. That
| helps keep the OKR/Agile business go on forever.
|
| 0: https://imgur.com/a/IeKjsff
| motohagiography wrote:
| While I think OKRs are necessary, and strategic leadership is
| necessary to achieve them, consider that whether a company is
| being led to an objective, or managed to optimize itself - is
| entirely dependent on the stage of the company. I'd argue
| optimization phase OKRs are negatively defined, where growth
| phase OKRs are positively definied.
|
| Stages I think of as survival/subsistance, product market fit,
| and max market share, are growth phases, whereas stages like max
| stock price and max gross margins, are optimization phases of a
| company. Optimization phases are when you already have market fit
| and a revenue stream, where as a board you can just drop in a
| bunch of MBAs to refine and hollow out the org and stabilize the
| company as a revenue stream in a portfolio. Management is value
| extraction, and it is a specific skillset that a company needs
| when it has a revenue producing asset, which it needs to optimize
| for stability, so that it can be used as collateral for
| _leverage_ into new ventures. That 's the point of management: to
| stabilize an asset with steady hands so that it is a coherent
| asset that can be traded and leveraged.
|
| Leadership qualities in managers are mainly plumage on (or cover
| for) their foundation of extractive skills, and are neither
| sufficient or necessary. You can't manage something until there
| is a null hypothesis, where the thing makes value or money
| already (default-alive in PG parlence). This is why managers
| creating OKRs often sound so vague, it's because they rig the OKR
| definition to avoid a perception of failure that would cause
| their attrition in a zero-sum optimization environment. OKRs are
| necessarily about black-and-white outcomes, whereas, managing is
| a matter of sustaining and directing an equllibrium. (yes, b&w
| thinking is usually considered "bad," but mainly from a mangerial
| frame of reference). I'm proposing OKRs are a growth/leadership
| phase tool that feels cargo culty in optimization/management
| phase companies.
|
| Smart people become managers because they can reason abstractly
| about stuff that makers, leaders, and IC's take personally, and
| there is a lot of value in learning to respect that skill, even
| when it is repellant, and not fall into the trap of merely
| moralizing our own limitations. (my bias should be obvious)
|
| Leadership is for the growth phases of a company, where you need
| to get from zero to one, a to b, subsistance to product market
| fit - where the function of leadership is to affect change. A
| company whose majority growth phase is behind it is in a stable
| state doesn't need change, it needs to be managed and optimized
| as an asset for leverage. It's dumb to drop leaders into stable
| companies because the inertia of the company is already headed
| toward an equillibrium of being a commodity asset, a piece of
| financial furniture in portfolios, and change agents (leaders)
| either have to derail that to succeed, or get frustrated and
| leave.
|
| For a FAANG company to have OKRs below the manager level now
| seems misguided, as their growth phases are behind them, e.g. the
| majority of the change in their revenue growth is going to come
| from cost management and margins, and not from growing into new
| market share. Their best hope for market share growth is
| demographic change, as if you haven't adopted their product by
| now, you're probably not going to unless you were born recently
| and are just discovering the product, or you have just arrived
| and the products are part of your new life. Otherwise, I'm
| probably not going to become a new user/market share of a FAANG
| product.
|
| As an optimization phase company you can't tell your engineering
| staff that the future is lean and that the company is now a zero-
| sum optimization problem, which their job is to beat out everyone
| else at doing the same or more with less. That's a great and
| strategic place to make a P&L mark as a manager, but a shitty
| place to be someone who builds and makes things. Your upside
| comes from outsourcing functions and services, integrating with
| tech debt, and other brain damaging tasks. An OKR in an
| optimization stage company is whether a function can survive
| being operated by cheap and the absolute minimally competent
| people. It's mainly about cost reduction. Imo, OKRs in an
| optimization stage company are like skinny jeans on a middle aged
| man, where nobody wants to have to be the one to say it, but
| they're past the stage where it's appropriate.
|
| OKRs make more sense in a startup or a growth stage company where
| there is a sense of shared mission and clear outward direction
| for growth, and where you're betting on growing your way out of a
| lot of problems. Deliver a feature that positions us for this
| market share growth, make something someone wants, establish PMF,
| establish feature parity w/ competitors, improve conversions in
| the pipeline by x% - these are the things that leadership is
| designed to achieve. It's high risk and leadership has terrible
| failure modes, but that's an artifact of the company stage.
|
| Long comment with intent to provoke discussion, but if your OKR
| is not concrete and a b&w binary outcome, I'd ask whether you are
| in an org that is still in a growth phase, and whether this is
| what you want. Nothing wrong with being in an optimization phase
| company (e.g a bank) but not being aligned personally to the
| phase of your company is a recipe for suffering.
| dbrueck wrote:
| OKRs just seem like another attempt in a long line of failed
| attempts to make development costs more predictable. I applaud
| the effort, but at any company I've worked, they've always turned
| into a stick used to beat on the underlings. I think I get how
| they could work in an ideal scenario, but the implementation of
| them has always failed, because the adopted process doesn't allow
| them to shift even as things arise outside your control, because
| they got tied to raises/bonuses in unfair ways, etc.
|
| My only "successful" encounter with OKRs was at a company that
| really bought into them hard, and so over the course of about
| half a year I got the teams in my group to slowly get ahead of
| the curve, such that 90+% of every next-quarter OKR items were
| things we were done with already, so that we could spend pretty
| much the whole quarter dealing with fires or secretly getting new
| stuff done for the next-next quarter.
| zippergz wrote:
| I don't disagree with any of this, but really these are problems
| with every goal-setting framework I have experienced in my
| career. Similar to performance review frameworks. It isn't the
| framework that sucks; it is the exercise itself. I've become
| convinced that at a certain scale, it is impossible for a
| corporation to have a company-wide goal process or performance
| review process that adds more value than it detracts. I don't
| know what the solution is, but I really don't think it's just
| "find a better process."
| commandlinefan wrote:
| > I don't know what the solution is
|
| I do, but they're not going to like it, so they're not going to
| do it. The mindset behind these goal-setting frameworks is
| "everybody is stealing from me and I have to watch them like a
| mafia boss to catch the cheaters". The solution is to actually
| treat the team as a team and work together, but the type of
| people who rise to a management role in any organization (
| _especially_ a corporation) aren 't the type of people who are
| capable of doing so.
| st3v3ndungan wrote:
| OKR's without strategy or context (or OKR's substituting for a
| strategy or context) is a killer I've seen. Especially if I'm
| "laddering up" my product's OKRs.
|
| This is where the bi-directional approach does work better than
| strictly top-down or bottom-up; my leadership probably doesn't
| see the opportunities or constraints for my product, but for my
| opportunities to be attainable, I need to be swimming the same
| direction as my organization. Strategy gives me context for where
| I should be playing.
| nkrisc wrote:
| I've been through several jobs that used OKRs, and even had to
| read a book on it at one point, and to be completely honest I
| still have no idea what they are. Maybe I'm just dumb or can't
| grasp it, but while I know what all the words mean, I still don't
| understand what it is or why it's useful. I'd write some "OKRs"
| based on what my boss told me to write, who was told be their
| boss, and then I'd enter them into some HR system and never saw
| or heard from them again. It was all very cargo cult-y.
|
| I never really understood how an OKR is at all applicable to an
| individual. Maybe our OKRs were bad but they were always related
| to increasing some metric or measure. I can't personally,
| directly affect any of that. I can do my damnedest to do good
| work that I think will help with that, but ultimately I have no
| control over whether our conversion rate goes down because some
| other department did something that hurt it. Yeah we did a great
| job on some landing page but then marketing pushed the wrong
| audience to it so it tanks. How does an OKR help with that? Now
| it looks like I haven't met any of my goals?
|
| Maybe the problem was we always had these executive-level, vague
| "objectives" set by the C-suite, but then nobody knew what to
| actually do with that. Object: be an industry leader in
| innovation. What does that even _mean_?
| djur wrote:
| > then I'd enter them into some HR system and never saw or
| heard from them again
|
| My favorite version of this is when it's personal goals
| attached to some kind of performance review framework, but the
| company keeps on changing its performance review system every 6
| months so you literally never can see them again.
| BlargMcLarg wrote:
| It's another corporate flavor of the "month" trying to solve a
| realistic problem developed by corporates themselves, in
| Corporatese.
|
| In theory the idea of OKRs is fine. They are "supposed" to give
| individuals a form of autonomous growth which can be related to
| the company and has a way to be measured and traced back. It
| gives them the "personal responsibility", "growth" and
| "autonomy" which tickles a particular type of people.
|
| In practice, there are too many conflicting viewpoints,
| agendas, power hierarchies, goals and more, to make them work
| out. That's assuming everyone works in good faith with one
| another, too. As others point out, nothing's keeping a manager
| from using OKRs against you.
|
| Stay tuned when in 10-20 years it will silently die off to be
| replaced by another flavor, and reinvent the square wheel once
| more.
| nairteashop wrote:
| I think of "OKRs" as just a fancy name for two things: (1) What
| are you going to do in the next quarter/year/etc? i.e. what are
| you & your team's "objectives" (2) How are you going to achieve
| that? i.e. what are the "key results" you're going to hit to
| achieve your objective.
|
| I hope most people will agree that, in an organization, having
| an understanding - and agreement - of what each team plans to
| work on, along with the trust that they have reasonably well-
| thought steps on how to achieve that objective, is incredibly
| helpful.
|
| The problem is, as with "Agile", "TDD", etc, people will run
| with this and lose track of what the actual end-goal is, i.e.
| to build things that matter while ensuring coordination between
| teams. So, you will see things that don't make much sense, like
| OKRs for individual contributors, OKRs that change monthly,
| objectives that aren't necessarily right for the company, key
| results that don't really tie into the objective, etc.
|
| I'm not sure what the solution is. At a previous gig, I tried
| asking management plainly to state publicly what they're going
| to do and how they're going to do it, and no one did it. Then I
| tried, let's do OKRs "just like Google" and everyone jumped on,
| even though IMO it's the same thing...
| crispyambulance wrote:
| They're meaningless. I don't understand how these things can
| continue to exist and evolve in ever more ridiculous
| incarnations of the same stuff. If, next year, they all
| disappeared and managers just "cut the pie" for their own sub-
| org-- nothing bad would happen and the vast majority of folks
| would see it as a relief.
|
| The weird thing is that _almost_ everyone, even high up in the
| organization, thinks these performance eval mechanisms are a
| baloney waste of time. But somewhere, at some level, somebody
| is really pushing hard for these and values them.
|
| Is it a suit thing? At what point in one's career does someone
| all of sudden decide "yeah, having everyone write paragraphs of
| BS justifying their work performance is a good use of time and
| THAT will REALLY solve problems"?
| marcosdumay wrote:
| > At what point in one's career does someone all of sudden
| decide "yeah, having everyone write paragraphs of BS
| justifying their work performance is a good use of time and
| THAT will REALLY solve problems"?
|
| When somebody starts making a lot of noise that people should
| do it, the people under you seem to unanimously support it,
| and the people above you seem to unanimously support it. That
| is, except for the very few that you can get a honest answer
| from, those are the only few that think it's bullshit, but
| put-up with it because everybody else is pushing it.
|
| A better question is how the hell somebody getting money to
| teach your people and organize the process get enough
| credibility that they can mess with all the communication
| channels. Maybe an even better question is if there is any
| way to make people feel safer at work than in a crazy
| absolutist king's court, so that they have less need to lie.
| lovich wrote:
| Our corporate environments and capitalist structure in the US
| consolidate power in people. Once you start being an exec who
| can fire individuals on a whim or hand out raises/promotions
| they end up getting surrounded by yes men and then you start
| seeing the crazy ideas start flowing down.
|
| The worse corporate jobs I've had have been the privately
| held large firms as the places are big enough you never know
| the executive but you still end up spending days/weeks doing
| ice breakers and personality assessments because the CEO's
| life guru convinced him it would align the astrological feng
| shui.
|
| It doesn't do anything for the company but waste time and
| money, but until it wastes enough to cause the leaders to
| lose all power it'll continue flowing down to us peons
| tonioab wrote:
| 80% of the value of OKRs is in the discussions they create, not
| in the actual list of OKRs that is produced in the process. The
| more an organization focuses on the technical aspects of
| producing a perfect OKR list or on "grading" the OKRs, the less
| value they will have.
|
| In particular, the "KR" part - quantifiable outcomes for the
| goals - usually helps in clarifying vague projects or ideas that
| may otherwise harm the team's focus.
|
| It's similar to the famous Warren Buffett's advice on identifying
| your priorities: pick 20 ideas you have and identify the top 5
| goals that you absolutely want to get done; then, throw away the
| other 15 goals and make sure that you never get tempted to work
| on them.
| 121789 wrote:
| Yeah, I agree with this. It's like writing a summary study
| sheet before an exam...the actual sheet is not that useful, but
| the work that went into it is. I've found OKRs to be pretty
| good for clarifying focus areas, both in my org and for
| personal development. Both the Os and the KRs will frequently
| change, but good managers/orgs don't really care about granular
| tracking
| larsrc wrote:
| There's plenty of problems with OKRs, but almost all the OKRs I
| encountered were bottom-up. I'm sure it was different in other
| parts of the company, though. Working on developer tools is the
| best.
| [deleted]
| Traster wrote:
| Quite recently I quit a company just as they were bringing in
| OKRs. The reason they bought in OKRs was because they felt that
| the engineering organisation was failing to meet the needs of the
| company. So they put together a list of Objectives and key
| results. They basically said "This is what we have to do to be
| successful". There were a few small hitches. Half the Objectives
| were outside the scope of the engineering team. We could execute
| perfectly, but if our internal customer fucked up, our objective
| would be blown. They explained this was because it doesn't matter
| if we meet some technical objective if it turns out that wasn't
| necessary for the company to make money. The second small hitch
| was they were diametrically opposed objectives. We were to going
| to increase our release cadence 10x. We were also going to reduce
| production issues by 100%. That's right, our objective was 0
| production issues whilst massively increasing our release cadence
| with 0 extra resources. The third issue is that they were
| unacheivable - we were supposed to deliver a 3 year project that
| would take 10 people in 1 year with 5 people.
|
| It missed that the reason the engineering org failed to deliver
| was that the internal customer would change the requirements of 6
| month projects roughly once a week.
|
| It was basically an exercise in trying to pin blame on engineers
| for the failure of the company. It didn't bother me too much
| because I was quitting anyway.
|
| OKRs don't fix dysfunctional organisations.
| theptip wrote:
| > OKRs don't fix dysfunctional organisations.
|
| Very true.
|
| However -- note that the process of implementing OKRs has
| caused the leadership team to write down their expectations,
| which previously might have been unspoken. This is a first step
| towards resolving the problem. The next step is for the CTO to
| push back, hard, on the bits of these that aren't actually
| realistic, and hopefully get the leadership team aligned on
| what can actually be done. And so, the process of OKRs
| potentially has value here in flushing out unrealistic or
| mismatched expectations between different parts of the org.
|
| This is one of those rare "my way or the high way" moments in
| leadership; as CTO at this company it's your job to either get
| the leadership team to realize that they are asking you for
| more than you can be expected to deliver, or quit. You can't
| stick around and put your name on a plan that you know is
| impossible; otherwise you're going to be the one that failed
| for every quarter to come. And even worse, you can't sign your
| team up for this BS. It's your job to shield them from this
| kind of shit.
|
| > Half the Objectives were outside the scope of the engineering
| team.
|
| Shared OKRs are difficult, but sometimes they are unavoidable.
| The most difficult business problems usually are cross-
| functional. At their best, OKRs can help to make these cross-
| functional dependencies more explicit, and foster communication
| and collaboration around them.
|
| If they are trying to have engineering take full ownership of a
| shared OKR, that's a big problem. But if you clearly call out
| the shared ownership, and consider both parties responsible for
| implementation, then I think that's OK.
|
| > We were to going to increase our release cadence 10x. We were
| also going to reduce production issues by 100%. That's right,
| our objective was 0 production issues whilst massively
| increasing our release cadence with 0 extra resources.
|
| As a tangential point, increasing release cadence can
| definitely decrease your long-term rate of issues (see
| "Continuous Delivery" by Humble[1]) -- this forces you to
| automate manual processes, and manual processes are one of the
| main places that errors creep in. Though I think "count of
| issues" is a very poor metric, you're better off with an uptime
| metric. And "100%" is the only strictly-incorrect number to
| pick for uptime, because it is literally impossible; my (super-
| unscientific, don't hold me to this) rule of thumb for business
| people is "every extra 9 costs you 10x". So do you need 99.9%
| uptime or 99.99%?
|
| [1]: https://www.amazon.com/Continuous-Delivery-Deployment-
| Automa...
| egman_ekki wrote:
| Having measures of success that are opposites of each other
| actually makes sense (as explained also in the High Output
| Management). That way you ensure you won't go too much into
| increasing release cadence at the cost of introducing too many
| bugs and vice versa.
| lloydatkinson wrote:
| I've only been at one place that had OKR's. That was my shortest
| job due to the toxic work environment. OKR's are simple enablers
| of toxic environments due to the amount of goal post moving and
| gaslighting.
|
| "Here is an arbitrary goal """you""" agreed to, why has it not
| been achieved?"
|
| "Well, you didn't really give me a choice and you also moved me
| to another project or the project was killed off"
|
| "not good enough"
|
| Yeah, I'll pass anywhere that encourages this.
| esel2k wrote:
| Quiet shocked by the negative comments regarding OKR. As a
| Product Manager I constantly have to tell the story to management
| after what I go. Whats the goal... And so the Objective is
| usefull. Example: Increase usage - so I look for weekly active
| users increase by x.
|
| If I now set that as part of my salary target etc is a different
| question, I am not a fan off. But having a direction and looking
| ar various is a good solution.
|
| As always if OKR don't help you, don't do them. But still better
| to try to measure and improve to get a better outcome, than to
| blindly follow the CEO or other brainfarts...
| wildrhythms wrote:
| As the resident 'fire-put-outer' engineer on my team whose
| priorities appear and vaporize every week or two, how do I
| quantify that work into quarterly OKR(s)?
| Jensson wrote:
| OKR are about the reason you get paid. The main reason they
| pay you seems to be to put out fires, so something like "Put
| out fires before things go bad" should be your OKR. If you
| did a good job putting out fires you get a high score.
|
| So many here say "OKR doesn't match what I really need to
| do", the answer is then always "then write down what you
| really need to do/focus on as your OKR". If your manager
| complains ask him "would you rather I work on this project
| instead of fixing a fire when a situation happens?", if he
| says yes then you should stop fixing those fires it isn't
| your job, if he says no then he should be fine with it being
| a part of your OKR's.
| balefrost wrote:
| I think a lot of people's introduction to OKRs is John Doerr's
| book "Measure What Matters". That's where I learned about them.
|
| The book explains how Andy Grove introduced the practice at Intel
| and it was very effective. The book seems to attribute the
| success to the practice itself and seems to say "if you adopt
| OKRs, you will succeed like Intel did".
|
| I suspect that this success is misattributed. I suspect that Andy
| Grove was probably an excellent manager and I think he could have
| succeeded with something other than OKRs. I think he understood
| that what was _really_ important was to get everybody across the
| organization to focus on essentially one big goal. He needed to
| make sure that everybody was pulling in the same direction and
| together, and OKRs provided a tool to do that.
|
| When my organization decided to implement OKRs, my question to my
| peers was "who is our Andy Grove?"
|
| If the people implementing OKRs focus too much on the practice
| and not enough on the motivation, I think you just end up with
| cargo-culting. The setting and tracking of KRs _becomes_ the
| objective. So people treat it like busywork because OKRs don 't
| really seem to matter - they just gets in the way of the
| "important" stuff.
|
| As one of my coworkers says, the title of the book is "Measure
| What Matters", but it's too easy to slide into "What Is Measured
| Is What Matters".
| hatware wrote:
| I can't be the only one who thinks the primary goal of OKRs is to
| keep non-technical managers employed, right?
| commandlinefan wrote:
| No, that's not the only goal - it's also there to create a
| paper trail to safely fire technical people who non-technical
| managers don't personally like.
| jaeming wrote:
| I remember when one member of my team put in an OKR for "learn to
| play the guitar" and mapped it into a training objective from
| above. It got approved, no questions asked. I was sort of
| disappointed management didn't follow up and ask him to perform
| for us all at the end of the quarter.
| quickthrower2 wrote:
| Probably the best OKR i have heard. At least it is good for
| morale!
| spaetzleesser wrote:
| "I was sort of disappointed management didn't follow up and ask
| him to perform for us all at the end of the quarter."
|
| that would have been pretty cool and given me lots of respect
| for management.
| partloyaldemon wrote:
| kbenson wrote:
| So, if you follow the link from the first word of the blog (the
| one giving details on what OKRs are), it takes you to a site[1]
| which when you go to the cookie prefs when prompted about what
| cookies you want, has a section I haven't really seen before (or
| was oblivious to before), called "Unclassified" with quite a few
| cookies. The difference between this section and the others?
| While others have a checkbox forced checked (Necessary cookies)
| or a checkbox you can toggle to accept or not (Preferences and
| Marketing), the Unclassified section doesn't offer up any
| checkbox at all.
|
| Seems awfully convenient to have a bunch of cookies you haven't
| classified so don't need to offer a choice to your users about.
|
| 1: https://www.whatmatters.com/
| jph wrote:
| I've seen OKRs significantly improve teams when there's full
| staff bottom-up commitment; I've seen OKRs totally fail when
| they're drive-by top-down directives.
|
| I maintain a repo of OKR guidance here:
|
| https://github.com/joelparkerhenderson/objectives-and-key-re...
| SaltyBackendGuy wrote:
| The biggest issue I've seen with OKRs is that it just turns into
| a game, and then proceeds to get "gamed". Separately, there has
| been more than one occasion where we chose to work on something
| OKR related but ended up providing less value to our end user as
| requirements changed mid quarter. Therefore making our initial
| OKR irrelevant, and preventing management from wanting to pivot
| to solve a real customer need.
| Jensson wrote:
| OKR shouldn't look like a set of sprint tasks, they are
| supposed to mirror what results matters to your team. If your
| team is supposed to solve the needs of a specific customer then
| your OKR should be something akin to "implement features to
| solve customer X needs and keep them happy" and not list those
| features explicitly since what you build doesn't matter, all
| that matters is whether the customer is happy so that is the
| key result. Alternatively the team can be focused on developing
| new generic features or products to be sold to many, in those
| cases you can list the products explicitly since then the key
| result your team is delivering is that product to sell instead
| of keeping a specific user happy.
| [deleted]
| SpaghettiX wrote:
| I read about OKRs briefly and worked at 2 companies that tried*
| to do it. Unfortunately, at both companies, management announced
| it to everyone, but I practically never heard anything after
| those announcements.
|
| I would like to boil OKRs down to a combination of 2 things:
| "goals + habits". Pick good goals, and design your
| days/behaviours/habits to get to that goal. Goals, habits,
| objectives, key results would all benefit from being measurable,
| clear, simple, etc.
| CobrastanJorji wrote:
| > All of them set a hierarchical pyramid of OKRs that cascaded
| down, rather than a set of OKRs that worked bottom-up, even if
| the company wasn't in a crisis and would have benefited from
| promoting innovation.
|
| Maybe I've only worked companies that do OKRs wrong, but I can't
| imagine what the bottom-up version of this would even look like.
| Individual teams pick their own OKRs, and then the exec above
| that looks at all of the OKRs that their various teams have
| decided on and then summarizes them in some way as their own OKRs
| after the fact?
| technovangelist wrote:
| That's kind of the only way I have seen them. Individual teams
| define the okr and they bubble up. I don't know what summarizes
| as their own would mean, but the first part was right.
| spookthesunset wrote:
| Bottoms up works really good. It needs to always be understood
| that bottom tier OKRs don't always directly tie to higher level
| OKRs and that is okay.
| djur wrote:
| This is a good insight. The biggest problem I've seen with
| OKRs is the desire to "align" them, which always ends up
| meaning that each manager rewrites their team's OKRs to fit
| into their director's OKRs and so on up the ladder. This
| doesn't "align" anything, it conceals a lack of alignment and
| makes it impossible to address whatever the underlying issue
| is.
|
| It seems to me that if the result of an OKR process is a
| bunch of team OKRs that have little to do with the company
| strategy, the result of that should not be to repeat the
| process or rewrite the OKRs but for company leadership to
| spend the next quarter figuring out what's going on
| (communication issue, too many underlying technical struggles
| to be able to prioritize, the company strategy is bad and
| nobody understands or likes it, etc.).
| spookthesunset wrote:
| In truth I kind of question the usefulness of "higher
| level" OKRs. They become too fuzzy and meaningless. Worse,
| I think it is almost impossible to come up with
| quantifiable key results that are directly influenced by
| the work of "lower level" OKRs.
| neerajk wrote:
| Any pro-OKR arguments now sound more and more like "But Real
| communism has never been tried" :)
| commandlinefan wrote:
| Every time I've seen it tried (over and over again in the span of
| a 30-year career), the "goals" are based on whatever the
| priority/flavor-of-the month happens to be when goal-setting is
| announced. I've never seen those priorities last an entire year,
| but I _have_ been called to account for why I didn 't personally
| meet the goals that I was pressured into setting "for myself"
| even though the priorities shifted over the course of the year.
| notreallyserio wrote:
| > called to account for why I didn't personally meet the goals
| that I was pressured into setting "for myself"
|
| This is one of the most hostile things an employer can do to a
| person. I don't want them involved in my personal growth --
| fuck allllll of that. I will grow when and how I want to, if I
| even want to.
|
| IME this never-ending push for continual improvement
| discourages me when I inevitably fail to meet goals they want
| me to want.
|
| I want to say "just leave me alone I'm speedrunning to early
| retirement" but that'll just get me in more trouble.
| corrral wrote:
| I worked at a smallish (~20 employees, at the time) agency that
| hard pretty good management overall, but one day decided to do
| OKRs. I assume one of the owners read a book or attended a talk
| or something.
|
| But we had no historical metrics on... anything, really,
| related to software development or design. Nothing that'd be
| useful for quarterly goals, anyway. "Close X tickets" or "make
| X commits" are famously shit measurements. We did client work,
| so we couldn't just try to decrease load times on one of our
| own products, or something like that.
|
| Having nothing meaningful to use for OKRs related to our actual
| jobs, developers & designers just latched on to sales &
| marketing projects and set our OKRs for those. Video views are
| relatively easy to measure. Sales funnel stuff's easy to
| measure. "Net promoter score". All that shit. The goal-setting
| for OKRs strongly favored sales & marketing, for whom measuring
| stuff was already _a lot_ of what they did.
|
| I'm not sure that's what they were aiming for, but it's what
| they got. I hope it was at least kinda useful for the company.
| spookthesunset wrote:
| NPS, specifically, is a hard metric to set an objective
| against. You can never really separate the stuff you did to
| your software from all the rest of the stuff that happened to
| your company.
|
| And yeah, using tickets as a success metric is gonna produce
| some incredibly awful behavior as people learn to game the
| system.
|
| Good OKRs are not easy. It's very hard to come up with good
| key results that incentivize the right behavior while
| actually measuring progress towards the goal. It takes quite
| a lot of skill to do that properly.
|
| To me the most important part of OKR's isn't really the
| metrics... it's the understanding that the team has been
| tasked with solving some problem without being told how to
| solve it. The team itself gets to own the solutions that
| drive the metric. Done correctly it lets everybody on the
| team take ownership of the product they are working on. It is
| far better than just being a feature factory that cranks out
| whatever sales or upper management thinks is a good solution.
| mcronce wrote:
| I've only ever seen OKRs attempt to be used by ineffective
| management who want to reduce everything, people included, to a
| number.
| goalie wrote:
| I've been so busy at work I haven't had time to "define" my Q1
| goals...it's Q2. I grow my skillset by doing my job well and
| attending trainings, I appreciate the idea of goals but they
| seem to set themselves.
| enos_feedler wrote:
| I worked at Google and been on teams where OKRs are used very
| ineffectively. Since then, I've read one thing that really
| changed the way I think about "goals" and could alleviate the
| problem you mention here. It's called the product strategy
| stack:
|
| https://review.firstround.com/set-non-goals-and-build-a-prod...
|
| If you have time, listen to the podcast. This is really the
| most comprehensive treatment I have seen related to OKRs and
| goal setting. Basically, goals are the last thing you consider.
| What is often missing is the high levels of the stack clearly
| articulated such that the goals make sense and measure progress
| towards a strategic outcome:
|
| "Our strategy is to increase revenue by 5%' or 'Increase
| retention by 10%.' That's not a strategy, that's a goal. It's
| great if you can achieve that goal, but only if it's actually
| part of a larger strategy that the company is trying to
| advance," Mehta says.
|
| "I often see teams get into a mode where they're just doing
| anything and everything to move the goal, without actually
| realizing they're headed in the wrong direction from a
| strategic standpoint to create long-term value." "
| fatnoah wrote:
| > "I often see teams get into a mode where they're just doing
| anything and everything to move the goal, without actually
| realizing they're headed in the wrong direction from a
| strategic standpoint to create long-term value."
|
| I see this all the time. Everyone is so focused on the "KR"
| that they know nothing about the "O". I want my teams to be
| bought into the overall Objective well before we start
| thinking about objective measures of progress and/or success.
| teraku wrote:
| It's like with most things in life.
|
| If you want to become fitter, don't think "I want to lose
| 10kg of weight", think about finding a sport which you like
| and healthy food which you enjoy eating.
|
| Your belly might not disappear 100%, but you will feel
| better, and you are in for the long run.
| goldenkey wrote:
| Specifically, eating sources of ecdysteroids like Spinach,
| Quinoa, Masal Root, etc. These are anabolic but do not have
| any androgenic side effects like conventional steroids.
|
| The Popeye spinach meme is real.
|
| I suppose if you come from a culture that eats insects you
| could also get a large amount of these compounds.
|
| https://en.wikipedia.org/wiki/Ecdysteroid
| jasonladuke0311 wrote:
| I'll bite. Are you suggesting that those foods you
| mentioned have anabolic effects analogous to exogenous
| steroids?
| WJW wrote:
| One of the downfalls of OKRs is that in many cases the true
| objective for people and/or teams is not something that can
| be mentioned without being unspeakably impolite. For example,
| the political goal "I as CTO want my department to grow by N
| FTEs so that I will gain in prestige compared to my peers in
| the C-suite" is definitely not something you will ever see on
| an OKR sheet but is definitely something that happens. On the
| other end of the influence spectrum, "I want to learn
| technology X because it will look good on my resume when I
| job-hop in a year from now" is also something you can't
| really use as a reason in a corporate setting but still
| definitely something that happens all the time.
|
| If you cannot start from the real Objectives and have to make
| up fake ones, determining effective Key Results to go with
| them is bound to lead to confusion.
| vmception wrote:
| > in many cases the true objective for people and/or teams
| is not something that can be mentioned without being
| unspeakably impolite
|
| At the individual contributor level the manager is always
| pushing for "personal OKRs" too
|
| And I've never been able to be honest or "authentic" about
| that
|
| Nobody could ever explain if it was professional
| development goals, extra responsibility or goals within the
| company or coding project, or actual personal. Other ICs
| would be excited to write their actual personal.
| icedchai wrote:
| I totally hate that bullshit. The last time I ran into
| this "personal goal setting" nonsense was at a company
| where I wasn't planning on staying around very long. You
| could say it was rather challenging to be authentic.
| oceanplexian wrote:
| Whenever someone asks that question I tell them my
| personal goal is to make more money. Ironically this
| sometimes leads to productive conversations.
| enos_feedler wrote:
| This is the dream response for any manager. I am the
| opposite and cared very little about making more money. I
| was more interested to reduce my life's operational
| expenses to get more out of the money I was already
| making. I got bounced around from manager to manager
| because of this. Nobody knew how to get me to do
| anything.
| PaulHoule wrote:
| It's funny.
|
| When it comes to personal development, side projects,
| etc. I have had times when I was very interested in
| setting specific goals and other times when I really
| didn't want to.
| deepsun wrote:
| Speaking for the devil -- that's going to happen anyway,
| but OKRs will force to put that into a framework, to come
| up with a reasonably looking excuse to do that. Better with
| excuse than without, no?
| Litost wrote:
| This hidden agenda issue can be very problematic, as you
| say it might be self-evident based on watching people leave
| that they've gone somewhere else for the "better" tech
| stack but you'll unlikely to get anyone to admit to it,
| unless you're working somewhere progressive and/or with a
| progressive manager etc.
|
| My last place we intentionally didn't use K8s but we were
| upfront with our team and hires (it was almost one of the
| first things I mentioned when recruiting) along with the
| reasoning.
|
| But unless people are honest about their motives, and this
| is something that has to cascade down from the top, you'll
| get all sorts of sabotaging behaviour, especially if OKRs
| are imposed from the top and not bought into/negotiated
| across the org.
|
| This gets worse when (due to human psychology and fast
| brain/slow brain traits, with the slow brain backing up the
| knee jerk fast brain) goals like the ones you mention are
| hidden (in shadow - see Jung). Or as mentioned in other
| comments you get the whole Economics externalisation
| problem when all sorts of 2nd and 3rd order+ goals (like
| team/org cohesion, fixing technical debt, taking ownership
| of incidents/problems or going the extra mile) which aren't
| in any of the OKRs get gamed out of the system because no-
| one's tracking them. This would be fine if the OKRs are
| light touch guides and not excuses to stick everything else
| on the bonfire. i.e. OKRs are in service and not master.
|
| I'm not sure how you mitigate this other than hiring people
| aligned with company values/goals/action who are less
| likely to just be (understandably because it's a jungle out
| there) maximising their pay and the modernity of the tech
| stacks they know and foster a culture of co-operation not
| competition.
| lovich wrote:
| > I'm not sure how you mitigate this other than hiring
| people aligned with company values/goals/action who are
| less likely to just be (understandably because it's a
| jungle out there) maximising their pay and the modernity
| of the tech stacks they know and foster a culture of co-
| operation not competition.
|
| I'm not sure it's possible to grow beyond a small group
| of people and actually maintain that. People would need
| to feel some significant ownership in the company and you
| can't spread a meaningful amount ownership across
| hundreds or thousands of people. And that's after the
| investors and execs take their cut
| hedora wrote:
| What you are describing is the opposite of agile, and also
| flies in the face of devops, so it's really hard to sell it
| in today's management culture. However, I've never seen agile
| or devops development processes work. I only work on big
| systems with year-plus timespans.
|
| I can imagine those processes working well for lean,
| piecemeal teams (like refreshing frontend site cosmetics once
| a year, or pumping out contract work every few weeks), or for
| technology-lean consumer startups building an MVP they plan
| to throw away once they have market fit.
|
| When I've seen project management work well, it's always been
| of the form (all these bullet points are mandatory, in my
| experience):
|
| - The goal for the product for the next 3-24 months is
| clearly articulated.
|
| - Each sub-team's 1-6 month goals are clearly articulated.
|
| - ICs produce a list of projects that should take one IC
| about a month, and that, if completed, will meet the sub-
| team's goal (deadline requirements are ignored during this
| part of planning).
|
| - Is "Number of projects / number of ICs" significantly less
| than the number of months to the deadline?
|
| - If No, this sub-team won't be able to ship, so adjust the
| scope, the resources, or the deadline.
|
| - Compensation is based on the performance of the product
| group, not the sub-teams. Somewhere between 1-10% of new
| hires end up being let go within 6 months. Hiring is never
| perfect, and firing people less bad for morale than having
| people sitting around being dead weight.
|
| Number of months varies depending on project maturity,
| business needs, and scope of the changes. Anything past 24
| months is best done in a graduate program, not a company.
| PaulHoule wrote:
| Goal setting is like other techniques in management.
|
| The quality movement went terribly wrong when the motivation
| became "We want to have an ISO 20022 sign in front of the
| factory" as opposed to "we want to crush the competition".
| See
|
| https://en.wikipedia.org/wiki/The_Goal_%28novel%29
|
| Probably the best phrase of that novel is "There is only one
| goal".
|
| I worked at an AI startup which was struggling to balance the
| long term needs of developing a technologically advanced
| product and the short term needs of delivering projects to
| major corporations.
|
| I saw the adoption of OKRs to be the beginning of the end of
| my time there because instead of carefully teasing apart what
| goals were necessary to realize their strategy everybody was
| told that they needed to list 20 or 30 goals, simply to list
| 20 or 30 goals.
|
| Not too long after I left the CEO announced that he was proud
| that the company had been acquired by a major athletic
| footware manufacturer. My hot take was "that's incredible!"
| because "incredible" was the CEO's favorite adjective, but
| really I told people all along that one of our engagements,
| if it fully realized its potential, would generate enough
| value for a customer that they'd see it as a bargain to buy
| the company.
|
| So of course this just makes people even more scatterbrained
| than they were before and worse yet it's rocket fuel for the
| psychopaths and narcissists in your organization because they
| are geniuses at playing that kind of game and they will use
| it to make themselves look good while making hard working
| people who are more interested in doing work and realizing
| the strategy look bad.
| elptacek wrote:
| Thanks for this. I recently left an otherwise awesome job
| mostly because of OKRs. I am still trying to articulate why.
|
| I'm going to correct you, because it's relevant. Mehta says,
| "but only if it is actually accretive to the strategy." I
| think the accretive is important here, because one of my
| observations on how we were doing it wrong was that there
| were no stated goals for security against the company as a
| whole. This made it seem like each teams' OKRs were a chaotic
| free-for-all. Intuitively, the goals for security as a whole
| should be based on the overall needs of the company, divided
| up across the appropriate teams. These teams will have the
| tribal knowledge to write the best roadmap, determine who
| will own the workflow that the project generates on
| completion and generally know how to scope each task.
|
| Going to listen to the podcast now. Maybe I will have more to
| say after. Cheers.
| mring33621 wrote:
| Annually, we're supposed to cut-n-paste several goals from a
| long list of mgmt approved blurbs. They are either hard-to-
| measure or metrics that I cannot really control. Whateva.
| serial_dev wrote:
| There are so many ways to do OKRs poorly, and I've seen many. I
| love the book in theory, but when I saw OKRs in practice, every
| company implemented this poorly.
|
| > Let's not have objectives just yet, we are not ready to
| communicate our goals yet with you, let's come up with key
| results... More like tasks, really just Jira tickets, our team
| already had to commit with management for the next year, we have
| a release plan and everything, so there is very little wiggle
| room there.
|
| > And please, don't ask about any of those goals, you are just a
| code monkey, and you weren't there at all the meetings, but trust
| us, it's the most important and impactful thing we can do...
|
| > Anyway, What's in the next 6 sprints? Let's just put them
| somehow in this OKR spreadsheet. Let's hope we don't need to
| change anything in the next sprint...
|
| > Hmm, alright, it looks like we have some space there, let's
| come up with 2-3 extra projects that realistically would need a
| team effort and a month focused work to complete, but you will do
| it on your own... Just remember that you should only work on
| items in the sprint, and the next 12 sprints are already planned,
| and we can't add your tasks to any of the sprints. You also need
| to convince the team that it's important, but please don't bother
| the team with your tasks, they will lose focus on sprint items.
|
| > I remember the book said something about something-something
| measurable. Unfortunately, no matter how many analysts we hire,
| they all quit around 3-4 months after they join, I wonder why
| that is. Anyway, we don't really have "numbers", so we can't come
| up with metrics, and we can't measure our success in any way, and
| we don't know whether gigantic projects bring any improvement at
| all.
|
| > Oh, and I'm pretty sure I will not be your boss, whoops, sorry,
| "competency lead" in three months because I'm actively
| interviewing to get out of here. Cheerio!
| theuri wrote:
| I've been wrestling with this recently as well, and found a great
| read re: OKRS versus a framework called OGSM.
|
| It provides the metrics and strategies that OKRs are missing -
| and results in deeper thinking up front.
|
| Here's a good read on this - https://medium.com/infinite-
| beta/ogsm-okr-8761dcb50e02
| Patrol8394 wrote:
| OKRs have become, like peer reviews, just one of those
| "corporate" things that you have to do, but that nobody really
| cares.
|
| My performance/bonus/promotions were never affected
| positive/negative, in any way by my OKR.
|
| Frequent re-org and change of direction very often invalidate any
| OKR one might even have tried to achieve.
|
| I wish companies realize that OKR, like working from the office,
| are things of the past that no longer fit in the world we live
| in, where things move at an incredible fast pace.
| athenot wrote:
| My biggest issue with OKRs comes from those who practice what
| could be called "Aimless Key Results".
|
| Instead of thinking about an _intuitive_ objective and then try
| to come up with some form of measurable Key Result that can help
| assess whether the org is getting closer to--or further from--the
| objective, some skip the whole Objective part altogether. They
| become so stressed with having something measurable that they end
| up with KRs based on how easy they are to measure, regardless if
| they actually correlate to a supposed objective.
|
| This is Goodhart's Law[1] on steroids.
|
| Healthy OKRs do exist but they have a few preconditions:
|
| - the individuals devising them must fully internalize which are
| the objectives that do matter for the org, among an ocean of
| "priorities".
|
| - the KRs must be carefully thought out and evaluated against
| their vulnerability to the law of unintended consequences.
|
| - the team(s) implementing the KRs must understand _why_ theses
| KRs exist, their relationship to the Objective they serve, and
| how well (or not) they measure the objective.
|
| - the leaders must be quick to change the KRs if there's any
| doubt as to whether they are actually helping, or causing more
| damage. The "why" should remain relatively constant over time,
| the "how" can change.
|
| - KRs that have thresholds should always be ambitious and very
| hard to actually meet, as they stretch the organization's goals.
|
| - Tying perforance bonuses to them is dangerous because it
| immediately results in gamification: Damn the Objective, I want
| my bonus!
|
| OKRs can be incredibly tricky for middle management because the
| top leadership may have a decent objective to be pursued, and the
| line managers may have a good grasp on what success looks like.
| But the middle part is caught in between the 2, and this can
| create all sorts of fun artifacts of measurement, aka.
| dysfunctions. Especially if that middle management layer doesn't
| have a rock solid understanding of the actual objectives and are
| only obsessed with the measuring part.
|
| [1] When a measure becomes a target, it ceases to be a good
| measure. --
| https://en.wikipedia.org/wiki/Goodhart%27s_law#cite_note-Str...
| andrewingram wrote:
| I have a slightly different take.
|
| I think there's a tendency to attach too much importance to the
| key results; though I very much agree with your point about the
| law of unintended consequences, this is why the concept of
| anchoring metrics/KRs comes up a lot.
|
| To me, the Objective is what you want, whilst the KRs are just
| a set of heuristics that tell you if the work you're doing is
| taking you in that direction. But I see it as a classic "the
| map is not the territory" thing. Too much emphasis on the KRs
| (like, as you say, tying bonuses to them) can lead to gaming
| the system and other failure states.
| crsv wrote:
| Ah yes, the 1000 word useless collection of thoughts on a nuanced
| and dense topic, followed by a flurry of kvetching and outlier
| horror stories in the comments. Classic HN work organization and
| management discussion.
| quickthrower2 wrote:
| I miss n-gate updates, but this made my minute!
| akomtu wrote:
| OKRs are New Year resolutions: "this year I'm try to stop
| drinking" or, if you want to sound more realistic, but still
| ambitions, then reword it to "this year I'll get less than 2
| DUIs."
| Apreche wrote:
| My issue with OKRs is trying to apply them to employees who have
| no power to make business decisions.
| spookthesunset wrote:
| OKRs are supposed to be liberating. In theory the management
| owns the prioritization of problems to be worked on. The team
| owns the actual way the problem is solved. Done right, OKRs
| help drive team level innovation.
|
| Of course there are plenty of ways to fuck up OKRs...
| [deleted]
| b3morales wrote:
| Or worse, doing a little farce where they supposedly "choose
| their own".
| cgearhart wrote:
| I've said for years that OKRs can make some sense at higher
| levels of the org because it's an easy way to communicate
| strategy but it makes no sense for individual engineers to use
| them. I think your comment explains why. At some point the
| people writing the OKRs no longer have the authority or
| autonomy to actually achieve them. So what's the point?
| spaetzleesser wrote:
| 100%! I have to set goals at the beginning of the year but so
| far every time priorities changed and the goals became
| deprioritized or obsolete quickly. And at the end of the year I
| have to map my achievements into categories like "increase
| market share" or "fuel international growth". My work is so far
| away from these things that it makes no sense at all.
|
| I can see this working for VP and higher who have a multi year
| perspective and can changes things as needed, but for lower
| ranks it makes no sense.
|
| The only realistic goal for my work is "Keep the f...ing system
| running and enhance as needed"
| andrewingram wrote:
| The most common failure states I keep seeing are:
|
| * Reverse-engineering the todo list to produce OKRs
|
| * OKRs being the wrong fit for the team and/or the company's
| lifecycle.
|
| The second one is more damaging, because it's subtle, whereas the
| first is obvious to everyone involved.
|
| Fundamentally, OKRs are a tool that should allow teams to make
| decisions about what to focus on, with the knowledge that they're
| aligned with the business objectives. If a team already has an
| immutable quarter+ roadmap, they're not making any decisions,
| they're just working; OKRs aren't a good fit for this kind of
| team. OKRs done well _should_ result in teams feeling empowered,
| because they can see the link between their actions/decisions and
| overall success. OKRs done poorly have the exact opposite
| effective; not just benign, but harmful.
| spookthesunset wrote:
| I actually don't think it is too bad to reverse engineer OKRs
| from the backlog.
|
| Well, maybe not completely reverse engineer.. just strongly
| influence whatever the OKRs are. I guess... provided whatever
| is in the backlog is solving the highest priority problems.
| Tomte wrote:
| > Reverse-engineering the todo list to produce OKRs
|
| I recently saw that. In a training. By a professional, paid,
| external trainer.
|
| We are supposed to take our backlog, comb it for stuff that
| always falls between the cracks, collect that, these are our
| key results. [1]
|
| Then we are supposed to invent a headline for all that assorted
| stuff. That's our objective.
|
| The whole procedure is supposed to be called "bottom-up OKR".
| [2]
|
| You don't have to tell me, I have actually read Doerr's book
| and know better, but everyone in that training went from
| knowing nothing about OKRs to knowing falsehoods about OKRs.
|
| [1] yes, he really confused tasks with measurable outcomes. And
| yes, that procedure ensures that the not-so-important stuff
| gets highest priority :-)
|
| [2] in reality, "bottom-up" refers to the company hierarchy.
| Bottom-up OKRs are set by lower-tier employees.
| timr wrote:
| It's not totally insane to want bottom-up OKRs. One of the
| common failure modes of OKRs is that the top-down view of the
| management doesn't connect well to the reality of day-to-day
| operations. So you often end up with people engaged in Kabuki
| theater (making up a nice story about how the things they
| were going to do anyway really _are_ the KRs for any
| particular stated objective).
|
| Of course, having teams produce bottom-up OKRs has failure
| modes too -- it's not really strategic planning if the leaves
| of the org tree are setting the goals. So you need both.
|
| A cycle of planning seems to work best -- a high-level goal
| is transmitted down, then each team engages in a local goal-
| setting process, then these goals go up, then there is
| coordination and refinement. But this takes _forever_ and
| requires incredible discipline, so it 's hard to do well.
| djur wrote:
| What this trainer was apparently describing as "bottom-up
| OKRs" sounds like what you're describing as "Kabuki
| theater".
|
| As for the top-bottom-top planning cycle, my experience has
| been that the "coordination and refinement" phase tends to
| mangle the OKRs beyond recognition. Management tends to
| "refine" what they were handed up by reframing it to sound
| like what their boss wants to hear. The concrete and
| achievable goals written by (or at least with the direct
| input of) the team get rewritten to sound more ambitious,
| but also more abstract, because management doesn't
| understand the goals as well as the team. The more layers
| of management you have, the more severe this effect, but it
| really only takes two or three to turn a solid list of team
| goals into a meaningless heap of synergy goo.
| timr wrote:
| Management doesn't write the KRs for the individual teams
| or people. If they are, they're engaged in _something_ ,
| it's just not OKR planning. Objectives and key results
| necessarily become less precise as you move up the org
| structure.
|
| > Management tends to "refine" what they were handed up
| by reframing it to sound like what their boss wants to
| hear.
|
| Sure, that always happens...but there's no system of
| management that is perfect. Humans gonna human. The only
| thing a system can do is make us aware of the biases of
| the people within it.
| Tomte wrote:
| Bottom-up OKRs are perfectly fine.
|
| But since objectives are often written at the top, with key
| results below them, this trainer believed that this is the
| top-down method.
|
| And bottom-up means defining key results and only after
| doing that deriving objectives from those.
|
| That's so obviously insane that I'm not surprised you
| misunderstood me, I should have written that more
| explicitly. :-)
| timr wrote:
| Ah, so you're saying he started from the KRs and back-
| calculated the O?
| mattgreenrocks wrote:
| Since OKRs are becoming so commonplace, what are some good
| strategies for playing the game sufficiently well enough to stay
| under the radar without a lot of time investment into it?
| corytheboyd wrote:
| Make sure your manager likes you.
| dboreham wrote:
| OKRs are a tool that barely competent psychopaths reach for.
| Possibly they work for other use cases (sales?) where everyone's
| a psychopath. The high functioning psychopaths don't need such
| ineffective tools.
| krnlpnc wrote:
| The main problem I've seen with OKRs in a technical setting is
| that they haven't accounted for steady state support, or sudden
| urgent issues.
|
| Both of those make up important work that has to be done in a
| timeframe shorter than the OKR reporting period.
|
| As a result important work goes untracked, and completeness of
| KRs are affected since people had to focus on "unexpected" issues
| instead.
|
| A compounding effect is burnout because a persons OKR workload
| and review process doesn't accurately reflect the day-to-day work
| that they did. Heroics are needed to avoid people higher up the
| management ladder seeing unfinished work under your name.
| wildrhythms wrote:
| Me irl :( Every time I'm sent the quarterly email demanding my
| OKRs I just copy over the couple of single line items like
| "Support X" and "Maintain Y". I'm sure there's someone I've
| never met wearing a suit and thinking I'm worthless as a
| result.
| spookthesunset wrote:
| I've seen this too. Unless upper management fully understands
| and supports the fact there is day to day "keep the lights on"
| work... a lot of what your team does won't get credit. It takes
| a lot of work to drill into everybody's heads that OKRs aren't
| an exhaustive list of what a team is working on.
| lisper wrote:
| The problem with OKRs is that they force you to set goals without
| doing anything to guide you about how to actually achieve those
| goals, or even to improve your odds. The industry fetish for OKRs
| is entirely due to survivorship bias. A few successful companies
| do OKRs and so now everyone does OKRs because no one stops to
| think about whether the success stories are because of OKRs or
| despite them. As an early Googler I can tell you from my
| firsthand experience that it was "despite" not "because".
|
| In fact, now that I reflect on it, the real function of OKRs is
| to get you to put in more hours, because either you haven't met
| your KRs yet and you need to keep working, or you have met them,
| and so you didn't set the bar high enough.
| digitalsanctum wrote:
| While I admire the optimism of what OKRs are suppose to do, I've
| never seen them done well or with a positive net outcome. In
| reality, it's been another one of those things that require
| discipline by everyone involved and is harder to accomplish at a
| large organization.
| savrajsingh wrote:
| This is why I prefer to work in startups. The objectives are more
| paying customers, more retention, and (for later stage companies)
| at a lower cost. If you're not doing something that moves the
| needle on those things in a startup, you're working on the wrong
| thing.
| ryan-duve wrote:
| The scenarios described here are familiar even though I've only
| spent a small part of my career doing formal OKRs. If your next
| blog post continues to mirror my experience, it will paint a
| picture of a quarterly OKR debrief meeting where half the people
| didn't work on their objectives and it just doesn't matter
| because they got good work done anyway. People who really like
| process and checklists will nail their OKRs, but they probably
| would have gotten the same work done in the quarter regardless
| so, again, it doesn't matter.
|
| Upon reflection, it makes me wonder if OKRs are better used as a
| corrective tool for a team than as a formal process for already
| high performing teams.
| hardware2win wrote:
| I feel like OKRs are poor version of google's 20% free time
| policy
| krinchan wrote:
| I think the only time I've seen OKRs work correctly is when they
| were super specific, singular, and very short term. The team I've
| seen use them generally picks something that aligns closely with
| something leadership wants to see progress on, that isn't a
| multi-year project, and is easy to measure directly.
|
| An example: Q1's goal was around tagging of AWS resources for
| billing. Our CBO came down with some new practices and automation
| around tagging and was having trouble getting traction in our BU
| with getting those tags in place for existing projects.
|
| The work was tedious, but not difficult. Progress is directly
| measurable (X of Y resources in Z account are tagged correctly)
| and the measuring is easily automated into a dashboard. It has a
| massive benefit for automating Change Management and
| Billing/Budgeting bureaucracy.
|
| I think OKRs have a place but I also think you just can't
| centralize them the way various big companies do. Even the
| "bottom-up" version just doesn't work because by the time the
| OKRs hit the C-Suite they're just mangled and incomprehensible.
| The OKR in my example never "escaped" past middle management. All
| the C-Suite knew was the CBO stopped whining about people not
| tagging their stuff.
| theptip wrote:
| I couldn't agree more here -- one of the biggest challenges
| I've faced (only rolling out OKRs to a ~50 person company, with
| just two layers, so nothing like Google-scale) was figuring out
| how to keep the different layers legible. I found the lower
| layer (team-facing) to be extremely useful, and the CEO-facing
| layer to be much more difficult.
|
| The dream is that you can imbue each employee with a "chain of
| objectives" that gives their work more purpose and clarity; I
| read an article on SpaceX that gave a rocket engineer saying
| something like "SpaceX's mission is to colonize Mars. In order
| to do that, one requirement is to build reusable rockets. My
| job is to build <rocket component X> in such a way as to enable
| cost-effective reusability." Perhaps that was a PR stunt but
| you can see how an employee with broader business context will
| be much more effective at making tactical adjustments within
| their domain of responsibility.
|
| In theory it should be possible to make some software to manage
| OKRs better than a spreadsheet; I looked at https://gtmhub.com/
| ages ago and didn't find it too useful. Maybe there is a good
| option now.
| simonswords82 wrote:
| Tired of people such as author of this post jumping on the OKRs
| are bad bandwagon. OKRs are a tool - they are not inherently good
| or bad but used well they can be good and misused they can be
| bad.
|
| My source for this is when I first used OKRs to manage a small
| team they were fantastic. Really focussed our energy and drove
| the team forward.
|
| Now I'm trying to grow the business I'm struggling to make OKRs
| stick as well as they did previously. I truly believe I'm
| misusing them as a tool - and now need to rethink my approach.
| maleldil wrote:
| I think we all understand that tools are just tools. But when a
| tool is as widely misused as OKRs are, there's probably
| something wrong with the tool.
| UglyToad wrote:
| I've only done them at one place over 1 year but they're easily
| among the worst things to come out of the Silicon Valley cargo-
| cult school of management.
|
| The root problem is that what works for the front-page of the
| internet who have a firehose of money and millions of users
| probably doesn't work for a pre-PMF start-up or B2B product.
| Primarily there's insufficient 'pressure' in any metrics to
| derive any meaningful signal from any changes a small group of
| developers can make. Any metric you can derive is way too noisy
| and spread over sales, marketing and development.
|
| Sure, Gmail can change the location of the Compose button and
| measure the change in emails started with high reliability, but
| when your feature has at most 5 users and takes 2 months to
| deliver the impact is far less clear.
|
| I felt in the company using OKRs we had one C-level person who
| was incredibly enthusiastic about them but with only 10
| developers we'd have been far better served by a unifying vision
| and shared product understanding.
| [deleted]
| Kalanos wrote:
| I agree. What could be more important? It is leadership's job to
| set the goals. If the goals fail, leadership has failed.
|
| Here is an expanded summary for those who want to learn more:
| https://medium.com/@rocketsyntax/okr-framework-strategic-pla...
___________________________________________________________________
(page generated 2022-05-18 23:00 UTC)