Measure what matters is a book which describes and evangelizes an approach to management called Objectives and Key Results (OKRs). John Doerr, in his role as a venture capitalist, helped bring OKRs from Intel (where they originated, under the leadership of Andy Stern) to Google. Thanks in large part to Google’s adoption, many technology companies have since adopted or at least experimented with OKRs in one fashion or another; I myself have seen a few iterations of this approach.

What’s interesting about this book is that it defines OKRs implicitly, through a series of testimonials from executives and mid-level managers who have adopted it in a range of corporate and non-profit environments. There’s no really sharp definition of what OKRs are, no concrete steps of how to implement them. There are some broad themes underlined, to be sure, but really the details are very much left for the reader to discover. In a way the book is a bit of an echo of the entire idea of OKRs: it focuses on results and deliverables without worrying too much about the way in which those results are achieved.

It’s clear from the testimonials that OKRs can be wonderfully clarifying for organizational leadership, and can help communicate priorities and measure them with good precision. That’s their key strength, to be sure. However, it’s equally clear that there’s a lot of confusion as to how to operationalize them, and a great deal too much focus on the format itself, rather than the values surrounding it. For example, there are all sorts of guidelines about what should and shouldn’t go in an objective, and how key results should and shouldn’t be derived from them - key results should be measurable, and should, when achieved, add up to the objective, and so forth. The chapters are organized into values (transparency, accountability, etc.) which are each meant to provide some guidelines into OKR implementation. They do, after a fashion, though the narrative is somewhat roundabout and indirect.

The problem is perhaps reflected in the name of this approach itself: OKRs focuses on the documents themselves, i.e. the list of objectives and key results. The structure of these documents is easy enough to pick up and follow, but the subtlety in this process is really in the contents of the documents, and the process of writing them up and curating them over time. It seems that a lot of different companies (including some of the ones profiled in this book) have tried this approach and made any number of mistakes along the way, because the focus is entirely on the document structure and not sufficiently enough on the contents and process. There is no “user manual”, as it were, and this book doesn’t really provide one, except perhaps with the appendix which describes Google’s implementation of OKRs. That may well be by design - Doerr appears to view OKRs as a sort of philosophy which must be implemented differently depending on the context in which they’re adopted - but it certainly makes it difficult to really sink one’s teeth into this idea.

So it is difficult enough to write one set of OKRs. It’s more complicated still to roll it out to an organization - how exactly does a department’s OKRs line up to the organization-wide OKRs? How should the head of the department’s OKRs line up to her department-wide OKRs? How often should OKRs be written and evaluated? What do you do if no one is following the process? Implicit in these narratives is the fact that these are tricky questions which are easy to get wrong, often at great cost. Also implicit in these narratives are many of the organizational values necessary to make OKRs successful: accountability, transparency, appetite for failure, and so forth. Doerr alludes to these values in chapter titles, but provides relatively thin operational guidance.

Additionally, there is the question of how OKRs live alongside other management techniques. Are OKRs compatible with other approaches, or must organizations manage themselves through OKRs only? Given how popular OKRs are in the software industry especially, how do OKRs live alongside such popular software development methodologies as agile software development? It’s not at all obvious how OKRs align with (or replace entirely) the software development backlog in these kinds of scenarios, and this book really doesn’t address the question at all.

Somewhat relatedly, the book glosses over the lived experience of individual contributors and other lower-echelon employees within OKR-managed companies. It’s telling that the people who narrate the chapters tend to be vice presidents and c-suite executives. They are the people who, it would seem, benefit the most from this system, and it’s not entirely clear that they understand how OKRs apply at the individual or team level. That is not to say that OKRs are not worthwhile, or even that they are some kind of elaborate system of oppression. But it does leave some rather big questions unanswered.

Of course, this book is not meant to answer every question under the sun about OKRs, and its mission is by design rather limited to evangelism. Moreover it attempts to focus on a broad swath of organizations - Doerr’s message is that OKRs are a general-purpose tool that have value in many contexts. Whether that’s true or not, the book’s lack of thoroughness in addressing some of these questions narrows its utility and scope quite a bit.