Live data from Hacker News

Why OKRs might not work at your company

svpg.com

21–30 of 140 posts

Re: Why OKRs might not work at your company

#21
The summary is "your company may not yet be worthy of OKRs". This kind of has the whiff of other religious movements in tech like REST and Agile: if it's not working for you, you just aren't doing it right. Try harder and hope to one day be worthy.

Re: Why OKRs might not work at your company

#24
I didn’t read the article. Is it because OKRs don’t work anywhere at all, and are only successful when they are ignored? At Google that’s certainly the case; the better a group is at paying lip service to OKR planning, the more work they actually get done.

Re: Why OKRs might not work at your company

#25
post #18
post #8

Biggest complain I have with Marty Cagan is he always describes the perfect product organization and says anything else is shit. Well you can't choose your execs, you can't choose your culture,.. so thank you for describing what is the ideal world, but almost no company will be able to apply your advice. Again in this article he doesn't explain how to replace OKR, but just says, if OKR doesn't work then your culture…

If your business relies on a blogger for its operating strategy, you are doomed.

Pithy and funny, but counterpoint: we've all surely noted businesses for which this would've been an improvement.

Re: Why OKRs might not work at your company

#26
post #9

BD needs to generate enough sales to keep the engineers stressed out. When you don't have that, you end up with politics. OR the company is pre PMF, and everyone needs to operate in that mode.

What is BD, OR and PMF?

BD = Business Development, aka sales

PMF = Product Market Fit

Unsure on the OR.

Re: Why OKRs might not work at your company

#27
post #8

Biggest complain I have with Marty Cagan is he always describes the perfect product organization and says anything else is shit. Well you can't choose your execs, you can't choose your culture,.. so thank you for describing what is the ideal world, but almost no company will be able to apply your advice. Again in this article he doesn't explain how to replace OKR, but just says, if OKR doesn't work then your culture…

It's like the Martin Fowler of business organization

Re: Why OKRs might not work at your company

#28
Not very sure if OKR should replace the KPI in most of IT companies since OKR mostly aims at developers. I've experienced one company that request their employees to do OKR weekly and monthly. It actually helped a lot at the beginning coz everyone is curious and energized.

But after a few weeks, indolence came out because someone forgot to submit the OKR. And other members also do the same thing. Pretty much of a "broken window effect". The workload was very high, so OKR wasn't attached any importance. Or maybe we did it in a wrong way.

It doesn't mean that we might not have to align with OKR, but the method of implementing the OKR insistently and continuously should come first before it takes places.

Re: Why OKRs might not work at your company

#29

I didn’t read the article. Is it because OKRs don’t work anywhere at all, and are only successful when they are ignored? At Google that’s certainly the case; the better a group is at paying lip service to OKR planning, the more work they actually get done.

Its a 2 minute read, go see for yourself

Re: Why OKRs might not work at your company

#30
> The main idea is to give product teams real problems to solve, and then to give the teams the space to solve them.

First, there's a dearth of high quality engineers in the industry. They've been gobbled up by SV companies with large paychecks and promises of "fuck-you money" paydays. Everyone else gets developers in the range from above average to bad.

Product teams only work with high quality engineers across the entire product. Why? Because if they're shitty, there's no bound to creep of shit code, call it "shit creep" (see footnote 1)

How do you fix a shitty product team, other than replacing the entire team, or product with hopefully a better team?

Sure, feature teams are more limited in scope and their abilities, but they at least constrain the shittyness to a feature. If the feature needs to be replaced, the team can just be replaced, not the entire product.

(1) We've all had to deliver shit code from time to time. The thing is the good engineers know it's shit and refactor it as soon as they can.

Post reply on HN