Why OKRs might not work at your company • Hacker News Board

Re: Why OKRs might not work at your company

#71

Post by toast0 » Mon, Jul 20, 2020, 4:30 AM UTC

cortesoft wrote: post #57

toast0 wrote: post #47

Earlier quoted context omitted.

I worked at Yahoo from 2004-2011. This is my opinion only. Yahoo was doing pretty well at times during that period. Certainly, Google had better revenue numbers and better margins, but Yahoo was still making tons of money, just not as much. Leadership had a tough time explaining what Yahoo did; although, they had a clear goal in 2004 era onboarding --- be in the top 3 of all internet verticals either through owned an…

Wouldn't your comment suggest that management DOES matter then? The person I replied to says that google has terrible management but is successful because of their starting position. As you have pointed out, bad decisions by management can lead to a company's downfall.

Yes. Definitely, sustained poor management can lead to a company's downfall. You have to continually sabotage your company to kill it. Just mediocre management or incoherent management won't do it. (But it might set the stage for worse decisions)

Google does seem to sabotage a lot of its products, but so far hasn't really sabotaged its core products or its company. As long as they don't destroy the dollar printing press (Adwords/search), they can keep pissing away money on dumb things and it won't kill them.

Re: Why OKRs might not work at your company

#72

Post by henrikschroder » Mon, Jul 20, 2020, 4:42 AM UTC

toast0 wrote: post #47

cortesoft wrote: post #38

Earlier quoted context omitted.

Why didn't the other companies that were those things succeed then? (Yahoo, Altavista, etc)?

I worked at Yahoo from 2004-2011. This is my opinion only. Yahoo was doing pretty well at times during that period. Certainly, Google had better revenue numbers and better margins, but Yahoo was still making tons of money, just not as much. Leadership had a tough time explaining what Yahoo did; although, they had a clear goal in 2004 era onboarding --- be in the top 3 of all internet verticals either through owned an…

I joined Yahoo in 2013, and my impression was that it was a company that still made a ton of money, because at one time a lot of really clever people used to work there, and their stuff continued to make money, but the people working there were not clever enough to build on it, they were barely able to keep up on maintenance of it.

I encountered a ton of cool technical solutions to things that were Really Hard Problems in the 90's or 2000's, and that was appropriate for hardware from that era, but the outside world moved on, while everyone inside Yahoo still thought that their shit was hot shit.

There were for sure a lot of smart people still working at the company, but the company had 0 cool factor, so they had an incredibly tough time recruiting and retaining people that could move the state-of-the-art forward.

...and no buzzword management strategy like OKR's or whatever is going to change that fundamental problem.

Re: Why OKRs might not work at your company

#73

Post by keeptrying » Mon, Jul 20, 2020, 4:44 AM UTC

The downside of OKRs is that it incentivizes everyone to sandbag their efforts and then stick to that effort. Also no one is going to stick their neck out on goals which are ambiguous or lack clarity. There is just no incentive - in fact there's a massive dis-incentive.

If you have a startup with less than 300 people and you have good communication and goal setting, don't use OKRs. Use KPIs and then nehlp your teams to keep iterating.

Input management is so much more effective than output management but it needs visionary leadership. Read: High Output Management - Andrew S Grove (ex Intel CEO).

Re: Why OKRs might not work at your company

#74

Post by hapticmonkey » Mon, Jul 20, 2020, 4:55 AM UTC

rufusroflpunch wrote: post #67

My company is adopting this. They just gave a big company wide meeting/sales presentation on this. I ended up tuning it out after a few minutes. Maybe that was a mistake but I am just so sick of the corporate gobbledygook dog-and-pony show. At the risky of sounding ignorant, these corporate productivity systems feel like cottage industries invented by consultants to sell to management looking for a reason to justify…

The core concepts behind OKRs (and others like it) are pretty good. The problem is that almost all of these methods require managers to cede power and control over to the developers. And that rarely seems to happen. So as a developer it just becomes another layer of bullshit to deal with.

It pretty much boils down to: Set well defined, well reasoned, and slightly ambitious goals...communicate them to your developers...and then leave them the hell alone to try and accomplish them.

Re: Why OKRs might not work at your company

#75

Post by quickthrower2 » Mon, Jul 20, 2020, 4:59 AM UTC

bretpiatt wrote: post #26

leetrout wrote: post #11

Earlier quoted context omitted.

What is BD, OR and PMF?

BD = Business Development, aka sales PMF = Product Market Fit Unsure on the OR.

It think that's just a regular old Or gate.

Re: Why OKRs might not work at your company

#76

Post by xtracto » Mon, Jul 20, 2020, 5:14 AM UTC

crooked-v wrote: post #22

My only experience with OKRs has been having to do more OKR-management homework separate from the actual work I do, which is the same 'coding stuff off the product roadmap supplied by a different department' as always.

That's why as a manager I always set my teams okrs to be aligned with whatever crap business is going to place in the scrum stories.

I've seen tech OKRs that are things like "reduce tech debt" or "decrease loading time" or "reduce downtime" but without hard tangible stories in sprints, it's just wishful thinking.

Re: Why OKRs might not work at your company

#77

Post by jldugger » Mon, Jul 20, 2020, 5:32 AM UTC

pitayan wrote: post #69

jldugger wrote: post #63

Earlier quoted context omitted.

> OKR mostly aims at developers Ops can totally have OKRs. Fewer incidents, faster resolution, faster deploy times, longer log retention, decreased AWS spend, the list of objectives I can think of off the top of my head is quite long. Same for project managers: on time projects and reporting, better estimates, faster issue triage, more a/b experiments, more features launched. OKRs done well are effectively a method o…

> OKRs done well are effectively a method of improving KPIs by recursively breaking work up into subtasks I strongly agree. (thumb up) Well, of course Ops can have OKRs as an HR evaluation method. KPI's shortcoming is obvious, most of the results need to have a quantified indicator which is not very appropriate for engineers' situations. But it still can be used as a complementary of OKR to provide clear numbers or d…

IMO, OKRs should be quarterly targets. Enough time to meaningfully make and measure changes repeatedly.

Re: Why OKRs might not work at your company

#78

Post by summerlight » Mon, Jul 20, 2020, 5:43 AM UTC

User23 wrote: post #64

mahmoudimus wrote: post #50

Earlier quoted context omitted.

Google engineering is fantastic and respectable. What gives the impression that it is anything else other than excellent?

Well here’s one example: https://reasonablypolymorphic.com/blog/protos-are-wrong/inde... . Another is the frat boy hazing code review culture. Heck there are plenty of noogler’s first code review memegens floating around. It’s totally not bullying it’s just joking right?

https://news.ycombinator.com/item?id=21873418

The author of that article completely confused about the goal of protobuf. Read this rebuttal comment, written by the previous owner.

Re: Why OKRs might not work at your company

#79

Post by cpeterso » Mon, Jul 20, 2020, 6:19 AM UTC

akmarinov wrote: post #7

One of our senior leadership people read the book, got in his mind that we need this at the company, got together the managers of all departments, they figured out some OKRs and now everyone’s off working on implementing them. Some of them are rather impossible, like teaching all devs on how to do devops within 2 months, so they can be self sufficient.

> teaching all devs on how to do devops within 2 months, so they can be self sufficient.

At least this Key Result is measurable: 100% devs know how to do devops. :)

But who is the individual accountable for implementing this Key Result? For a task that broad, I hope a department manager is responsible for creating a training problem, not individual devs responsible for teaching themselves.

Re: Why OKRs might not work at your company

#80

Post by cpeterso » Mon, Jul 20, 2020, 6:26 AM UTC

jacques_chester wrote: post #42

I really ought to read an OKR book, because the telephone-game version I hear about seems problematic. For example, Austin's Measuring and Managing Performance in Organizations [0] gives a helpful 3-party model for understanding how simplistic measurement-by-numbers goes awry. He starts with a Principal-Agent and then adds a Customer as the 3rd party; the net effect is that as a Principal becomes more and more energe…

> I really ought to read an OKR book, because the telephone-game version I hear about seems problematic.

I've read John Doerr's Measure What Matters OKR book and personally used OKRs for a few quarters. Google's re:Work site about OKRs is short and adequate summary:

https://rework.withgoogle.com/guides/set-goals-with-okrs/ste...