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.” "

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.

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.

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

2) but sabotaged by a general (lack of) friction in people's ability to move jobs (I'm averaging about 2 years now per company, down from 4-5 years around 20 years ago) and this isn't seen as a negative.

3) This obviously can create large internal friction, especially when every new person brings new challenges (or fads) to the strategic direction such that you can spend more time changing (tooling or process or organisation structure) than actually doing real work.

4) As mentioned in a recent post here, this tendency to pay market rate for new hires, but not to pay market rates to more productive people already working for you also exacerbates this, but everyone just shrugs and plays the game because no-one's invested enough in the process to challenge it (or those that are and do just get labelled as awkward).

So it's interesting the "fetish" for OKRs in many spaces that can make people look good, but how often do they actually track the actual "costly" actions like

a) perpetual people leaving -> hiring -> training/getting up to speed cycles

b) or number of hours wasted in meetings or context switching due to interruptions or

c) deciding to outsource something you've just spent 9 months insourcing to a different company than the original one you insourced from at great financial/opportunity cost (assuming they even succeed and it doesn't take 3 attempts) etc.?

d) Let's rewrite everything in new tool X I need on my CV because you won't pay me market rate so I'm now looking after myself...

Without surfacing these costs, how can you make effective decisions???

[1] - https://www.youtube.com/watch?v=chKZ5BVxTfY

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.

The honest truth: I didn't have any goals, and still really don't. I just wanted good, interesting work to do during these dark times (pandemic, etc), with as few interruptions as possible.

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.

The more you understand the real motivation of people the harder it gets to take business goals and decisions seriously.

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.

I don't know what would be considered too much spinach, personally I include it in my salads but not as the base (usually that's romaine for me), and sometimes Sautee some to go with eggs for breakfast, but I don't get it every grocery trip.

https://www.livestrong.com/article/529555-what-are-the-effec...

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.

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.

And as always, there is no process substitute for adequate management.

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.

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.

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.

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.

I find #1 is more prevalent as most people are competent but I might be a bit generous in that assessment.

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.

Unfortunately Doerr presented a football team example in a pathetic attempt to explain how okrs cascade directly.

Because of this, okrs have been done poorly at so many orgs. Sadly, okrs software companies saw the simple computation from set theory to make krs be children of higher level objectives so they could make cool visual maps illustrating how okrs connect.

So, yeah, I feel you, “Whateva”

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".

I think “focus” is the keyword and am very glad to see this pointed out.

The company I’m at has gone into OKRs thinking that it’ll be some magical, productivity unlocking tool. However, when multiple people asked what the company strategy was and what we were planning to focus on, the response was that they (C-suite leaders) wanted to continue tackling every opportunity. That they think having OKRs will lead to the same workforce being able to tackle more things. It was really weird to try and write OKRs where literally any measurable outcome could be considered success. It wasn’t a surprise when I read the OKRs for other teams and orgs and saw everyone rowing in different directions ¯\_(ツ)_/¯

Goals != Strategy and that took a while to realize.

I wish I read Good Strategy Bad Strategy and The 7 Powers first.

It offers no value to anyone trying to actually deploy okrs in a given organization or team.

But hey, it does fire up execs!

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.

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.

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?

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.

> 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.

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.

A status meeting serves to reinforce the social status of the one who called the meeting. No other status is relevant.

* 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.

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.

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.

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.

> 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.

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. :-)

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.

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?

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.

I still don’t even understand how that’s supposed to work unless you’re an executive with wide latitude to do what you think is best. I worked on what my manager told me to work on. All I can control is the quality of my own work. Maybe it wasn’t meant for the rank and file.

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"?

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.

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

I don't understand this aspect of corporate/startup culture. Who the hell likes ice breakers in meetings? Everyone I know -- and I mean everyone -- has started joining late in an attempt to avoid ice breakers.

(I actually know who likes them: all those "life coaches" that regularly get hired by startups with too much money.)

They are infantilizing, kindergarten-like activities for adults who will never again speak to each other until the next ice breaker activity.

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...

But for Engineering? I had all kind of nice reading OKRs: reduce mttr, mttf, reduce bugs, reduce feature implementation time, etc. But in reality the day-to-day work of Engineering was "build the shit that the product team defines", we had little influence in stories that went on each sprint, and invariably every time we pushed for some technical matter, business always trumped us and the stories went to the backlog.

  > But in reality the day-to-day work of Engineering was "build the shit that the product team defines", we had little influence in stories that went on each sprint, and invariably every time we pushed for some technical matter, business always trumped us and the stories went to the backlog.

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.

Yes! In my past two jobs I finally learned to never pay attention to official performance reviews and career goal plans and personal goals tracking systems: every 6 months to 1 year, like clockwork, someone important in HR gets replaced, a new tool to track goals gets bought, and everything is redesigned from scratch.

The only way to get a promotion or a pay rise is to push for it on a completely different band, nothing to do with these systems.

> 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!

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.

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...

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.

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.

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.

Of course there are plenty of ways to fuck up OKRs…

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"

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.

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...

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.

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.

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.

Making people mistakingly create new accounts indeed helps you hit your # of sign ups goal but at what cost?

I maintain a repo of OKR guidance here:

https://github.com/joelparkerhenderson/objectives-and-key-re...

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.

If the product objective is to grow an app to 100m users, the objective of a backend distributed systems team would be to scale the system to handle the load.

If front end requirements change, for example the app needs to serve videos instead of images, entire OKRs of the backend team might need to be rewritten. If requirements change often enough the backend team OKRs just become meaningless. If they follow your model, the backend team objective would be to just "help the product scale", and the personal OKRs would be just to "help the team scale the backend and make my EM happy" because there's no way to really plan for what the product team wants next. That may well be the only thing that can be done, but it's a degeneration to a system that offers no clear accountability, and just points to the futility of sticking to the OKR model in a large organization that needs to move fast.

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.

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.

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.

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.

"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.

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

2-individuals should not be defining okrs at their level. I don’t see many people doing this anymore… even Google came out and advised against this practice as it leads to a lack of collaboration. And okrs end up looking like personal goals such as “buy house in Mountain View”

3-okrs should not be a to-do list, but looks like many, if not most, teams who think they are doing “okrs” simply make a to-do list and call it “okrs” which is ironic since okrs are about outcomes not output.

4-Okrs work best when leadership stops saying just “be innovative” and instead says “successfully expand the ecosystem of product ABC” Then describes why that objective is important and why now to educate and motivate the company. And then gets input to solicit how we will agree on what measurable progress will define the achievement of the objective so we all know what the goals are for the short term. But okrs do not work when krs look like “reduce the backlog” or “fix bugs” as those are not actually “krs” they are “to-do lists”

5- last point, and most importantly… okrs is a “verb”, a way of asking questions. You are doing okrs when you are asking yourself and others include the following questions:

A-what is the most important area to focus on making progress in near term? Why? B-how will measure progress on the objective? C-what is the intended outcome of the task (because people will answer question B with a task list)

If you ask these questions of yourself and others, good things happen. If you use okrs to make a to-do list or evaluate performance of staff, you will end up complaining that okrs don’t work. Your choice.

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.

that would have been pretty cool and given me lots of respect for management.

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.

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.

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.

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…

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.

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.

LOL this paragraph really spoke to me. I've been in FAANG for 6 years, and every time roadmapping/OKRs come around this always happens.

As an IC, those weeks spent planning are precious time that could be spent landing ~impact~ for your performance review, so you might do a mini-planning session to figure out how to use your time. That project that you picked up ends up getting traction, but due to disconnects with the team's planning process, the overall OKRs no longer align with your work! Guess we'll have to fudge the numbers...

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?

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.).

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.

Here is an expanded summary for those who want to learn more: https://medium.com/@rocketsyntax/okr-framework-strategic-pla...

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

(Yes this is off topic and about formatting and it's boring.)

For now, if you want, you can click the circle in the upper right to toggle to light mode.

Thanks for the feedback!

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.

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.