--- title: "OKRs in practice: goals that steer the workday" description: "OKRs only steer the workday when key results measure impact instead of counting activity. How I lead with few goals as COO, and where the method is a poor fit." url: https://carl-wuerfel.de/en/notes/okrs-in-practice author: Carl-Uwe Würfel --- 1. [Home](https://carl-wuerfel.de/en) 2. [Notes](https://carl-wuerfel.de/en/notes) 3. Leadership # OKRs in practice: goals that steer the workday OKRs only steer the workday when key results measure impact instead of counting activity. How I lead with few goals as COO, and where the method is a poor fit. [Carl-Uwe Würfel](https://carl-wuerfel.de/en/about)First published January 12, 2026 · Updated November 5, 2026 · 5 min read[Deutsche Fassung](https://carl-wuerfel.de/notizen/okrs-in-der-praxis) A key result that counts an activity does not measure impact. "Five new tools introduced" or "ten training sessions held" describes work. It does not say whether anything got better. I think this is the most common mistake people make with OKRs. In AI projects it happens especially often, because rolling out a tool is so easy to count. OKR (Objectives and Key Results) is a goal-setting method. An objective describes the desired direction in words, and a few measurable key results show whether the effect has happened. The goals apply to a fixed period, usually a quarter. Andy Grove shaped the method at Intel, and John Doerr brought it to Google. In day-to-day leadership, what counts is whether teams prioritize their work by these goals and whether obstacles surface early. A well-kept goals document on its own hardly changes the workday. The decisions that follow from it do. ## Separate direction from results An objective describes the change a team is aiming for. Key results show whether it happens. A list of completed tasks helps with planning, but it does not prove impact. Since 2023 I have been moving SUMAX as a whole company onto AI. In that work I keep two things apart: introducing an application and improving a workflow. The introduction is a task a team checks off. The improvement is the result a goal has to be measured against. So a key result asks whether a handoff is more complete, whether a report needs less rework or whether a team delivers a service in fewer hours. Whether an AI application plays a part makes no difference to the goal. That is why, in this transformation, I look at the work itself. In editorial work, for example, I look at how many specialist articles get written per hour. As of this revision, it is a multiple of what was possible in 2024. Anything that just gets checked off belongs on the task list. A key result that counts an activity does not measure impact. _Figure: Two columns: key results that count activities, such as five tools introduced, ten training sessions held or an application rolled out, do not measure impact. Key results that work ask whether a handoff is more complete, whether a report needs less rework and whether a service takes fewer hours._ ## Fewer goals, clearer priorities A team with too many goals ends up prioritizing by gut feeling. I believe in few goals per period, even if important topics have to wait on purpose. Making that selection is leadership work. Leave it to the team and you get a long list where everything looks equally important. You can talk a few goals through without anyone opening a document. A goal nobody knows by heart does not steer a single workday. ## Connect goals to the work A team needs to know what its work is supposed to contribute, and it needs room to find its own way there. Leadership sets the goal, the team sets the path. This only works if both sides take it seriously. Leadership stays out of every single step, and the team speaks up early when the path is not working. A rigid cascade, where every level simply inherits its goals from the one above, undoes that split. One department is enough to start with. The regular check-ins are about obstacles, not status reports. Simple questions help: What has changed? What is in the way? Which assumption turned out to be wrong? The answers often say more about where things stand than a progress number that looks precise. A high percentage sounds like progress and can still mean the hardest part is ahead of the team. A single document with the objective, the key results and the current status is enough as a template. It lives in one place everyone knows, not in individual heads or scattered spreadsheets. ## Goals can be corrected If preconditions fall away, or a task turns out to mean something different, that calls for a deliberate decision. Keeping a goal only because it was once agreed sends work in the wrong direction. So I change a goal mid-period when the situation calls for it, and I would rather do it openly than ask the team to chase a goal nobody believes in anymore. Being responsible includes explaining the change so people can follow it. A team that gets no reason reads it as arbitrary. A team that knows the reason learns something about where the company stands. ## Keep OKRs out of compensation Once pay depends on key results, teams set goals they know they will reach. That takes away what OKRs are most useful for, which is making ambitious goals visible and talking openly about obstacles. Performance and development belong in separate conversations with their own criteria. The team's goals come into those conversations as material for discussion, not as a formula. This is also where OKRs differ from management by objectives, where goals are usually set once a year from the top and often tied to bonuses. ## A goal needs an effect the team can influence A key result measures something the team can influence through its own work. Numbers that depend mostly on the market, on individual deals or on other departments work as observations. As key results they do not work. > A team wants to improve the quality of its handoffs to the next department. The number of tools introduced is a poor measure for that. It makes more sense to agree together on what a complete handoff looks like, then check real handoffs against it and measure how often rework is needed. The team controls that number itself. Along the way it also becomes clear what is in the way: missing information, unclear responsibilities or technical hurdles. The goal conversation then leads to decisions about the work itself. ## Where OKRs do not fit OKRs are a tool for change within a fixed period. For running operations, meaning utilization, day-to-day quality or hitting deadlines, standing metrics work better because they measure continuously. Wrap every routine in an objective and you water down the goals that are supposed to change something. I keep the two apart. Metrics show whether operations are running, and goals describe where they should go. The method has its own limits too. In very small teams, the effort of writing, aligning and tracking OKRs can outweigh what they bring. There, a few metrics, one clearly stated goal for the period and a regular conversation about progress are enough. ## Further reading * [Profile and responsibilities](https://carl-wuerfel.de/en/about) * [AI change management: your team is rarely the problem](https://carl-wuerfel.de/en/notes/leading-a-team-through-ai-transformation) * [Measuring AI ROI: time saved isn't money saved](https://carl-wuerfel.de/en/notes/ai-roi-in-an-agency) * [An AI roadmap with decision points](https://carl-wuerfel.de/en/ai-roadmap) ## Contents 1. Separate direction from results 2. Fewer goals, clearer priorities 3. Connect goals to the work 4. Goals can be corrected 5. Keep OKRs out of compensation 6. A goal needs an effect the team can influence 7. Where OKRs do not fit 8. Further reading **Carl-Uwe Würfel** COO & Chief AI Officer, SUMAX [Questions about this piece](https://carl-wuerfel.de/en/contact) ## Read next. * [**Shutting down an AI system: keeping it is a decision too**](https://carl-wuerfel.de/en/notes/when-we-switch-off-an-ai-system) * [**AI prompts as part of the documentation**](https://carl-wuerfel.de/en/notes/prompts-are-documentation) * [**Running AI in production: the pilot is the easy part**](https://carl-wuerfel.de/en/notes/running-ai-systems-lessons)