What’s the thinking behind this?

> Keeping something static (like keeping a metric at a particular number) is not a key result.

I could easily imagine a support team having an objective to keep the backlog of queries low. And to be pedantic, any metric can be expressed as “keep difference between metric x and expected/desired value y close to zero”, so there must be something deeper here.

IMHO that article quotation is wrong, and you're right. Static OKRs can be great for support teams, reliability engineering, service queues, recurring maintenance, periodic compliance, etc. Static OKRs can be as inspiring as dynamic OKRs, especially for highly motivated teams.

A popular example is the objective of 99.999% uptime. This is a superb goal, and when you achieve it there's a ton of ongoing work to keep it-- it's akin to a fine restaurant that earns a Michelin Star, and works very hard to keep it.

OKRs are Objectives AND key results, they're two different things. There is no such thing as "an OKR for growth".

I've found it helpful to insert the phrase "as measured by" between the two. If I can't do that the there is either a tenuous connection or I've blended the two concepts together.

For example instead of "OKR for growth = Improve {topic} by {percent} during {timeframe}. Measure by {metric}" You should have something like "Improve new user experience to create a loyal customers (aspirational objective) as measured by Improving onboarding completion by X%, Remove X steps from onboarding, Improve NPS for new users by X% (KRs)".

Usually putting both a measure and a deadline is redundant. There is an implicit deadline (the OKR cycle length). Likewise if you're defining a deliverable and deadline then you may as well just use roadmaps. The idea of OKRs is to give teams flexibility to learn and change course rather than follow a set path.

What you wrote is different than what I do; use what works for you.

For me, each objective gets one explicit measurement and one explicit timebox. And the key results can be a simple list of a few highlights that bolster the objective.

For me, an explicit measurement and explicit timebox both work better than implicit, because teams can be on different metrics and cadences-- such as engineering teams using uptime metrics for quarterly OKRs, VP teams using cashflow metrics with yearly OKRs, and launch teams using user metrics with target date OKRs.

OKRs are famously vague to begin with, and you are ignoring the little tangible guidance that does exist. You're just describing regular old planning.

That's fine, because OKRs have a drawbacks and lots of people struggle to make them work. But if you're teaching people you shouldn't call your approach OKRs.

Totally agree about famously vague. :-) You know what you're talking about, and your more-detailed points are more-faithful to Andy Grove's writing than mine.

Want to help? I'll donate $50 to your favorite charity if can take a look at the GitHub link OKR in my top post, and tell me what needs fixing/changing/improving to help all people know how to use these better and for free.

I like the concise aspects of your OKRs but maybe they're too specific? It's hard to tell without seeing the motivating problem statements in context though.

Yes you're right about concise and specific. These aspects help teams who are new to OKRs and who want to write good ones.

The motivating problem is how to get teams to try: "I don't want to waste time with project management overhead buzzwords" or "I don't understand why we need this because we already have task cards".

It turns out when teams see the concise specific templates, and write using that format, then the mental model clicks into place.

Do you have a goof basic resource you'd recommend for getting started in the process? I'm about to redesign a mostly ad-hoc operation to be more structured and formalized.

If you don't have at least 100-150 employees, I've found that OKR are an absolute nightmare and create more confusion than good. There are many better ways to align smaller teams and orgs.

Do you have any sense of why? It works best for me on small teams and startups, since that's where we need people to own and iteratively address full problems. "Understand and address why users of type X aren't returning" is not too confusing, especially if you have good communication processes during the actual work.

Does your OKR process span multiple teams and management layers?

Yes, my post links to GitHub repos where I maintain basic resources, examples, collected comments, and the templates that I use professionally-- see the "OKR examples by SixArm".

The most important single item for success, IMHO, is to invite your whole team to get involved at the start.

I have read the John Doerr's Measure What Matters, and trying to implement some. Do you keep all OKR's visible to everyone in the organisation?

Yes all OKRs are visible to everyone in the organization. Visibility builds mutual understanding, and also can be a great help for inter-team goals, team-of-teams projects, cross-functional areas, and roll-ups.

How do you avoid OKRs for capability that are all-or-nothing? I've had the problem picking ones that stay at 0 for a very long time.

OKRs that are all-or-nothing are fine in practice, when you have ways to measure progress.

For example the objective "Land a team on the moon" is all-or-nothing, and has progress indicators such as "Orbit a team around the moon", "Orbit a team around the earth", "Prove mission control performance during a crewed mission", and so forth. Each of those all-or-none items can have sub-OKRs, sub-KPIs, sub-metrics, etc. as you wish.

It depends on what you are trying to accomplish. A lot of things like migrations can be expressed as “100% of traffic on $New_service”.

Love this. Thank you for posting!