Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OKRs will never be enough

edge.ceo

Post reply on HN
Print view View original

91–100 of 100 posts

Re: OKRs will never be enough

#91

Post by mbernstein »

keredson wrote: post #60
mbernstein wrote: post #54

Earlier quoted context omitted.

Management doesn't care if it's agile or not - they want something that works and delivers economic value for customers and will help them continue to innovate and deliver EVA for them in the future. One huge problem is that a lot of times, what people think is what the customer wants isn't what they want or need. One way that happens is sales brings asks (in the form of solutions often) to product and it goes downhi…

"Management [...] wants something that works and delivers economic value for customers and will help them continue to innovate and deliver EVA for them in the future." You're confusing "owner" with "manager". Most managers just want to get promoted, which usually means increasing their HC/budget, making sure credit for a project's success is their's, failures are blamed on others, getting trendy internal projects, do…

I'm not confusing owner with manager - I'm thinking of things through the lens of the principal-agent relationship and of upper management's goals (which was what the OP was talking about) rather the middle management's.

Re: OKRs will never be enough

#92

Post by hgsgm »

jkukul wrote: post #22

> When a startup is small, it can be sufficient to run a fairly simple objectives-and-key-results (OKRs) When OKRs were first used at Google it already had tens of thousands of employees. Why would any startup use a tool created by a big org and designed for a big org? Should we give infants medicines that were created for adults? Startups need to stop copying BigTech because they're not like BigTech.

I don't think that's accurate. They got OKRs early on from a VC John Doerr connected to Intel ("High Output Management").

Intel was huge when they started OKRs, but Google wasn't, in 2000.

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

Re: OKRs will never be enough

#93

Post by hgsgm »

deathanatos wrote: post #61

> OKRs inevitably become at odds with business results and the OKR system becomes bloated. It becomes hard to focus on the priorities that matter most while ensuring that every area of the business is running as expected. Is practically begging the question. If the business results are not matching up, what's going on? Are are your OKRs in conflict with running the business as expected? The title "will never be enoug…

Is your company successful? Or is their failure at OKRs a symptom of their problem?

Re: OKRs will never be enough

#94

Post by hgsgm »

dumbotron wrote: post #50
kenjackson wrote: post #2

The business scorecard just seems like it is measuring a set of key results. If it’s a KPI the team is trying to achieve then how is that different than a key result?

There isn't a practical difference between PIs and KRs other than that KRs might be more vague or binary and PIs more like a gauge. It's just semantics around framing goal-setting.

KPIs are more operational "is anything broken". OKRs are more aspirational "achieve something new".

Re: OKRs will never be enough

#95

Post by itsdrewmiller »

drewcoo wrote: post #66

So the simple modified MBO framework that Andy Grove era Intel used and then later Google used . . . just won't scale as startups get bigger? Something smells fishy.

I imagine both companies also have a financial plan and some kind of process for monitoring baseline KPIs, which seems to be the main point of the post.

Re: OKRs will never be enough

#96

Post by BugsJustFindMe »

ocimbote wrote: post #87
BugsJustFindMe wrote: post #53

Earlier quoted context omitted.

I'm an architect (software, not houses). There's a gigantic fucking chasm of difference between architectural design planning and OKRs.

What are your thoughts on some of the trends/buzzwords I find among Architects' communities these days, like "Evolutionary Architecture" or "Just Enough Architecture"? Note: I don't mean to lower their values by calling them buzzwords, but I truly see a peak of usage in the last 12-24 months, that gets me curious.

Unrelated to any specific subject, I dislike all buzz phrases everywhere everywhen, because they tend to only make sense to people after you explain what they mean. And if you have to explain what they mean, then the phrase wasn't helpful and you can just skip that part and get right to the explanation.

But it especially doesn't help anyone to say pithy business guru shit like "build only what you need". Sure, ok, but that's not the part people really need help with in the first place. Put up a poster that says "make the company more money than you cost it" with a picture of a cute kitten or something and move on with your day.

99% of all software engineers need to be told exactly what functions to implement and where and how to name them and how to organize them in order to not produce something disgustingly oppositional to use and maintainance because they completely lack any aesthetic sense whatsoever for their craft. So management can decide which bridge they want to prioritize safety in and let an architect plan it first before the wrench jockey who doesn't know a cantilever from their elbow starts bolting holes.

I don't know if I answered your question as expected or not.

Re: OKRs will never be enough

#97

Post by proc0 »

mavelikara wrote: post #32
proc0 wrote: post #19

This is the framework beneath the language that as an engineer has gone above my head for a long time. Large tech companies often fail to bridge this language gap, and maybe that contributes to some friction overall. On a slightly different note, it would be great if organizations had no expectations for engineers to learn or know about any of this... and also get promoted. I went to school for so long to be a techni…

If you do not contribute more to the business than the job you originally took, why should you be promoted? I can imagine you getting a raise as you demonstrate more proficiency in the job, but promotion seems to imply that you do a different job for the business.

Fair point, although remaining in the same position without promotion is usually discouraged and not a real option in the long run. Yes, promotion means more value added, but that can be defined many ways. In tech companies it usually includes having more management and/or other non-technical skills (for technical workers). The value could be more aligned with just having more technical skills. It could even be formally assessed by reviewing code and even test, yet from my experience more technical skills had little impact on promotion chances.

Re: OKRs will never be enough

#98

Post by testfrequency »

I’m so fucking over everyone spending time trying to re-invent the methodology in which work is accomplished.

Just do the work, do it well, make it measurable, and hit 80% of your aspirational goals

Middle management needs to find something else to do, like complain about single panes of glass and metrics

Re: OKRs will never be enough

#99

Post by testfrequency »

BugsJustFindMe wrote: post #8

I don't care what managers do as long as it's managers doing their own fucking jobs instead of forcing it on everyone below them. Individual engineers shouldn't have to plan objectives, their own or otherwise. That's literally what management is for in the first place.

Here here!

Re: OKRs will never be enough

#100

Post by mejutoco »

loeg wrote: post #46
mejutoco wrote: post #42

From wikipedia ( https://en.wikipedia.org/wiki/OKR ) > Key results should be measurable, either on a 0–100% scale or with any numerical value (e.g. count, dollar amount, or percentage) that can be used by planners and decision makers to determine whether those involved in working towards the key result have been successful. There should be no opportunity for "grey area" when defining a key result. In a lot of places…

> This means your bonus now depends on politics, instead of a defined metric of success. The process of defining a concrete metric in advance is just front-loading that politics process to the planning stage instead of at the back end. (Which may be better! But it doesn't eliminate politics.)

That is a good angle. Let me elaborate.

I am not so much talking about the correctness of the metric, but about the certainty that you will get it, if your results are good.

If there is no specific number someone can always say you performed bad one day before, for pretty much any reason (you did not care enough about the customer). This can destroy morale.

Instead, if the metric is quantifiable and easy to check on a dashboard there is no way to deny it. By the time the evaluation comes there is no manipulation possible.

Post reply on HN