
OKRs Aren't Going to Fix Your Communication Issues - saisrirampur
http://www.craigkerstiens.com/2019/03/29/okrs-arent-going-to-fix-your-communication/
======
spydum
Incase others like me don’t know - OKR is Objectives and Key Results.
[https://en.wikipedia.org/wiki/OKR](https://en.wikipedia.org/wiki/OKR)

I honestly have never seen that acronym but apparently popular from Intel
management practices?

~~~
mattnewport
I hate it when people use TLAs without defining them.

~~~
netsharc
I added "what_the_fuck_are_okrs_craig" to the end of the URL in the hopes he
gets the message when he looks in his 404 logs...

~~~
majewsky
Are there people who do this?

~~~
netsharc
Admittedly I'm grumpy today. I sometimes do this "404 trolling" to yell at
people.

~~~
Quarrelsome
the knowledge of this has made me happy. :)

Thanks.

------
msluyter
I've only experienced OKRs at one company, and I felt a sort of a weird
disconnect between OKRs and actual work/performance. On the one hand, OKRs
were presumably critically important, but on the other, they weren't directly
tied to individual performance. I still have trouble wrapping my head around
that.

And I found those ratings (0, .4, .7, 1.0 for hitting a stretch goal) just a
sort of weird self delusion, like setting your watch 15 minutes early to
ensure you'll be on time. You can fool yourself a little, but eventually it
stops working, and so, for example, .7 become the de facto "real" target.

Secondarily, I found that as a team lead, to the extent that OKRs were
stressed, any non-OKR related work became highly disincentivized. Refactor?
Write more integration tests? Hell no, not if it doesn't directly impact OKRs.
We had stories in the backlog that really _should_ have been done because they
would have helped other teams and yielded a positive return, but anything non-
OKR was just dropped on the floor.

Third, they didn't really provide any value to the team that I could discern.
We didn't have to look at our objectives every day to know what to do. We had
typical releases/epics, etc... to do, and on a day to day basis, the OKRs just
receded into the background. In theory, I assume that the OKRs are there to
guide which releases/epics/stories, etc... you do, but in our case, we had a
pretty clearly defined product already prior to introduction of OKRs. So the
OKRs were all just sorta "OK, finish this thing we're already working on."

That said, the company was new to them and in the process of learning. Perhaps
we did them wrong, or perhaps I missed the point.

~~~
sockgrant
Why didn’t you make OKRs out of refactoring, integration tests, etc.?

~~~
sanderjd
IMO, it is difficult to write an OKR for this sort of work that is focused on
measurable impact.

"Write an integration test for xyz" is not really what OKRs are designed for.
You can do that (and lots of people do), but it tends to be frowned on. The
reason for this is that it's not clear how it rolls up into the larger company
OKRs. Where does "wrote integration test for xyz" fit into the company's
"increase monthly active users by x%" KR?

I think the general trickiness is that OKRs are inherently backward-looking. A
lot of technical improvements have to do with risk mitigation. The risk of
nasty bugs (testing), the risk of future functionality being slow to develop
because of poor architecture (refactoring), etc. But it isn't clear (to me)
how to write OKRs for mitigating future risks.

~~~
NSSec
| "Write an integration test for xyz" is not really what OKRs are designed
for.

This gets it backwards. This is a task. Why are you performing this task?
Especially without being tied to specific development? If you can't justify
doing it with your/teams/companies stated OKRs, you actually shouldn't be
doing it. Even if you feel you should because 'its the right thing'. Even
looking at it this way gets it backward.

You should be looking at your OKRs and figuring out what you should do to get
there. But, you might have to break it down a little further.

Indeed, a KR of 'increase monthly active users by x%' is not directly
actionable by an engineer. But an engineering department can come up with its
own OKRs that fit in that direction.

For instance, to achieve that goal it might be necessary to develop new
features. However, if 70% of the engineering time is spent in bug-fixing then
they're not going to be able to do that. (Do you know where your team spends
its time? That might be worthwhile to figure out).

So, an objective of 'Increase development time for features' (or some such)
might be considered. If you find you're dealing with a lot of bugs, one of the
key results might be to reduce bugreports by 50%. To do that you might argue
that you should add some integration tests so that you can change code and
catch issues before they get to production so that in the future you'll be
spending less time on bugfixing / rework, so that you can work on new features
that will entice new users to full fill the company objective.

~~~
colechristensen
How do you measure the impact of rare but very expensive flaws without
inventing phony metrics to pretend to fit the tasks you think need doing?

"Don't have a catastrophic data breach"

There isn't a middle ground where there is a linear correlation between a
serious compound failure and fixing bugs or writing tests.

You could come up with a methodology for a "security score" and track that.
However it is both a transparent workaround for having specific bugs / tasks
in OKRs and it is likely that your invented metric will be bogus and will lead
you to do irrational things.

~~~
NSSec
IMO, you don't. Operational security isn't (or shouldnt be :)) a specific _
business goal_ for a company. With that I mean it's not a specific objective
to achieve: it should be a _base principle_ that should be part of your
engineering (and operating) principles that you apply to do anything.

Put differently: you have a way of working that includes applying measures for
security. For instance, you might do threat modeling at an early stage of your
project/iteration. Those sessions may result in concrete work to perform. You
might also perform a security test at the end of an iteration that confirms
things have been covered. That adds to your workload and affects your ability
to achieve goals in a certain way. You apply this way of working to move
toward a goal.

So, over time, you will find out that applying these principles have a certain
outcome. It may be positive: "we're not seeing security issues and development
pace is OK" and it might be negative ("security tests are coming back bad",
"we're hacked" or "development pace is snail-like"). When it's negative, that
means you have to do things that will slow down achieving your goals.

That kind of negative feedback should lead to a poor(er) performance score on
the KR when reviewing them. It's this kind of feedback that should factor back
into your decisions moving forward to achieve the goal. In this example, if
you have negative findings, you might choose to educate engineers on security
matters, streamline your engineering principles, increase the team size and/or
even replace people.

~~~
andrewflnr
If you put off security work until "we're hacked!", it's too damn late. You
can't bolt on security after the fact. Similar for testing, refactoring, etc.
Your approach here is a recipe for putting off important work until it's too
expensive or flat out too late.

~~~
NSSec
I agree. I shouldn't have added 'were hacked'. It distracts from what I'm
trying to say. Your conclusion that I'm saying is a recipe for putting off
work is exactly opposite of what I'm trying to say.

My point was that you should have a certain set of sane engineering principles
(security being one area they should cover). They should be sufficient to
todays standards. These principles are not/should not be business goals: they
are tools in achieving goals in a responsible and reproducible way.

I am also saying that if you get feedback that these principles are keeping
you from you should include them your evaluation in determining next steps to
move forward without dictating a specific manner of how you should deal with
them; that's up to the specific situation at hand.

------
killjoywashere
When I took over at my new lab, 40 FTEs, I implemented OKRs, just between my
direct reports and I. It quickly became apparent who gets shit done and who
doesn't. It also became apparent how overloaded some folks were. How little
some understand their jobs. It helped me see what I needed to focus on and
what I needed the lab to focus on.

I am also in a massive, MASSIVE, organization with literally acres of people
dedicated to formal communication processes. I submit that OKRs were handy
because they forced formal communication that revealed problems outside the
official formal methods. It's a hack. And in the realm of formal comms, it's a
particularly low-friction, low-cost-of-adoption hack.

10/10 will use again.

~~~
pishpash
As suspected it's useful only to the higher-ups and specifically to manage
drones who need military discipline, same as scrum.

If it has an acronym it's useless to functioning contributors. The original
purpose has disappeared with the name.

~~~
asdfasgasdgasdg
Everybody's acting like OKRs are this enormous heavyweight process. Why? You
just write down what you're planning on doing this quarter in a prioritized
list. The purpose is to broadcast your view of your priorities, so interested
parties can ask that they be adjusted. At the end of the quarter you look back
and review what you actually accomplished. It's really not that big of a deal.

The process gets heavier at the level where OKRs are getting aggregated across
multiple teams, or teams of teams, but that's a cost paid by managers, not by
"drones," so I don't see why line employees should be concerned with it.

FWIW I spend about four to six hours a year thinking about OKRs, and that's
assuming I'm paying attention for the entire OKR team meeting (fat chance).

~~~
falsedan
> _four to six hours a year thinking about OKRs_

As a non-IC, I'd spend that much time per week on OKRs: writing the OKRs for a
team involved planning out the next quarter's topics, which required aligning
the team (with individual meetings & group ones) for the 2-3 weeks at the end
of the quarter. Then drafting them, aligning with the department/VP's topics
for the quarter, finishing them, getting feedback from other team leads, dry-
run presentation for the dev manager meeting, then live run-through for the
department all-hands, mid-point scoring updates, end-of-quarter scoring, back
to the beginning

------
xiphias2
,,OKRs present a heavy-weight answer to the problem. OKRs tend to require
hours and maybe even days to determine what are the right goals and metrics.
''

If a team leader doesn't have a few days to decide on the strategy for the
team for the next quarter, I have no idea what more important thing she is
doing.

John Doerr wrote the great book about OKRs to explain how important they were
in setting the strategy for Intel when it went out of the memory business and
focused just on processors: achieving that in 1 quarter is only possible with
very clear communication.

If it's not rare enough (quaterly or yearly) or not short enough (few items),
it doesn't work, it's just a wish list. I have seen them working and not
working (when the whole team knew that doing all the strech goals were
impossible).

~~~
jldugger
> If a team leader doesn't have a few days to decide on the strategy for the
> team for the next quarter, I have no idea what more important thing she is
> doing

Typically, focusing the team on the strategy for the next 24 hours.

~~~
count
That sounds like leading by micromanaging...

~~~
mr-ron
Depends if the leader is in the weeds contributing or not.

My experience with quarterly goals at an early startup was that it made an
artifact for what was most important at that given moment. Only later we're we
able to prioritize a quarter ahead

~~~
xiphias2
For a startup an example objective would be an MVP launch and a key result
would be an MVP being tried out by 10 people in a coffee shop, or getting 100
views from various blog posts. Something like this would set an expectation
for the whole team (sales, marketing, engineering...) for the quarter. It
shouldn't be complex, but it has to be something well thought out and serious.

I would get crazy if I would get a new strategy every 24 hours. The details of
the execution can change, but the objective and the key results shouldn't
change that often.

------
eismcc
Despite the name and intention, in my experience, OKRs is a prime candidate
for cargo culting culture into an org and using process as a proxy for actual
focus on outcomes.

~~~
mlthoughts2018
I agree. That’s the only type of use of OKRs I’ve ever seen or heard of,
across several jobs and big, small, young and old companies.

People who get shit done do so _in spite of_ OKRs or other formalisms like
Agile. OKRs do not help orient work towards what matters, maintain
accountability, alert management to schedule slippage, or unify team efforts.
OKRs are cargo cult metrics for middle management to bend the ear of higher
management to argue and gladhand for bonuses & promotions.

~~~
Jtsummers
When you say Agile is a formalism, you mean Agile with a big-A? Like the very
formal approaches to Scrum or SAFe?

Because outside of those, agile is actually the anti-formalism. It's a whole
slew of tools, techniques, methods, and philosophies to choose from for your
team and organization. Offices that formalize it are the same ones that'd
formalize Waterfall or Vee model or Rational Unified Process or any other
approach. And they'll suffer the same consequences regardless of which one
they use.

Offices that understand it as a toolkit can actually get value from it (AKA,
those who read and internalized the initial manifesto and mostly avoided the
consultancies that came out after).

~~~
mlthoughts2018
In theory I’d agree, but in practice agile is _always_ just a source of
metrics so that middle managers can create Dutch Books out of project
outcomes.

I read a good way of putting it once, “when everyone misuses a tool, beyond a
certain point, it’s the tool’s fault.” I think this fits the realities of
agile well.

Separately a lot of people will look at this or that pathological issue in
agile and say that’s not “real” agile, ignoring that this is just a No True
Scotsman fallacy by which you’d vacuously define agile as “all good things” or
something.

The main pathology I’ve seen in agile (across half a dozen companies, large &
small, with or without formal agile training, etc.) is that it is
paradoxically highly inflexible. If certain research tasks need to be a 4-week
deep dive that cannot be chopped up into separate tickets on a sprint cadence
and cannot be time-boxed, there’s no way to handle it (this happens all the
time on research teams).

If one team needs to work on a 3-week cycle all summer instead of the company-
wide 2-week cycle, it can’t be done. If there is no way to estimate some
points for a certain task, you still are forced to go through the motions and
fabricate misleading numbers anyway.

Even the core agile manifesto has to be ignored sometimes. Sometimes sticking
to the plan actually is more important than responding to change, and you have
to turn down business or tell customers no even if it costs you.

Agile can be used well. It’s just exceedingly rare that it is, to such a
degree that we need to admit something’s wrong with agile itself given how
easy it is to subvert agile into a bad system.

At this point a lot of people reply by saying, well what alternative is there?
I don’t like this because it presumes there has to exist some named
alternative that doesn’t suffer agile’s limitations, but no such official
method has to exist and that doesn’t mean agile should be used.

Instead, just use some mixture of common sense and planning based on the
specific personnel working on the project, their preferences and styles, and
randomly stealing things from agile or waterfall or whatever else on an as-
needed bases. Don’t give it a name.

------
jSully24
Good people make any process look good.

No matter how amazing the process is, without good people, you’ll fail.

I like OKRs, but I benefit from being with smart people.

------
dboreham
One way to think about this stuff is to ask : "Do lawyers and accountants and
doctors and playwrights and mathematicians have these kind of schemes?".
Answer: probably not. They're handy for some jobs but not others. FWIW this
kind of oddness has been going on since I entered the workforce in 1986.
BS5750, ISO9001, TQM, KPI, and on. Part of the landscape and not really worth
getting too excited about.

~~~
eismcc
Good point. Thinking about this more, I’m wondering if OKRs are just s
byproduct of abstraction. Management needs to feel like they have a way to
have “traction” on things they don’t actually have any real understanding of -
eg the code. Similar to how devs think java is what the processor actually
does.

------
greatlakes
We just got done with trying OKRs for a quarter at my company. It was overall
a really positive experience. We had a small team of people working to push
out a new product. At the beginning of the quarter, we defined what success
looked like for that new product and came up with the key indicators for it.
As a developer, it was really fulfilling to take time to really think through
what it would take to build out a truly quality product. I spent a lot more
time thinking through the things I normally wouldn't put much effort into. We
built tools to help our support team understand the new product. We put
together documentation. We took time to think about how to train the company
on the new product. We wrote automated tests to make sure that we could sell
the new product as a stable solution. Everything was focused on our overall
objective to deliver a quality product. Our team had people from development,
marketing, sales, product, and quality assurance. It was great to see a cross-
department team unified to get something amazing done. Just adding a data
point that there are ways to make it work well.

------
jpm_sd
One way in which I've seen OKRs used effectively is as a defense against the
type of middle or upper manager who is constantly coming up with new ideas or
tasks. But what if we did $shiny_thing!? Sorry, that's not in our OKRs this
quarter, let's have a meeting to plan for next quarter.

~~~
1123581321
It acts as a defense in both directions, too, since the manager’s boss will
want the manager to stick to objectives that fit with the manager’s boss’
OKRs.

------
bitL
OKR and other management frameworks work well in environments that would
perform well even without them (self-organizing, enthusiastic, competent, non-
threating and driven employees). Having just the structure in place wouldn't
guarantee much. Google's success using OKRs was a side effect of their past
employee composition and the fact it got least in the way of them to do great
things.

------
thinkingkong
This is good. Ive found communicating OKRs steadily on a cadence (weekly) as
well as show the team the progress towards a goal at an all hands to be
effective. Its rare for someone to miss _all_ the all hands meetings.

Commms, progress, priorities, from a company down to tactical execution level
are easy but require discipline.

------
honkycat
People moan on and on about OKRs, but I am a developer and I honestly like
them.

Personally: I do not resent that management wants to know what I am up to. And
it is helpful for me to be working on projects in such a way that I understand
their greater context.

------
ryanmarsh
They also won’t fix leadership’s lack of vision, ability to focus, and
courage.

------
jondubois
It's strange because the company I work for just started implementing OKRs
last week. It actually happens creepily often when I do something and then
some related article pops up on HN a some weeks later. I do read HN everyday
though but still.

I guess it shows that we severely lack creativity and are all being
manipulated.

Personally I don't think OKRs add any value because they force us to focus on
measurable results at the expense of unmeasurable results which might actually
be more important.

~~~
layoutIfNeeded
>It actually happens creepily often when I do something and then some related
article pops up on HN a some weeks later.

[https://en.wikipedia.org/wiki/Baader–Meinhof_effect](https://en.wikipedia.org/wiki/Baader–Meinhof_effect)

------
omeid2
What is an OKR? Whatever it is, clearly didn't help the author to communicate
clearly. ;)

------
Simple_Guy
Here's a step to fix your communication issue. Don't assume people know what
OKR is, and explain it briefly at the start of your article about OKRs.

------
empath75
I have never been involved in an okr system that wasn’t an utterly pointless
waste of time that no one but hr and back office people took seriously.

~~~
dpflan
What was a common theme among all the systems that you think contributed to
their pointlessness?

~~~
patejam
We do quarterly OKRs. Quarterly deadlines are completely arbitrary and my
actual deadlines aren't tied to the quarters.

So I (and everyone around me) don't take them seriously. We take the actual
deadlines seriously. The only thing OKRs seem to do is provide direction to
the higher ups about what my team is up to.

~~~
6nf
Yes so you have no actual incentive to focus on OKRs. You're doing the work
required to keep the company running but the quarter's OKR goals only gets
attention if you think it will help your actual job. Is that what you mean?

------
minipci1321
Using email efficiently requires training and discipline, being able to:

\-- at a quick glance, quickly "triage" big lists of unread messages, not be
put off by several hundreds messages and grab the phone

\-- reply shortly and to the point (being native to the culture and language
helps but is not a given anymore)

\-- master art of attracting attention of very busy people of various kinds,
to get them open at least the email and read some

\-- not to turn email into slack in disguise, check if the question already
has answer available somewhere else, and not become nervous if the other side
doesn't reply in a second

\-- master email client sufficiently to configure pre-sorting messages, and
trust it's action

I'd say environment where email works as a reliable channel for top-importance
communication (such as goals and prios), probably already doesn't need OKRs.

------
acdha
Jacob Kaplan-Moss had some practical advice in response to this post which I
found interesting:

[https://jacobian.org/2019/apr/1/talk-about-
performance/](https://jacobian.org/2019/apr/1/talk-about-performance/)

------
idcrosby
The point he makes is that OKRs (alone) aren't going to save you. The same way
any technology or trend (Scrum, Docker, latest JS library...) isn't going to
fix your problems. You must change your process/culture along with it.

We took on OKRs a while back, and have created a process around it -
[https://info.container-solutions.com/hermes-container-
soluti...](https://info.container-solutions.com/hermes-container-solutions-
strategic-execution-toolkit) (Apologies for the gated content)

------
xena
OKRs were always waved around as some magic secret sauce that's going to
revolutionize the free puppy distribution market. In practice they ended up
just being another reason why directors would bother us about the "error burn
rate" of services that only have errors when the upstream services they rely
on are having issues; with no way to programmatically remove that from the
"error burn rate". I hope this helped management discover how much the systems
of that job all rely on eachother.

------
etse
I feel like the article misses a powerful aspect of OKRs–the ability for
people to be creative, but in a cohesive manner that results in focus.

I noticed that my team hardly did any of the work we planned for last quarter,
but we were still able to achieve many of our key results through (different)
work.

In an organization where you don't have the power to influence your own work,
OKRs provide more context than what will be used, so people may feel like it's
a waste of time.

------
jordanpg
Goals are great, sure. And yes these are just goals with lots of wrapping.

But I am tired of having the latest management book wisdom foisted upon me by
product and management. Why do engineers always need to be dragged into this
stuff? Why can't they be content to have their endless meetings and share
their "decks" alone? As Christopher Hitchens was fond of saying about
religion: "just leave me out of it."

/rant

------
erikstarck
"OKRs tend to require hours and maybe even days to determine what are the
right goals and metrics."

The author implies that this is wasted time. It is not.

Figuring out why you do what you do and how you measure the success of that in
a way that leads you to the right result IS hard but extremely valuable work.
It forces you to deeply understand the problem you're solving and the
challenges you face.

------
xtat
In my experience OKRs are the latest fashion of BigCo MBA bullshit -- same
thing with a new name and with equally bullshit results.

------
bigbadgoose
I like having a static quarterly document, in a super easy to access place. It
must be one page max and lay out the "theme" of the quarter and supporting
initiatives.

Every team weekly summary email has a link to this document in the footer.
Tracker — or whatever you use — has epics et al aligned with this document.

------
kochikame
OKRs can be really great but only if they are used properly and are fully
integrated into the process from top to bottom.

Just relabelling old KPIs as OKRs is pointless (just, why would you do this?)

Just having OKRs at a division or company level is pointless (no buy-in or
engagement from regular employees)

------
vmware513
What is OKR?

~~~
6nf
Example of a more traditional KPI (Key Performance Indicator): System downtime
must be below 0.01% every quarter.

Example of an OKR (Objectives and Key Results): By the end of the quarter,
implement a new fast-response process to reduce issue resolution time by 25%

~~~
1123581321
That isn’t an effective OKR. Try this:

Objective: system downtime must be below .01% every quarter.

KR: implement new fast-response process (binary measurement.)

KR: reduce mean issue resolution time from 60 to 45 minutes (linear
measurement of progress with .75 set to 15 minutes and 1.0 set to 20 minutes
of reduction)

In this case, your objective is likely a key result of our boss, so it makes
sense that it’s the same measurement. You’re being measured on something that
matters. One of your key results is purely based on effort. The other might
have a bit in it that’s out of your control, but also lets you benefit from
other ways you and your team find to achieve the resolution time reduction.

------
alex_young
OKRs can be great, or they can result in releasing software that isn't ready
yet (see Google's Buzz for context).

My suggestion: let your team members craft goals, and help shape those goals
into deliverables that help them and the company.

------
Rapzid
I worked at a startup for a bit that started OKRs and I found experience super
enjoyable; to the point where working in a more relaxed environment(for lack
of a better description) is kinda hard these days.

The two things people and teams struggled the most with though, IMHO, is:

A.) Coming up with a good OKR that met longer term, higher level company
priorities that intersected your work.

B.) Coming up with a good ORK in terms of measurable key results.

It can be tough and time consuming to get the measurements in place necessary
to gauge the results, or even make a case for the OKR in the first
place(incidentally this is the dirty secret of SRE IMHO). We would pro-
actively get data collection in place on occasion for reasons that included
helping to launch and score future OKRs.

~~~
tadasv
True. I've worked at several companies where OKRs were implemented and I find
it valuable. Everyone does them differently. People still have trouble
understanding and implementing them.

To address some of the pain points with OKRs I started building my own saas
about a year ago [https://simpleokr.com](https://simpleokr.com)

------
james305
John Doerr's book references Intel and Google heavily to gain credibility for
the OKR methodology. Can someone from either of those organizations chime in
with their experience?

------
pst
OKRs aren't supposed to fix communication. They are supposed to guide your
team to make day to day decisions that support the agreed goal.

------
maerF0x0
One issue I see... People dont actually read their email

[https://blog.prepp.io/news-stories/youre-not-imagining-it-
yo...](https://blog.prepp.io/news-stories/youre-not-imagining-it-your-
employees-are-not-reading-your-emails)

------
2betafactor
True that!

------
2betafactor
true that!

