
Why OKRs might not work at your company - codesuki
https://svpg.com/team-objectives-overview/
======
gregdoesit
This is the key of the article:

“ Those successful companies aren’t successful because they use OKR’s. They
use OKR’s because it is designed to leverage the empowered product team model.
And as I have tried to make clear with years of articles and talks, the
empowered product team model is a fundamentally different approach to building
and running a tech-product organization.”

Amen to this. Google is an example company that claims to have had great
success with OKRs. But let’s not forget that before OKRs, they had empowered
teams, a growing market which they disrupted and grew, and a unique culture.

My bet is they would have done spectacularly well without OKRs, using some
other method as well. You can’t say that OKRs caused Google to succeed, and
they certainly won’t be enough to turn a company or org around, like the
author argues.

~~~
ck425
Is Google success because it's a well run company in the first place? It's
obviously not terrible (I'd personally love to work there) but life is a lot
easier when you have the biggest cash cow ever plus a few smaller ones.

In general I'm skeptical whenever anyone wants to copy Google as their
advantages and disadvantages are so far removed from a typical company and
always were. I don't think they're a particularly good company to model for
most companies.

~~~
garyrichardson
Back when it was popular to have a flat structure or no managers or whatever I
started suggesting "Every type of management works until money gets tight." I
think the principle still applies, but a more useful/general version is pick
your structures and processes around resource availability (good vs bad
times):

Good Times: pick something that can amplify abundant resources. There is going
to be less bureaucracy around decisions and spending so move quickly and place
lots of bets while you can.

Bad Times: pick something that works with meagre resources. You're going to
spend more time justifying spending.

------
gorpomon
I've worked with OKR's at large e-commerce companies, small tech incubators,
consultancy firms and "Unicorn" stage startups. At each stop OKR's were
absolutely worthless.

What I really appreciate in reading this article is that they were absolutely
worthless for the reasons this author has stated: there was no real
empowerment behind them. Most often they were used for personal development
since I had no meaningful say in my actual work. It's always a stretch to put
personal development in terms of OKR's: "I'll write two blog posts this
quarter." "I'll run one lunch and learn"\-- ok those are fine activities but
we hardly need OKR's to grow as engineers-- and just imagine how annoying it
is to be at quarter's end struggling to write a blog post when you find out
midway that you're enjoying learning in an entirely different manner.

~~~
kmclean
This is totally my experience with OKRs as well. At my last company they were
a feeble attempt by micromanagers to manage a bunch of teams into being self-
managing. But at the end of the day they were giving us solutions not problems
to solve, which obviously didn't work out well. Most of the software we wrote
missed the mark and didn't get used.

------
polote
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 is the issue

~~~
djohnston
It's like the Martin Fowler of business organization

~~~
tempodox
I had the same thought. What good is the nicest theory when all the practical
implementations you can find basically abuse the name for something that is
quite the opposite?

[https://martinfowler.com/articles/agile-
aus-2018.html](https://martinfowler.com/articles/agile-aus-2018.html)

------
rufusroflpunch
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 their salaries to investors.

~~~
hapticmonkey
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.

------
brogrammernot
I’ve always found it shocking (well not that shocking honestly after years at
10 person startups to 5,000+ people companies) that you get these folks who
read “measure what matters” or some cherry picked Andy Grove stuff & decide
“this will fix our velocity and other problems”.

Like no, hard no. OKRs are great, I personally love them but if your company
has deeper issues a set of OKRs won’t help and likely hurt as it obfuscates
the underlying issues that exist.

~~~
chetatkinsdiet
Most times they don't even read the books. They just stop at "what doesn't get
measured doesn't happen." Great, that leads people to measure all sorts of
stupid stuff like lines of code to production. Who cares if it isn't something
that contributes to a thing that someone's going to use.

------
kmclean
> ... still continue to tell them the solutions they are supposed to deliver –
> nearly always in the form of a roadmap of features and projects with
> expected release dates.

This has always been my experience with OKRs. They were implemented by
directionless companies with weak management as an attempt to bring structure,
but the real reason there was no structure or coherence is that nobody in
leadership agreed about what the company should do.

They ended up being such vague, arbitrary, and ambiguous goals, like "dominate
this sector" or "become a leader in that vertical", or "hire x engineers by y
time" that they were effectively meaningless. What does dominate mean? What
are these new engineers going to do once they're here? Nobody had answers to
these questions, yet achieving the OKRs was paramount.

I'm sure there are examples where they work well, but I suspect this author is
onto something and the companies that use them successfully would be well
managed with or without them.

------
cmrdporcupine
Most of the teams I've been on at Google don't even bother with OKRs. The ones
that did, it was a bit of a dog and pony show, a poor substitute for just
doing some regular iteration task planning.

------
daveungerer
It _feels_ like OP has made a bit of a straw man out of OKRs. More charitably,
perhaps we did not get our information from the same place - all I know about
OKRs is from reading "Measure What Matters" and implementing it in my own
company. Reading this article makes me feel like someone took an incredibly
simple idea and decided that what it needs is more complication.

From TFA: "most companies are not set up to effectively apply this technique".
Yes. And if you read the above book, you'll learn that this is sort of the
point. You WILL fail at your first few OKR cycles, but you're supposed to use
those experiences to change your company into one that CAN set and achieve
objectives.

If you think your company is one where OKRs won't work, all the more reason to
do them.

OKRs are about creating and communicating strategic short-term objectives
across the company, so they remain top of mind. And that's 80% of what you
need to know! The objections to OKRs mentioned in the article don't make sense
to me, because it seems to follow a different definition of what OKRs are.

~~~
quadrifoliate
> all I know about OKRs is from reading "Measure What Matters" and
> implementing it in my own company. Reading this article makes me feel like
> someone took an incredibly simple idea and decided that what it needs is
> more complication.

I know this is HN and you could totally be Drew Houston; but I'm going to go
out on a limb and say that your company has fewer than 500 employees.

The problems the OP is describing are, in my opinion, usually present at a
large, bureaucratic company. There is no strict size definition for this (I've
seen incredibly bureaucratic 50-person startups), but Dunbar's number [1] is a
good rule of thumb.

> You WILL fail at your first few OKR cycles, but you're supposed to use those
> experiences to change your company into one that CAN set and achieve
> objectives.

Once you get into a bureaucratic company, it's largely about _avoiding_
failure or the perception thereof. Since you own your company, it's easy for
you to take this overall view of "if it failed, it failed". Any mid-level
manager or individual contributor is going to be incentivized to avoid the
perception of failure since it's super-bad in a large organization. Google is
often used as a counterexample, but I'm not entirely sure that Google is a
company that's good at making products. Also, Google uses the approach of
"Hire extremely smart people and throw a truckload of money at them" approach
which most companies under discussion (including yours) likely don't; which
(IMO) is a far better predictor of success than OKRs.

> The objections to OKRs mentioned in the article don't make sense to me,
> because it seems to follow a different definition of what OKRs are.

This is the No True Scotsman fallacy. The reality is that the "cascading"
nature of OKRs often gets lost in translation and doesn't take into account
macro-level changes in your specific vertical. Yes, the company's goal is to
become a leader in the field of underwater baskets; how does this translate to
me rewriting that terrible frontend code that the cofounder's buddy wrote in
2007 and has never been touched since? Doing that translation will become more
difficult year by year due to how technology evolves; and most people in
"leadership" suck at doing that translation well. That's what the article is
talking about.

[1]
[https://en.wikipedia.org/wiki/Dunbar%27s_number](https://en.wikipedia.org/wiki/Dunbar%27s_number)

~~~
daveungerer
Nowhere in the book is it pitched as a tool you roll out to a bunch of MBAs
and hope that good things happen - it's never about out-of-touch managers
demanding results. If someone cascades objectives without also cascading
planning and estimation, are they not simply a bad manager?

What the book DOES say is that you should not create such a fear of failure
that no-one will set stretch goals, and that OKR results should not replace
individual performance evaluations. In short, OKRs are what you seem to think
they are, plus the culture that makes it possible. If an organisation doesn't
get that right, are they doing OKRs?

If your organisation does not allow developers to push back against impossible
objectives, do you not perhaps have bigger problems that OKRs (or any other
system) can't fix for you? Why would you blame OKRs - would any other system
not also be painful when a company has become so dysfunctional? Also, did you
know that all objectives don't need to cascade - some can be set bottom-up?

You're going to call No True Scotsman fallacy, and I'm going to call Straw
Man, so I'm done with this thread. Perhaps I just fell for John Doerr's
elaborately constructed fantasy that he uses to sell books. But right now it
seems like a useful tool to keep a company on track, and I'll keep adapting it
as the company grows.

~~~
athenot
I'll add to this thread that I was largely against OKRs, having seen them
implemented in the style of "we need a quantitative measurement for success so
let's make something up hastily", only to fall prey to Goodhart's Law[1].

But John Doerr's book introduced me to the bridge of concepts that I was not
seeing: in a healthy setup, we are first and foremost focused on a
_qualitative_ objectives and THEN we attempt to model that fuzzy feeling with
a _quantitative_ measure (the "key result") that should reflect success. It
takes several iterations in order to come up with a matching measurement, and
even then we need to constantly re-evaluate whether the measurement is
appropriate or if is devolving into a numbers game devoid of true objective.

In other words the full acronym is OAMBKY, or "Objectives, AS MEASURED BY Key
Results". But that doesn't roll off the tongue quite as well.

So in that light, OKRs are a useful tool IF AND ONLY IF leadership—as well as
the whole team—are focused on the philosophical, qualitative goal and are all
aware that the measurement is only an imperfect proxy that is contantly re-
evaluated to help us better assess the goal; not a goal unto itself. But that
takes real leadership to drive that message (as well as avoiding setting up
misguided incentives).

[1] When a measure becomes a target, it ceases to be a good measure.

------
habitue
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.

~~~
irjustin
I'm trying to grasp what's wrong with that. That statement is true for every
set of system/values.

A set of systems won't work for 100% of the cases because that system was
designed around a particular team. And there are times it won't work well.

Whether the system is good/effective has nothing to do with "you aren't doing
it right" part.

The "you aren't doing it right" can be applied to literally everything.

~~~
habitue
The common thread is that they're frameworks which promise to be very general
and be applicable everywhere, but which in practice "everyone does wrong".

If no one can actually successfully use your framework the right way, maybe
the framework isn't as generally useful as it purports to be.

~~~
irjustin
Ah got it.

Having gone through scrum and OKRs I agree with the idea that people tend to
sell them to be 'generally' useful at least on the surface.

But once we started doing training/testing towards scrum, it's very clear we
needed change as an organization. Some people ended up leaving as a result
because it's not everyone's cup of tea.

I can't say the same for OKRs because I joined and it was already in place
pretty effectively, but I imagine it to be similar.

------
crooked-v
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.

~~~
xtracto
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.

~~~
the_other
> 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

How could it be any other way (and work)?

~~~
xtracto
It doesn't, but it is still done. A friend of mine who worked at IBM told me
that they had "quarterly goals" that were stuff like "learn a new language" or
"improve testing" or any other utopian idea, but their week-to-week sprint
stories were completely perpendicular, so at the end of the quarter during the
performance review the only people that achieved some of their goals were the
ones that stayed to work on evenings and weekends (extra time) to do something
related to their goals.

------
trwhite
My CEO tried to explain to me that the "key result" part of OKRs didn't need
to be measurable and then cited my colleague's as better examples despite none
of them having written anything that could be used to hold them accountable.
When I ask him if he's read High Output Management he just says "It's on my
reading list". I'm leaving soon.

~~~
andrewingram
I've definitely seen it where objectives don't need to be measurable, but the
results are what you measure to let you know if you're going in the right
direction. Sometimes you might have objectives that look like results (like a
top-line revenue target), but yeah... Good luck :)

------
rukuu001
We just started using them.

We're a small org that's mostly experienced consultants and contractors.
They're energetic, proactive and independent people.

We've adopted OKRs to basically get everyone pulling in the same direction,
but without being prescriptive about how the work gets done.

I'll report back at the end of the quarter on how it's working out, if
anyone's interested :)

~~~
adamsvystun
I am totally interested! But how will you report back?

~~~
rukuu001
I’ll reply here!

------
akmarinov
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.

~~~
scaryclam
"teaching all devs on how to do devops within 2 months, so they can be self
sufficient"

There's so much wrong with this key result it's incredible :( One big reason
that OKRs can fail is just flat out bad OKRs. Teaching all devs to do "devops"
within two months ignores the actual issue that they seem to be trying to
solve (which I'm guessing is that not having sufficient ops is hurting the
company and velocity). It's far too easy to fail and puts pressure on
individuals rather than letting the team find the right solution.

~~~
the_other
This has flicked a lightbulb on for me.

If your teams are fairly self-organising, if you are small-a agile and
building your process as you discover more, you can plan in things like “dev A
will spend 50% of this sprint learning dev-ops, without doing feature work or
tech debt; and 10% shadowing dev B who already does Ops”.

That seems actionable, and measurable. Over two or three
sprints/iterations/retrospectives, you’ll probably be able to measure the
impact of the training (more successful releases, higher uptime, or more story
points covered because ops is less a bottleneck etc).

------
Marazan
OKRs seem a brilliant way to silo your teams and shut down any cross team
collaboration.

OKRs become a shield to deflect any external request that doesn't precisely
align with a measure.

Not a fan.

~~~
GauntletWizard
I'm certain you've got experience to back up this view of them, but you should
consider that it's not a failure of OKRs, but of management setting OKRs, that
what your teams OKRs weren't aligned with other teams. I've had similar
experiences, but I've also had explicitly cross-team OKRs and OKRS that were
broadly set on "Respond to needs of customer teams X, Y, and Z" that were
among the most successful that I or others on my team picked up.

Collaboration should be a goal. A management structure that doesn't explicitly
make it one is at fault, and they would have failed regardless of the
organizational methodology they chose.

~~~
Marazan
In my experience that still just pushes off the problem one layer. Now you've
defined who the team can and can't interact with to an even greater degree
than not having anything and it totally kills 'spontaneous' collaboration.

I am absolutely no rejecting the notion that maybe my company is very bad at
doing OKRs but for me they have always resulted in "working to the metric" and
have totally inhibit team autonomy - you become ruler by the KRs.

EDIT: the first time my company tried OKRs a company culture of collaboration
and experimentation was brought to a shuddering halt as everyone stopped
trying to do what was best for the business and started trying to hit their
OKRs instead.

------
peignoir
OKRs are just a tool, but having been the founder of many startups, comes a
moment when you need a tool to align your team towards a clear goal.

I understand most of the comments but as you grow your startup will come a
time when it becomes useful when you have 70+ and even more thousands of
employees. The bigger the company the harder it is to manage, google famously
hated management and ended up with OKRs. My understanding from a couple of ex-
googlers is that now most people are just gaming the system and aiming at a
0.7 score so I'm not sure if they are still as useful as they were at google.

OKRs / KPI etc are not magic, at the end of the day the article is right, the
team is what matters, how teams align and communicate with each other is what
OKRs can help with (I find them better than the old top down KPIs personally)
I was asked by a startup to explain OKRs and I kept getting the CEO to ask me
questions related to them not making sense (e.g some teams argued that goal X
did not make sense to them etc...) For me this was not an issue with the OKRs
per se, but OKRs helped to show very clearly that the organization was not
well structured for the general goals, so worst case if OKRs don't work you
should be able to tweak things and measure the impact (that's the all idea :
measuring to improve)

------
dboreham
Tell people what's important and what isn't. How innovative. OKRs are for
managers who are incapable of telling their staff what's important.

~~~
chetatkinsdiet
Easy enough in a small org, much more difficult in a big org. Part of the
point of OKRs, when done right, are that it shows how the thing you're working
on today ladders up to the big thing that drives the entire company forward.
That said, in reality it's rarely executed well or with any precision
whatsoever. I worked at a 1000 person place whose top level OKRs were so vague
they were garbage. You could have created any feature whatsoever and shoed it
into those.

------
keeptrying
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).

~~~
codemac
Considering High Output Management literally advertises Management By
Objectives, I'm confused how that is a citation for your point about KPIs vs
OKRs, they should not look that different.

If you're doing OKRs without some type of indicator, kpi or otherwise, I don't
see how you're achieving key results.

------
jldugger
> The Role of Leadership > And finally, and really the root of the problem, is
> that in the vast majority of companies I see that are struggling to get any
> value out of OKR’s, the role of leadership is largely missing in action.

Here, here!

OKRs are being rolled out at work, and there's a pretty clear managerial
vacuum. You could call it the KRO: leadership makes a request that trickles
down to line staff for projects and goals, then each layer of management tries
to glue them into a coherent Objective.

------
bb88
> 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.

~~~
CoolGuySteve
You will enjoy your career much more if you quit it with this inverse Lake
Woebegone philosophy.

The idea that all engineers outside of a few Silicon Valley companies are
mediocre is laughable if you've ever worked at a FAANG. People pick all sorts
of jobs for all sorts of reasons.

------
geebee
I personally like OKRs, as I find them a valuable counterbalance to 1) daily
standup, which can promote short term thinking, and 2) yearly "goals" in
performance reviews, which, when evaluated in a binary way as completed/not
completed, can deter people from taking on more ambitious and ambiguous tasks.

My big worry about OKRs is that they will descend into the same shitstorm that
ruined SCRUM. Daily standups were never intended to turn into a daily
opportunity for micromanagement and application of deadline pressure, but this
is exactly what they became. And I can't say it was an external corruption of
the process - the dangers are inherent to the technique. I always felt that
saying standup and scrum are good, you just have to be careful someone
external to the process doesn't corrupt it don't turn into micromanagement is
like saying nitroglycerine is good, you just have to be careful some chemical
reaction external to the process doesn't cause it to suddenly and
unpredictably combust. The instability is inherent to the substance.

There was also a mini (or not so mini) industry of industry consultants
helping people "do agile", that elevated "processes and tools" over
"individuals and interactions", kind of how the 10 animal commandments in
animal farm ended amended to mean the opposite of how they were written down.

I see a danger in point in OKRs, in that they're a great way for a manager to
turn a casual projection into a committed estimate. I see the inversion of
"Customer collaboration over contract negotiation" all over again here. The
developer (or employee) is lulled into a belief that we're all friends and can
trust each other, the "customer" (or client or boss) is lawyering up with a
contract, and when time comes, the developer's feet will be held to the fire
with firm commitments, and subjected to daily deadline pressure and
micromanagement (because agile).

All I'm sayin' is, this could go sideways. But then again, so can any job.

------
pitayan
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.

~~~
jldugger
> 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 of improving KPIs by recursively
breaking work up into subtasks.

~~~
pitayan
> 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
date time as a target.

I just guess that iterating the OKR every week and month is quite challenging.
And most of the OKR stays unchanged even after months of iterations. HR and
managers need to figure out the way to keep everyone update their OKR
effectively.

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

------
Mindwipe
Good piece

I worked at a company that used OKRs but the teams weren't set up in a way
that people had responsibility for the things that their OKRs wanted them to
do, and it produced very little (thankfully the teams were generally good and
it wasn't a disaster, but it was a waste of effort).

If the OKRs aren't embedded into the sales teams as well (which basically
means you can't have separate sales teams) then it likely fails.

------
sfgweilr4f
OKRs?

Quote: "OKR’s are first and foremost an empowerment technique."

Don't empower anyone. Instead work on getting rid of / minimizing / improve on
anything that dis-empowers. This is usually easier, cheaper and far more
straightforward. Not always easy to get rid of disempowerment but you can at
least put things in place to minimize it. Empowerment is barely measurable in
real terms. All the metrics are indirect. Even turnover doesn't accurately
measure it. Dis-empowerment on the other hand is a stinking mess. Follow your
nose. Or your heart.

Quote: "Manager’s Objectives vs. Product Team Objectives"

One of these needs to be fired / removed / re-evaluated. If the manager is
fighting the team then who's more in alignment with the overall vision? Why
would you tolerate a manager that is fighting their team? Or vice versa? If
the team members are across leaders and there's issues then there's some
misalignment that needs to be fixed. Now. Iceberg! Change direction or sink!

Pointless drama and deliberate friction created in large organizations is why
they squash innovation. Its why they do mindbogglingly stupid things. Its also
why a manager or executive can benefit when a team fails, even their own.
Incentives can be so screwed up that if a division fails, a number of people
in the division cheer because their individual incentives are all green. This
is too common.

Another quote: "The main idea is to give product teams real problems to solve"

You're doing WHAT?! How can you possibly tolerate non-real problems? Why would
this be even necessary? That's like saying, "it gives them a way to generate
profit". Really? That's a thing you're going to add?! As if its some new
thing? What?!

Quote: "Passive manager"

What is this creature? How can you passively manage anything? Not even drunk
people are passive. Only when they become unconscious do you start to have
passivity. I've met managers who's teams zip along with the manager gone for a
month. This isn't rare and its still not passive if adult supervision is in
place. Why? Because an active manager puts processes in place to monitor and
optimise what is going on. This is active management.

Quote: "Stop doing manager objectives and individual objectives"

Correct. Any mismatch means pointless friction. Why was this tolerated?
Perhaps because drama at the bottom and middle keeps people too busy to notice
the silliness at the top? Maybe. Regardless, it sounds expensive: How's that
productivity going?

Quote: "Leaders need to step up"

Sure, and they should be allowed to lead. Which is often NOT the case. Plenty
of managers leave team leaders in the dark about key aspects about what is
going on and what is planned. Leading means choosing a direction. How can you
know the direction to choose if you don't know the destination? This applies
generally as well. Instead of expecting leaders to step up, why is there a
step in the first place? Shouldn't there be a level playing field? Sort out
organisational mess so its as level as possible - remember the bit about
removing disempowerment? I wasn't kidding. Here's a symptom: the need to step
up when no step should exist.

Ugh!

Go for enabling and self-directed team members that can tolerate and operate
successfully with adult supervision. This kind of supervision requires
managers, directors and team leaders as well.

One last thing: Get rid of deadlines and use due-dates instead. Not just
wordplay. We need to be using project X on date Y. Make it happen and don't
drop dead doing so. Change the mindset to fit this approach. Those deadline
crunches? Not good. Dropping dead after a due-date means something went very
wrong. Everything must be re-examined to avoid it in future. The mess has to
be cleaned up. Supports put in place. Additional followups scheduled and kept.
This works for projects as well as childbirth.

Ok. I feel decaffeinated and that is dis-empowering. Time for coffee. See?
Fixable.

------
tomrod
Agree that the method is not guaranteed to be a success-maker. Our experience
adopting in a small healthcare thinktank was difficult -- the pattern didn't
really fit our present and future workflows very well.

------
hedora
> _Please upgrade to a supported browser to get a reCAPTCHA challenge.

Why is this happening to me?_

I see this at the bottom of the page, and I’ve been seeing it more and more.
I’m using the Duck Duck Go browser on iOS.

~~~
markalexander
An educated guess: reCAPTCHA has become (partly) passive, using whatever
tracking data Google has about your behaviour. So, if your browser blocks the
tracking, it causes issues. I assume that's what the DDG browser is about.

------
jacques_chester
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 energetic in enforcing a numerical management scheme,
the Customer is at first better served and then served much worse.

As a side effect he recreates or overlaps with the "Equal Compensation
Principle" (described in Milgrom & Roberts' _Economics, Organization and
Management_ ). Put briefly: give a rational agent more than one thing to do,
and they will _only_ do the _most_ profitable thing for them to do. To avoid
this problem you need perfectly equal compensation of their alternatives, but
that's flawed too, because you rarely want an agent to divide their time
exactly into equal shares.

Then there's the annoyance that most goals set are just made the hell up. Just
yanked out from an unwilling fundament. Which means you're not planning,
you're not objective, you're not creating comparative measurement. It's a
lottery ticket with delusions of grandeur. In Wheeler & Chambers'
_Understanding Statistical Process Control_ , the authors emphasise that you
cannot improve a process that you have not first _measured_ and then
_stablised_. If you don't have a baseline, you can't measure changes. If it's
not a stable process, you can't tell if changes are meaningful or just noise.
As they put it, more pithily:

> _This is why it is futile to try and set a goal on an unstable process --
> one cannot know what it can do. Likewise it is futile to set a goal for a
> stable process -- it is already doing all that it can do! The setting of
> goals by managers is usually a way of passing the buck when they don 't know
> how to change things._

That last sentence summarises pretty much how I feel about my strawperson
impressions of OKRs.

[0] [https://www.amazon.com/Measuring-Managing-Performance-
Organi...](https://www.amazon.com/Measuring-Managing-Performance-
Organizations-Robert/dp/0932633366)

[1] [https://www.amazon.com/Economics-Organization-Management-
Pau...](https://www.amazon.com/Economics-Organization-Management-Paul-
Milgrom/dp/0132246503)

[2] [https://www.amazon.com/Understanding-Statistical-Process-
Con...](https://www.amazon.com/Understanding-Statistical-Process-Control-
Wheeler/dp/0945320698), though I prefer Montgomery's _Introduction to
Statistical Quality Control_ as a much broader introduction with less of an
old-man-yells-at-cloud vibe -- [https://www.amazon.com/Introduction-
Statistical-Quality-Cont...](https://www.amazon.com/Introduction-Statistical-
Quality-Control-Montgomery/dp/1119657113/)

~~~
jldugger
> Put briefly: give a rational agent more than one thing to do, and they will
> only do the most profitable thing for them to do. To avoid this problem you
> need perfectly equal compensation of their alternatives, but that's flawed
> too, because you rarely want an agent to divide their time exactly into
> equal shares.

I would argue the system is working as intended. Contrary to your assertions,
you don't want employees spreading effort like peanut butter, you want to
focus them on executing one or two things quickly and getting value out of
that quickly. Instead of launching 12 features a year from now, I'd rather
launch 1 feature a month.

> you cannot improve a process that you have not first measured and then
> stablised.

There is of course, a certain amount of reasoning under uncertainty involved.
One of the lessons many folks learn from a/b testing and OKRs is just how hard
it is to actually make a difference, and folks need practice calibrating.

~~~
jacques_chester
> _Contrary to your assertions, you don 't want employees spreading effort
> like peanut butter, you want to focus them on executing one or two things
> quickly and getting value out of that quickly._

That's not quite what I was driving at. Optimisation is made on the
_measurement_. Measurement is only necessary because the Agent is not
perfectly observable, there is an information asymmetry between Principal and
Agent.

That's why Austin's model is so helpful. There are many things that must be
done in order to best satisfy the Customer. Some of those are measurable, some
are less measurable. But a rational Agent looks at any basket of measurements
and will optimise for _one_ of them: the one that pays best.

It's not enough to say "just this _one_ feature and no peanut butter please".
You have to define what the one feature is. You have to provide an exact
measure for it. Agents can then either optimise honestly, or they can go
further and optimise fraudulently. If honestly, the Principal realises that
they actually need a basket of values to be optimised. But then they need to
apply equal compensation, because the Agent will simply ignore any measurement
that doesn't maximise their results.

I believe measurement is useful. But I also believe that connecting it to even
the whiff of reward or punishment is beyond merely futile and well into being
destructive.

------
tomjen3
Objectives and Key Results for those who are confused.

------
aey
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.

~~~
leetrout
What is BD, OR and PMF?

~~~
bretpiatt
BD = Business Development, aka sales

PMF = Product Market Fit

Unsure on the OR.

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

~~~
aey
(BD -> Eng Stress) ^ pre PMF

------
andrewla
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.

~~~
djohnston
Its a 2 minute read, go see for yourself

