All these frameworks for managing people matter much less than creating a team of quality people. Think of it like sports. Sure a good manager or coach can get the most of the players on the team. They might even add tactics and play above their level. But when it comes down to it, what matters the most in the skill set of the players. The best coaching in the world isn’t going to help me and my friends beat a pro sports team. Same thing for teams inside companies. Strategy does matter, but quality matters much more.
The people upvoting this blog can’t have read it, since an HN audience would not possibly think the solution to OKRs is to supplement them with a reductionist income statement and traffic light scorecards
The problem with all of these performance management frameworks is the same.<p>You start with objectives that make sense and are aligned to the organization's mission.<p>Then you come up with metrics that attempt to measure how successfully those objectives are being realized.<p>Then you tie manager and executive compensation to those metrics.<p>Finally everyone proceeds to game the metrics, often in ways that completely contravene the original objectives, in order to maximize their bonuses.<p>Rinse and repeat.
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.
I don't know what the rest of the comments are on about but this is a pretty reasonable proposal. In particular, it's heinous to couple customer acquisition to engineering projects. Maybe customers don't want what you're selling, or maybe the economy is taking a down turn, or the sales pipeline is broken.<p>OKRs can absolutely be useful, but like so many other things, a system is what it does. If you measure bug rate, then you'll get no bug reports, even if there are bugs.<p>OKRs, when done correctly, aren't about accountability necessarily, but course correcting early and often. It's a tool to combat scope creep and a feedback loop for triggering pivots when progress towards laid plans aren't yielding returns.<p>These are things engineers should love! They keep engineers focused on the right things, aligned with the business and most importantly keep the business aligned with them.<p>Politics and bureaucracy are rampant everywhere, but like everything else, when used in moderation these tools can be really good.
I am so happy to work in a company that does not work with this business voodoo (and still delivers great results).
All goal frameworks I have worked in, OKRs included, were a colossal waste of time.
While the article may be good at explaining organizational goal setting, personally I f*g hate anything about this HR bullshit. It's simple: make goals, do them. Don't overcomplicate and annoy people who actually do smth compared to those that just talk.
> When a startup is small, it can be sufficient to run a fairly simple objectives-and-key-results (OKRs)<p>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?<p>Startups need to stop copying BigTech because they're not like BigTech.
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?
> <i>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.</i><p>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?<p>The title "will never be enough" is business dystopia to my ears. OKRs are bad enough — and you want <i>more?</i> OKRs as implemented where I've worked is the "O" is often BS, everybody skips the "KR" step <i>completely</i>, often naming abstract wibbly-wobbly goals in its place, and by Q3 it's all been forgotten about.
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.<p>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 technical person but it seems every org expects engineers to learn everything about business operations, management etc. It's just a strange expectation, like being a plumber but then you also have to take care of the plants outside and do some gardening.
At this point, I'm full "sickos.jpg" watching organizations switch goal setting frameworks to fix issues stemming entirely from communication, planning, and accountability problems. I'm not even going to get started on how silly these scorecards are considering the metrics shown are a <i>minimum</i> for running a business.
From wikipedia (<a href="https://en.wikipedia.org/wiki/OKR" rel="nofollow">https://en.wikipedia.org/wiki/OKR</a>)<p>> 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.<p>In a lot of places that use "OKRs" the metric is something non-specific, like "get more users" or "have a great UX". This means your bonus now depends on politics, instead of a defined metric of success. When the metrics are clearly defined, work can be a pleasure.
You <i>can</i> use a different framework here, but you can also just use OKRs too. I argue mixing OKRs and KPIs just muddies the water for little value.<p>Even within engineering, some teams are more geared towards “sustaining quality” than “expanding capabilities”.<p>You can just as easily set a “maintain quality” or “sell our product” objective that may or may not have explicit initiatives, and call the KPIs from the article KRs instead. There is really no difference.<p>You often see this within teams too; it’s best practice to have a quality metric as a guardrail to any growth metric (eg “add users, but don’t increase churn for existing” or “build new functionality, but don’t impact API uptime”). So you end up needing to represent these non-initiative-driven metrics that the article wants to call KPIs in your OKR system anyway.<p>KISS!
I’m so fucking over everyone spending time trying to re-invent the methodology in which work is accomplished.<p>Just do the work, do it well, make it measurable, and hit 80% of your aspirational goals<p>Middle management needs to find something else to do, like complain about single panes of glass and metrics
I don’t see the difference (and frankly the need for) scorecard and OKR.
I am one of these managers the majority of the comments here complain about. I lead teams and tried to implement twice OKR. Overall the idea I think is good as it makes everyone start thinking how to work with outcomes instead of objectives. The major problem is that without a good strategy doing OKRs is very difficult.<p>But back to the problem: Objectives (O) should be inspirational and Key Results (KR) are measurable outcomes.
The examples given for scorecards can very well be KRs. Instead of a weekly review we just use dashboards where everyone can see how we perform and we review OKR quarterly.
By their very nature OKRs are terrible. It’s purely for the benefit of management/executives because they’re asking rank and file employees to go above and beyond their job duty all in the name of squeezing out more performance with the same amount of resources.<p>Supposedly it’s the leadership’s job of steering the company in the right direction but in the end they throw their hands up and ask the people doing the REAL work to simply do more.
The author gets the headline right: OKRs will never be enough. You need talent. Management talent and individual contributor talent. OKRs are a communication framework. The author thinks you should communicate more detailed information than what OKRs contain by default. Seems fine, but honestly a big nothingburger.
OKRs in practice look suspiciously like waterfall software development. When you find yourself assigning ICs programming tasks by economic quarter, you've f-ed up.
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?<p>Something smells fishy.