Book: Succeeding with OKRs in Agile (2nd Edition)
Author: Allan Kelly
Part: I — Why OKRs
Chapter: 4 — OKR history
Reading time: 2 minutes
Tags: okr-history okr-fundamentals andy-grove intel-okrs john-doerr google-okrs management-by-objectives peter-drucker goal-setting-theory
Summary: A brief history tracing OKRs from Peter Drucker’s Management by Objectives through Andy Grove’s adaptation at Intel to John Doerr’s introduction of OKRs at Google. Kelly shows how OKRs evolved from top-down management tools into collaborative goal-setting frameworks suited to knowledge work and agile teams.
4. OKR history
No organization which purposefully and systematically abandons the unproductive and obsolete ever wants for opportunities…
The normal human reaction is to evade the priority decision by doing a little bit of everything.
Peter Drucker, Age of Discontinuity, 1992
Once upon a time there was a management guru called Peter Drucker. He advocated ‘management by objective’ – or MBO¹. The idea was for managers to decide strategic objectives that the organization would pursue; effort and resources are then directed to meet these objectives.
Drucker was not the first to advocate MBOs and he was not the last. Differences exist in how writers describe the use of MBOs and how companies implement them.
In general, MBOs are interpreted as a top-down mechanism: senior managers decree the MBOs, middle managers instruct their department to undertake the MBOs. The workers at the end of the process are but recipients.
Andy Grove² invented OKRs in the early days of Intel Corporation. At the time Grove was a senior manager at Intel; he went on to become company CEO. Grove saw delivery as key: in devising OKRs he extended MBOs with a focus on delivery.
As one of the earliest and most successful Silicon Valley companies, Intel’s approach permeated Silicon Valley culture and many of the start-ups that followed. Intel alumni carried OKRs to new companies, and given Intel’s success, many were only too happy to copy.
Success bred success: the more people heard of OKRs, the more companies tried using them. The more companies that succeeded using OKRs, the more other companies wanted to copy them. That does not mean they were universally adopted in Silicon Valley, but they did become common.
¹The Practice of Management, Peter Drucker, 1954
²Measure what Matters, John Doerr, 2018
OKR history 21
One particular ex-Intel engineer became prominent in spreading OKRs: John Doerr. After leaving Intel Doerr became a successful venture capital investor. In this role he held an influential position with many start-ups and advocated the use of OKRs.
In 1999 Doerr invested in the company that was to eclipse all his other investments: Google. Next Doerr introduced OKRs, Google’s founders and early employees were eager adopters and – as they say – the rest is history.
Interest in OKRs continued to grow, and news of their success at Google further increased their allure. In 2018 Doerr published Measure what Matters in which he tells stories from Intel, Google and elsewhere while explaining OKRs in more detail.
1999 was also the year that Extreme Programming³ burst onto the scene. XP was one of several ‘lightweight development methods’ that were rebranded as ‘agile’ in 2001. It was only a matter of time before companies started to use both agile and OKRs.
While MBOs are still in widespread use, they have fallen out of fashion in many quarters. Experience with MBOs has shown several problems. Doerr suggests that in their formulation and use, OKRs rectify such problems.
Doerr’s comparison of MBOs and OKRs
| Tied to compensation | Mostly divorced from compensation |
|---|---|
| Risk-averse | Aggressive and aspirational |
| One should not pretend that the OKRs mechanism is without issues. Later chapters discuss | |
| some problems and issues you should be aware of. Like a sharp sword, OKRs can be |
One should not pretend that the OKRs mechanism is without issues. Later chapters discuss some problems and issues you should be aware of. Like a sharp sword, OKRs can be amazingly useful, but they also need to be handled carefully, lest they harm their users.
³Extreme Programming Explained, Kent Beck, 2000