OKRs vs. KPIs: understanding measurements for your SaaS business

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

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.

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.

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

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

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.

Maybe we computer people are, like anybody else, also in need of a Shepard and a holy book?

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

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.

Let’s say you want to fit in your clothes again. Make that the objective. The KR is a how for the O why.

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.

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