Why OKRs might not work at your company

I've been working with GCP a lot during the last two years, and I think the experience is actually quite a bit better than people generally assume or adoption numbers suggest. It's probably not a great fit for large companies with really big engineering departments building really complex systems, but getting started on GCP as a small to medium org is a breeze, products at different levels of abstraction complement each other well (so it's easy to grow) and everything seems to be built to be minimum hassle and require a lot less fiddling by an engineer to get going than the corresponding AWS product. Much better web console than AWS, great K8S offering, BigQuery can do machine learning nowadays, which is actually usable for simple tasks. Everything has lots of sane defaults, it's usually only a couple of clicks to spin up pretty much any resource; in AWS this tends to be a huge pain.

Although, if you're in the EU and bound to a strict interpretation of GDPR, then your experience is going to be absolutely miserable, because there's no way to actually restrict data to stay within the EU for the vast majority of products. A lot of the serverless products has something like "data may be processed in US West or global" hidden in their docs (which legal tells me is a big no-no), and while you can set allowed regions, even BigQuery violates that silently, so that's useless and dangerous as well.

So if they were to get better at selling what they have (which they really, really suck at; we're using them not because, but in spite of, their sales efforts) and maybe discover Europe one day, then it'll be a very strong contender for AWS/Azure.

And maybe that would have been for the best. If we look, within a year of the HTC Dream (G1, First commercial Android phone) Nokia released the N900, an amazing device running real Linux.

We could have had Maemo instead of Android.

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.

But furthermore I think your comment is suggestive of the "You can't manage what you can't measure" fallacy that underpins OKRs.

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.