> 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.
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.
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.
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.
As an engineer, I’m really tired of these processes and metrics that are supposed to increase focus and enable delivering value but in practice often don’t. A lot of organizational time is spent coming up with OKRs only for them to be either overridden due to the reality of running a business (gotta do what clients need, gotta do what you can to compete with competitors) or just by VPs/Directors deciding that something else requires the teams focus. Ultimately it seems like a whole bunch of busy work for PMs and TPMs, to justify their existence and hiring more of them.
“But you’re not doing OKRs correctly!” Sure, I agree to that. But what use is a system or process that’s so difficult to get right that most organizations fail? I would argue that it is useless.
I’ve seen this happen with another process: the church of agile. The way I’ve seen agile being used effectively is for orgs to agree to use the parts of it that make sense for them, not worry about what’s “right”, and constantly try out new ways of improving in response to feedback. That gives the team a sense that it’s a process that is evolving to meet their specific needs, rather than evolving to meet a dogma.
I think it's totally fair to see OKRs as silly and useless as an engineer. Personally I think they are really only relevant at the VP level and above.
All the things you say are true about OKRs, they run up against the reality of the business, and at the end of the day are fungible, but I would encourage a different way of looking at OKRs.
They inspire a conversation about how the company should really be spending its time and resources. What are the ultimate goals of what the business is doing. What is the real opportunity. How do we define success and how can we push success further? What's the dream by investing in these various initiatives?
Once you are leading an organization of several people, each of whom has their own individual success depending on some of these decisions, it behooves you to take this type of planning seriously and spend some time trying to answer these questions at some cadence (once or twice a year at least) to solidify the high level goals - even if there is constantly the risk of these OKRs getting trampled by the realities of the business as you eloquently put.
The purpose of having these conversations about OKRs at the leadership level is a bit different than the pragmatic benefits of the agile process and the two are a bit perpendicular in terms of purposes. Agile is on the ground execution, dealing with and greasing the wheels for the day to day efficiency of small teams. OKRs are occasional shocks to the system attempting to steer a large barge on course towards a far off goal.
Philosophically, it's important to have something concrete to work towards.
Like you say, what happens in practice, no matter what the system, is that it takes on a life of it's own, and there is a management layer discussing, planning, monitoring, etc thr KPIs, OKRs, whatever, as if tending the metrics is the goal of the business instead of delivering the underlying work. And this pisses off the engineers (or whoever the actual "doers" are, because it makes management look like a big circle jerk instead of a useful function - and a lot of the time, this is true.
Personally, I can see emphasis on these metrics and their associated processes as an important part of a process driven organization, where you want everything to be consistent, and are willing to sacrifice efficiency (and job satisfaction), while carrying a heavy admin layer. This is probably true for most big companies.
Personally, I think the solution is individual responsibility- less management and more focus on specifications. Basically treating each employee as a subcontractor or tradesman and telling them what you want done instead of how to do it, and having money or %utilization as a feedback mechanism. But they only works with the right mindset, and if you're the government or a big Corp, it's probably easier to just spend the time on OKRs
I empathize with this view and felt this way for a long time, but now that I work with managers who are really good at this stuff and are "pushing" me to get good at it, I am seeing its power.
> “But you’re not doing OKRs correctly!” Sure, I agree to that. But what use is a system or process that’s so difficult to get right that most organizations fail? I would argue that it is useless.
You can say that about a lot of stuff. Most people "fall off the wagon" with proper diets, for example - but that doesn't mean it's not a valuable thing to strive for.
I’m not really a fan of agile but I like the simplicity of OKRs if done well. It’s not easy and time consuming like you mention. My guess is it rarely gets done correctly.
One of the main benefits of OKRs imo is helping each person understand where they fit into the big objective. I don’t see the value in management using them to set lofty goals or push their team.
In threads that complain about work, I see a lot of comments about a desire for ownership of their work. OKRs can play a role in describing a persons ownership.
You are right.
I experienced the same cult-like fanatic adoration of the process with rather detrimental results for the company's IT department similar to the times of "agile will solve everything and heal cancer" which bit us like a holy hand grenade.
Maybe we computer people are, like anybody else, also in need of a Shepard and a holy book?
> But what use is a system or process that’s so difficult to get right that most organizations fail? I would argue that it is useless.
This is also what extremely difficult but fundamentally important problems look like. Getting clarity about goals across a big organization where every single person has a different conception of the problems it faces is Very Hard. I don't know if OKRs are the right answer, but the right answer will definitely reflect the Very Hard nature of the problem it's trying to solve. Probably the most any methodology can do here is trick you into asking the right questions.
(I think Agile is an entirely different story. But remember that agility is only easy if you have solid developers, and hiring is in general Very Hard, especially for the kind of people who muck up Agile.)
"That gives the team a sense that it’s a process that is evolving to meet their specific needs, rather than evolving to meet a dogma."
In my experience the most dogmatic organzations tend to just cargo cult their methodology.
There's no real deep understanding for "why" it works for whatever MAANG they're trying to mimic. There's just a hollow pursuit of vanity metrics and busy work.
There's value to be had with good work methods but it's almost always when people craft it to serve the unique value their organization creates rather than blindly doing whatever it is that Google does.
OKRs are hard. A common error is to couple the O too tightly to the KR.
Case in point:
> Objective: Reduce body fat %
Key result: Reduce body fat by 5% by the end of the year
I really don’t like this form of OKR pair. The O is arbitrary here. Ideally leadership should convey the O, and the team can meaningfully exercise their experience to come up with KRs.
In this case you are just specifying the KR. For example the O might really be “Get in shape for the calendar photo shoot”, and another meaningful KR would be to increase your lean body mass a bit. But not if you are training for an ultramarathon!
Anyway, that’s perhaps a nit that is orthogonal to the point of the article. As to the article itself - I’m not sure I’m convinced by using both KPI and OKR. As I learned it, there is no reason not to set up KRs that are maintaining instead of improving; for example the SRE team might have the O: “keep the site up”, with one of many KRs: “99.99% API uptime”.
I’m a fan of conceptual simplicity and I just don’t see a win for a third category above “plain metrics” that the team tracks and “KR” that the company tracks. The main strength I can see to the OKR&KPI approach is it lets you hide your KPIs in some contexts and really drill down on the few true KRs you have left. But whatever works for your team, go for it.
All I know about OKRs comes from when the last company I worked for (a YC saas company) got all excited to implement them. They said teams would be empowered to meet the objectives they were given by leadership. The goals were audacious, but we were supposed to get excited by the challenge and freedom of working toward them as a team, doing whatever we felt was right to get the job done. Each team then got together and figured out a plan to do that: what to build, how to build it. Then leadership decided they didn’t like our plans, so they just told us what we were going to build instead. In the end, it ended up being completely top down and, ultimately, ineffective.
I don’t believe that’s how you’re supposed to run OKRs: My point is that these tools are as easy to mess up as any others, and will fail if there are deeper, unaddressed problems in the org that aren’t solved first.
The unfortunate aspect of most (if not all) OKR articles is their use of very simple examples. There are a thousand reasons why real world is messier. In a changing environment goals give people the false sense of comfort to stick with a plan rather than review and adapt, not to mention the danger of optimizing things for the wrong KPIs. So surprise surprise! It’s not as easy as it sounds.
I have found that KPIs are a useful addition to an OKR framework.
Objectives are usually big and ambitious, but need to be pinned down using Key Results. Key Results are the definition of success for an Objective.
However, it’s often the case that there are many ‘numbers’ that affect the Key Results. In advance it is very difficult to know which combination of such metrics is the right one to target.
For example, if a KR is to increase sales from £70k to £100k of product X, you can break this down into various other KPIs - traffic, inquiries, conversion rate, AOV etc
In many cases these metrics can’t be hard coded into a KR, as the sweet spot for the business is unknown - and ultimately we don’t care which combination brings us to hit our KR.
So KPIs allow us to play with the next layer down from KRs, setting and revising targets for the constituent numbers that ultimately drive a KR.
Note: KRs should not change frequently, but KPIs can - with testing, iteration, and new information.
He has a lot of respect in the tech world, being a leader at Kleiner Perkins who invested early in Google, Amazon, and many others. He's the person who really popularized OKRs, so the book has some great examples.
I liked the distinction made here between objectives and key results. Objectives are the general direction you want to go, key results are how much progress you want to make in how much time. In other words, key results set the planned pace in the direction of the objectives.
If the business is a vehicle, the business plan is the intended velocity vector. The objective is the direction of the vector and the key results are the magnitude (speed). And the KPIs measure the actual realized progress in the planned direction.
In terms of actually tracking and charting this data, it’s pretty useful to have it all in one place and queryable by SQL—this is not usually the case by default!
OKRs are essentially 2 parts. The "O" is an aspirational goal; The "KR"s are the measureable components.
* Start with the problem statement and then make the objective to address it.
* If you're always 100% on your OKRs they are not amibtious enough. The value is in the progress not "completion".
* Don't make your Key Results a giant checklist of TODOs. It's OK to have figuring out the "how are we going to do this?" as part of the result to be measured, you just need to predefine how it will be measured.
OKRs = objectives and key results: https://github.com/joelparkerhenderson/objectives-and-key-re...
KPIs = key performance indicators: https://github.com/joelparkerhenderson/key-performance-indic...
It turns out three templates can help greatly:
OKR for growth = Improve {topic} by {percent} during {timeframe}. Measure by {metric}.
OKR for capability = Launch {feature} for {benefit} on {date}. Track progress by {metric}.
OKR for process = Accelerate {queue} from {x} to {y} before {deadline}. Time by {metric}.