Who Does What by How Much

The problem it solves

Most OKR programmes start well and then drift into a list of things the team plans to build or launch. Gothelf and Seiden say the root cause is simple: people work hard on the wrong things because they lose track of what their customers want. The book names the usual ways key results go wrong. Some are tasks in disguise. Some measure a system, such as homepage load time, instead of a person. Some copy a revenue figure that the team cannot move directly. Each one gives you a number to report and nothing to learn from.

What changes after you read it

You stop writing goals about your own activity. You ask what people will be doing differently if you do a good job, and you write that down with a number. You also stop putting the solution into the goal. The objective and key results describe success, and the team is free to find the way there by trying several ideas and measuring them. That changes how a planning meeting sounds. People argue about evidence for a behaviour, not about whose feature wins.

When to read it, and when not to

I'd read it before your next planning cycle, or before you roll OKRs out to a second team. It is written for anyone, and the case studies range from a supermarket to a ceramics maker, so you do not need to be in software. If you are small, Parts 1 to 3 are the core. Part 4, on leaders, middle managers and scaling, matters once several teams share goals. If you only want a template, the book is longer than you need, because it also explains the habits that make OKRs stick.

Why it fits a business that wants to grow

Growth multiplies the number of things you could work on. The authors answer that with focus: one main objective per team per quarter, two or three key results, and a strategy to choose it from. They also show how goals stay connected as headcount rises. Every OKR needs a parent, teams that depend on each other can share one, and a pilot with one team in one quarter comes before any company-wide launch.

How I would connect it to decisions and playbooks

This part is my reading, not the book's wording. The authors treat every OKR as an assumption and every solution idea as a hypothesis that you test. That maps neatly onto a decision log: the choice of objective, the behaviour you expect to change, the number, and the date you will check it. Their Keep, Maybe, Stop and Start lists are a set of decisions too. When an experiment moves a key result, the steps behind it are a good candidate for a repeatable playbook.

Jeff Gothelf and Josh Seiden argue that OKRs go wrong when teams write goals about the work they will do. Their fix is to define success as a change in what a customer does, and then to run the goals as a continuous cycle of learning. The book is a how-to in four parts: what OKRs are, how to write them, how to use them, and how to make them work across an organisation.

Introduction

The authors say organisations rarely suffer from people who do not work hard. They suffer from people working on the wrong things, usually because they have lost track of what customers want. Their stance is that everyone has a customer, and that can be a colleague as much as a buyer. Their value equation is who does what by how much: the customer, the behaviour, and the size of the change. They also insist OKRs are not only for tech teams.

What Are OKRs?

OKRs are three things at once: a goal-setting framework, a process for using the goals, and a culture. An objective is inspirational, qualitative, timeboxed and specific. Key results measure progress and describe what customers do. An objective for a shoe designer, for example, is to make feedback easier, with brand managers giving feedback 50% faster. OKRs leave solutions out on purpose. As OKR expert Brett Knowles tells the authors, "Rule #1 of OKRs is that there is no Rule #1."

Why Use OKRs?

This chapter gives the benefits: customer value at the centre, learning and autonomy, transparency, a built-in reason why, and alignment with focus. It also lists seven principles, each with a typical failure: focus, autonomy, alignment, accountability, transparency, agility and customer-centricity. The autonomy idea goes back to management by objectives, which the authors set against decisions made by the highest-paid person in the room. Case studies include a supermarket and an Ecuadorian ceramics firm.

OKRs and Outcomes

Here the authors separate three terms. Output is what you make. An outcome is the change in customer behaviour that follows. Impact is the long-term result such as revenue, margin or churn. Google Glass and unlimited holiday policies are their examples of output that did not change behaviour. Key results are outcomes, and impact is too big for a team to work on directly. KPIs are useful as conversation starters, not as a one-to-one match for any part of an OKR.

Strategy and OKRs

Without a strategy, OKRs can point at the wrong things, so the book starts Part 2 here. Strategy is defined as an opinionated and coherent approach to an important challenge, a view that draws on Richard Rumelt and Roger Martin. Their light process is three steps: name your biggest challenge, decide where you will play, and decide how you will win. Then tell it as a short story. Internal teams have competitors too, such as the email or spreadsheet people use instead of your new tool.

Who Does What?

To find your outcomes, start with your scope of control, then pick the customer you will target first. Be specific without being absurd, and list three to six candidates. Next, tell a short story of that person's path with your product, using a donut shop as the example, and pull out three to six behaviours written as who does what. If you lack data, guess and go and learn, because waiting for perfect information costs more.

Writing OKRs

Take your biggest obstacle and turn it into a positive objective that has no solution in it. Give each team one objective and two or three key results, and give every OKR a parent. Check that each key result is an outcome and that hitting all of them would achieve the objective. For numbers there is no right answer, so offer a figure and let people react, weighing what is possible against what is valuable. The authors lay out a four-level score but are not keen on scoring.

Setting OKRs Through Collaboration

Goals set only from above lose context and buy-in. The authors describe a loop: leadership sets strategy and high-level OKRs, teams write their own with a clear parent, everyone talks it through with leaders and peer teams, and the result is revised and published quickly. They tell a story from their own former company, where a revenue target arrived with no objective behind it, to show what the top-down habit does.

Common Questions About Writing OKRs

This chapter answers the questions teams keep asking. Keep one main objective a quarter. Keep business-as-usual metrics separate. Write only within your scope of control. Guessing at numbers is fine. Write the key result even if it is hard to measure. In business-to-business work, your customers are the buyers, not their customers. It also lists four pitfalls: task lists, bending key results to fit the old backlog, measuring systems, and sandbagging. In the authors' words, "Key results should never be outputs."

The OKR Cycle

The cycle has five pieces: organisation strategy and OKRs, team OKRs, execution, learning, and checking in. The organisation sets goals yearly and teams usually work in quarters. Execution and learning run together, with check-ins as the punctuation. Communication runs through all of it. Short cycles matter because the faster you learn, the less you have invested in an idea that does not work.

Working with OKRs

Because OKRs have no solutions, you start from the key result and work backwards. List several ideas and phrase each as a hypothesis: we believe that doing this will achieve that outcome. Rank them by value and risk. Risky ideas get a learning activity first, and the authors would rather you talk to six customers than survey a hundred. Safe, valuable ideas get built, in small pieces. Collect numbers and conversations, because the first shows what happened and the second shows why.

Checking In

There are weekly, monthly and quarterly check-ins, plus a retrospective on the process. The weekly one is a thirty-minute pulse check, the monthly one is longer and includes stakeholders, and the quarterly one decides whether to confirm, change or replace the OKRs. Outcomes are the main measure of progress, and a confidence vote is only a way to start a conversation. Hitting 70 to 80% of a target is often a success. Changing a goal needs evidence and no surprises for stakeholders.

Planning with OKRs

Plan in short cycles and expect plans to change. Filter your existing to-do list through the OKRs by sorting it into Keep, Maybe, Stop and Start lists, and soften Stop into Not Now if that eases the politics. Replace the feature roadmap with an outcome-based one that shows themes, quarterly key results, solution ideas and learning activities. The further out a quarter is, the fewer guesses it should hold. For date-driven work, shrink the scope and ship a small, useful piece first.

Start with Why

Part 4 turns to culture. Before introducing OKRs, leaders should explain the problem they are solving, describe what the future looks like, and state their hypothesis for getting there, with success criteria written as outcomes. Without that, the authors warn, people comply grudgingly and OKRs become a chore.

Supporting OKRs from the Top

Leaders need to give a clear strategy and high-level OKRs first, trust teams to choose solutions, pay for learning work, open up data, and build psychological safety so that bad news can travel. They should also model the behaviour they want and organise people around customers. A manufacturer weighing pipe-bending as a service, and a marketplace group that reorganised into customer-focused tribes, show structure changing with the goals.

Managing Up, Changing Responsibilities

Middle managers are squeezed in the middle. The book tells them to tie every request from above back to an OKR and keep telling the story of their team's work. Their own role shifts from assigning tasks to keeping strategy aligned, setting constraints, clearing hurdles and making the call when evidence is mixed. On pay, the authors are firm: "Do not create individual OKRs and then use them for individual performance management."

Scaling OKRs

At scale, start from strategy and align instead of cascading. Picture a family tree, where every OKR, objective included, has a parent. Dependent teams can share one OKR. Set a time limit of about a month for writing the goals. A full rollout can take two to five years, so run it as an experiment: a small, visible pilot team made up of your best people, then OKR champions, training and tools. The case studies show Infobip learning from two failed attempts and Metro starting with sixty people.

What to do with it

• Pick one team, one objective and two or three key results for the next quarter, and write each key result as who does what by how much.
• Check every key result against the pitfalls: not a task, not a system metric, not revenue, and no solution hidden inside it.
• Write three or four hypotheses for each key result, mark which are risky, and plan a learning activity for those first.
• Hold a short weekly check-in and a longer monthly one, and share the notes with stakeholders as you go.
• Sort your current to-do list into Keep, Maybe, Stop and Start, and say no to what does not serve the OKR.