OKRs Are Hard | Hacker News Reader

OKRs Are Hard

skamille.medium.com

43 pointsfrostmatthew18 comments

Saw a tweet about this the other day, pretty crazy this company does OKR meetings on weekends: https://twitter.com/PeregrineBadger/status/15852624247807303... not sure about the employees' perspective but it seems to be working well!

They're fine enough for aligning the work of few related teams, but OKRs suck when forced on individuals as the focus for regularly scheduled performance evaluations.

Does anyone have examples of "good" OKRs for a developer / individual contributor worth sharing? Typical guidance I've seen is either generic to the point of uselessness or else involves numbers that are just completely outside the control of anyone in my role. The alternatives amount to one for one copies of Jira epics, which are too susceptible to the whims of product management or else personal growth stuff which is the first thing dropped when crunch time comes knocking. The obligation to write individual OKRs feels like providing a list of reasons to deny promotions when plans inevitably change over the course of an evaluation period. It's as if it were all smoke and mirrors for management to justify whatever it is they already wanted to do with you.

I don't really believe in "individual OKRs" even though that's talked about in Measure What Matters. You don't come up with a list of OKRs before driving to the store, but you absolutely reference the dashboard with clusters of gauges on your drive there.

At a firm level, this is as concise an example as any of what good looks like:

https://felipecastro.com/resource/The-Beginners-Guide-to-OKR...

For me, though, what good looks like is:

In OKRs…

- Os are the clusters of gauges you'd want on a live dashboard of your company (not of your product), (e.g., 1. maintain speed over distance, 2, engine running well, 3. vehicle systems nominal)

- KRs are what each gauge cluster's needles point at (1a current velocity, 1b trip distance, 1c fuel consumption, 1d miles to next oil change, 1e miles till empty)

Dashboard space is limited, so only have a specific number of clusters with no more than a few gauges per cluster (max 2 or 3 positive, max 2 or 3 counter-balances, no more than 3-5 total)

They are not project milestones, they are not deliverables per se, they are numeric needle gauges making subjective qualia (the Os) objective (the KRs).

Your GPS/map tool is for your projects. The dashboard is for how the vehicle is performing at its job.

As in the example above, consider having counter balancing gauges to keep you honest. For example, in cluster 2, RPM is great, but engine temp shouldn't go red and oil shouldn't go empty, or your high revs are gonna give you a bad time.

If finance or other overhead functions love running MBO (management by objective) using e.g. KPIs or BSC (balanced scorecards), let them. Don't screw up the value of a few clear strategic objectives with a few meaningful gauges with their excel spreadsheets.

Above, I've said I don't believe in personal OKRs. That's not entirely true: I think a lightweight process is super valuable to keep your eye on the ball, manage yourself above the day to day, run your career and personal life as if excellence matters in all things. Excellent work, excellent home, excellent friendships ... Same principle as TODO, DOING, DONE being same as personal Kanban, it categorically helps.

It's not ceremony or process that helps, it's the mindfulness and north star.

"They’re hard, but sold as something that everyone should do, so everyone does them poorly, and most people don’t see any value as a result."

OKRs are inane management fad. OKRs are "hard" because Objectives are vague and Key Results are vague leading to vague definitions of success and arbitrary flag planting.

Any management concept that is simultaneously so hard that no one does it right, but yet everyone is doing it is proof in point how valueless it truly is. Of course, when compensation, bonuses, and kudos are tied to OKR, people will keep doing them, as hard or as vague as they might be.

"Good OKRs tell a story about what is important, they help you inspire people to think about why they are working on what they’re working on, and I think they carry a bit of energy that comes from seeing how it all fits together in a succinct form."

That sounds more like a mission statement to me.

My experience was with them being imposed by mid level tech managers who went to a conference, read half a book or had a consultant whispered in their ear.

They didn't know what a good OKR looked like, but know the one your proposed isn't what they want. Keep iterating until everyone gets fatigued and you eventually settle on a set of OKRs everyone hates. Then priorities move enough that none of it matters by the time you planned to measure.

OKRs should be used to craft major projects and initiatives. They shouldn’t be used for direct performance evaluation.

They are helpful because they align effort and energy, top to bottom, in the direction most relevant for the business.

It goes without saying that if the organizational OKRs are messed up, then it’s messed up all the way to the bottom.

What do you mean vague?

OKRs were used for pivoting Intel from being a memory company to a processor company in a super short time frame. I believe they were quite successful.

So the team behind Intel is irrelevant, the success was all due to methodology, right?

Almost every person that tried to cure flu with homeopathy was successful.

OKR's are great for one thing: They force writing, which in turn forces clarity of thought. It's the clarity and focus that's important.

Good thoughts, but would be nice if they spent time focusing on reviewing good examples instead of just mentioning what not to do.

Yes, this is the problem with things like OKR and OGSM. People write up incredibly vague examples to protect imagined IP, or a bunch of counterexamples.

Rarely do you see anyone public a set of "this is what good looks like".

Here, this is what good looks like:

https://felipecastro.com/resource/The-Beginners-Guide-to-OKR...

The TL;DR is: In OKRs the Os are the gauges you'd want on a live dashboard of your company (not of your product) and the KRs are what each gauge cluster's needles point at.

They are not project milestones, they are not deliverables per se, they are numeric needle gauges making subjective qualia (the Os) objective (the KRs).

They don't work.

Creative work is not an assembly line. You can't predict the effort, and you can't control the outcome.

I don't think line workers on assembly lines have much exposure to OKRs.

OKRs are entirely about creative work and have seen success at tech companies that take management seriously.

The problem is that throughout the industry most managers were promoted into those positions without any training for being good at something else entirely. So even if they want to care, they generally have no idea where to begin. Self help books about business "heroes?" Focus on more metrics because they're something to show? Just focus on coding because that's what got them the promo? Et al.

I have a theory that management can be connected to portfolio theory as a variance-reducing process. Outcomes are random but bounded in expectation by the efficient frontier. When Google started, they hired the smartest people and enforced zero management and zero hierarchy, and thus were operating at the high point of both expectation and variance of outcome. Instantiation of OKRs brought their operating point down to something more predictable, but at a tautologically lower expected outcome. They notice this and keep trying to remove management on special groups like X, but then some new brilliant management idea comes along, and they adopt it with roughly the same results as every other new management idea. It's like the investment industry before Benjamin Graham.

In my dysfunctional organization we spend half of every quarter planning OKRs for the next.

First we have to collect all of the O's from top down and adjacent team blockers. Then we have to craft measurable KRs. Engineers are usually involved to size the effort of each. Then we need to make sure the total size maps to our bandwidth. We spend weeks prioritizing, and negotiating, pushing back up and to the side the work we can't take, and organizing cross-team dependencies to refine them to the final prioritized set.

At this point engineers have been dragged far into the planning process for sizing and have been thrashed by hearing glimmers of a chance to work on project X only to find out it's de-prioritized for project Y and now they have to size that effort instead.

The PMs will remind you if there isn't a number or a binary-sounding deliverable in every KR, and will hound you about getting a baseline and building the measurement tooling if there isn't one available. Sometimes making something measurable means instrumenting A/B tests, building dashboards, or instrumenting some metric capture. If it can't be measured, it can't be done in the OKR framework.

Once we begin the actual work In the glorious 4-week period where we aren't planning our next quarter OKRs, we're meeting daily and weekly to report progress at different levels. It's exhausting. This is where a lot of blatant funny business occurs with how folks measure and report progress that destroys the whole process.

I think on paper OKRs sound logical. Concrete goals and measurable deliverables are good. In practice it's a huge time suck and far less actual progress is made. It's a toilsome framework and a drain on morale. The only folks who seem to like OKRs are upper-management and PMs who are so detached from actual work that it's the only way they can feel like things are happening.

If someone is forcing you to implement OKRs, ask them to apply OKR to that process.

What is the objective that you're trying to achieve with OKRs?

How are you going to measure success (remember, you have to measure outcomes, not outputs)?

For a methodology that is all about metrics, it is almost impossible to measure.

Reply on news.ycombinator.com