Michael Rill

Einfach machen

Tag: OKRs

  • The metric is not the goal

    Great articulation by Mike Davidson in his reflection of being one year at Microsoft:

    Our north star is at least pretty pure — Daily Active Users — and that metric is usually a good indicator that you’ve made something people like, but doctrinaire allegiance to almost any singular metric can quickly make people forget why we are in this profession to begin with: to improve lives. Or to put it squarely in Microsoft parlance again: to help every person and organization on the planet achieve more.

    If you ever find yourself asking the question “how can we increase Daily Active Users?” instead of “how can we make our product better for people?”, you’ve already lost. Metrics are trailing indicators of qualitative improvements or degradations you’ve made for your customers… they are not the point of the work.

    One year at Microsoft » Mike Industries

    It’s a great reminder that a KPI is an indicator of value (it says it right on the tin), not the value itself. In large companies, we have created sophisticated systems that drive those indicators that it’s sometimes easy to confuse them. If you work at Microsoft, the easiest way to drive monthly active users is to pre-pin your app on the Windows task bar. Which is when the metric stops being an indicator of customer value. Or as Goodhart’s law states it:

    “When a measure becomes a target, it ceases to be a good measure”

    Goodhart’s law – Wikipedia

    Coming up with good metrics and keeping them fresh (speak: preventing them from being gamed) continues to be hard.

    Hat tip to Isaac for pointing me to Mike’s post.

  • The OKR Operator’s Manual

    The OKR Operator’s Manual

    I’ve recently come across the Operator’s Manual, a post by Ian McAllister. It’s a compilation of tips for communicating data, dates and deliverables. Basically, how to live up to “be bright, be brief, be gone”. 

    Taking inspiration from that post, below are some tips that I frequently share when it comes to OKRs. My standard line is “OKRs are deceptively simple, but tricky to get right” or as I just recently heard from Isaac “a minute to learn, a lifetime to master.” Below is an overview of some of the tricky aspects. None of them are rocket science, but each represents a hard-earned lesson:

    Introducing OKRs

    Articulate the “why” for OKRs: The original sin is starting the conversation with “I think we should do OKRs” without specifying what you want to improve with them. OKRs can help with many things such as increasing transparency, aligning teams on clear goals and targets, surfacing disconnects between teams early, bringing strategy closer to execution, improving focus, … Pick one or two challenges upfront and be clear on how OKRs shall help. Unless you create clarity for what you optimize for, OKRs are easily dismissed as another management fad.

    OKRs are not an extra thing: OKRs are set to fail when they are handled separately to the rest of the product management process. Instead, they should be tightly integrated into how teams work and manage their products. Product decisions and feature prioritization should be grounded in their alignment to the Objectives and their ability to move Key Results.

    Keep it simple: It can be tempting to design OKRs from the get-go for an entire organization all at once with multiple levels. That becomes overwhelming quickly. It helps to pick one leader and design a single set of 1-2 Objectives with 2-4 Key Results each for their area of responsibility. Think of it as a cheat sheet that they would use for the 1:1s with their boss. Don’t overthink it and avoid the temptation to put too much detail into too many Objectives and Key Results. Start with 1-2 Objectives with 2-4 Key Results and take it from there.

    OKRs are not individual performance management: OKRs can be an input for an individual performance review conversation. But they should be one of many inputs. As somebody once told me: “I’m not going to force myself to promote jerks just because they deliver on their OKRs.”

    Selecting Key Results

    Outcomes over outputs: When defining Key Results, if at all possible, avoid output-Key Results. Outputs are basically tasks that need to get done (Launch feature X, reach milestone Y, revamp marketing website, …). They are tactics to get to an outcome, but they are the outcome itself. Walk the extra mile and identify what the benefit is that you want to achieve with a specific feature or activity (increase in user engagement, more leads, better customer conversions, …) and use that as your Key Result. Techniques like the five whys help. That discussion can become quite esoteric (“Why do we exist? What is our purpose?”), but that is only temporary and typically an indication that the team is on the right track to better and more refined OKRs. Rick wrote a good post about this: Binary: Good for code, bad for OKRs. 

    Fewer but better OKRs: Every single time I’ve introduced OKRs we ended up with more than the recommended 3-4 Key Results. I’ve come to accept this as a necessary rite of passage, because after a few OKR review meetings the team realizes that the conversation always centers around 2-3 Key Results that really matter. Once you come to that realization, go ahead and deprecate the other Key Results. They are typically the ones that turn out to be green/on track while nobody feels good about the overall progress.

    Be an OKR pragmatist, not an OKR dogmatist: There are lots of different flavors and nuances with OKR implementations. John Doerr had “output” Key Results in his examples and even within the almighty Google not everything is as clear cut as it looks from the outside. Try to understand the underlying concepts behind OKRs, but also feel free to break the rules when they hurt you. In the same way as database normalization comes with clear drawbacks the further you progress, there is value in not being too dogmatic about OKRs. Know the rules well, so you can break them effectively. (Hat tip to Isaac for the punchy headline)

    Don’t start with an OKR tool: When introducing OKRs, the first step is to understand the methodology and create a rhythm around setting, reviewing and scoring OKRs. You can do that with a shared document to set, track and review OKRs in a smaller team or one specific level in the org hierarchy. A tool will distract at the beginning and easily derail the effort. Once you roll OKRs out across multiple teams and organizational hierarchies, a tool can help manage the complexity. But start small and simple first, build the muscle and then move to a tool. I wrote more on that here.

    Reviewing progress

    Commentary over number: Knowing where a metric stands is important, but understanding what drives that metric and what the implications are is by far more important. I recommend addressing three aspects in the commentary:

    • Data (what): What does the data say, is it going up or down, by how much
    • Insight (so what): What does it mean, is this good or bad, what are the causes for this behavior, what can we learn from this, have we identified new risks to our plan, …
    • Action (now what): What should we do about it, do we need to adjust our plans, …

    Once you get to a spot where the commentary is consistently good in OKR reviews, OKRs become this amazing learning tool that accelerates how quickly a team understands its customers and its product.

    Embrace the red: Encourage Key Result owners to give a fair and balanced assessment of the status of their KR. Being “red” is not necessarily bad – pretending not to be is. Once a team “embraces the red” OKRs shift from a performance management tool to a learning device that facilitates highly impactful conversations about what teams learn as they build, launch and operate products. I wrote more on that here: Embrace the Red.

    No watermelons: Avoid the temptation to declare a Key Result as “on track” when it is actually “at risk”, i.e. the watermelon (“outside green, but when you look inside it’s red”). If it’s at risk, declare it early, which brings us to …

    No surprises: Leave it all on the table and make sure that you create maximum transparency when reporting your Key Results. I’ve seen too many rationales that assume a hockey stick growth curve only to be surprised in the last OKR review of the quarter or semester. Hope is a bad strategy. One way to address this issue is to track the confidence level for each Key Result as part of the review conversation: each Key Result starts at 50% by default, i.e. a 50-50 chance to hit the goal. As you progress through a quarter you will learn more and the confidence will move up or down and allows a team to communicate confidence even if a Key Result is backloaded. It creates an embedded feedback loop in case confidence levels swing hard towards in the last weeks of a quarter: What could we have anticipated earlier or better mitigated risk? Christina Wodtke has more on that in her book Radical Focus.

    Final Words

    Every OKR implementation is different and the above are just a few of the lessons that I learned over the years. I’m sure I’ll be able to add more over time. By the way, most people know Measure What Matters by John Doerr, which is a great intro into OKRs. Once you understand those basics, I highly recommend The OKRs Field Book by Ben Lamorte. Lots of hands-on advice in there on how to get started and what kinds of pitfalls to avoid. 

    Big “Thank you” to Isaac for his generous contributions to this post. He’s also been the one who got me back on the OKR bandwagon.

    Photo by Ryan Graybill on Unsplash

  • Embrace the red

    Embrace the red

    One of the biggest success factors for OKRs is culture. A healthy team culture of trust is fertile ground for successful OKR implementations. One of the core principles is to “embrace the red” in OKR reviews.

    It’s important to celebrate what teams are doing well. At the same time, learning and growth happens in areas that are blocked or need attention. As teams create new categories, targeting new audiences and inventing new products, there will always be aspects that need to improve, i.e. show up red on the OKR scorecard. The red key results are the opportunity to improve the eventual outcome as soon as possible.

    It is easy to slip into a mentality that suggests anything in red is negative – and uncomfortable to address. Focusing on red key results will generate the fastest growth. It opens up the path to improvement, growth and scale.

    Once you “embrace the red” OKRs shift from a performance management tool to a learning device that facilitates impactful conversations about what teams learn as they build, launch and operate products.

    Image: Engine start button on Unsplash

  • OKRs and tools

    OKRs and tools

    In the space of OKRs there is an unwritten rule: Once a team announces the introduction of OKRs they must face within five minutes the question of which software tool they will use.

    This question is mostly glazed over in books like Measure What Matters or Radical Focus. For good reason: The biggest hurdle of introducing OKRs is almost never the OKR management tool, but rather understanding, socializing, and implementing OKRs as a tool itself. Techniques like pressure testing OKRs, outcomes vs. output or focusing on few but meaningful key results are a lot more important than the tool in the early stages, and it often takes a few quarters for a team to get good at OKRs and see results.

    I used to be dismissive when I got the question of the management tool. My standard anecdote was:

    Remember pickup basketball? You never worried about the person with brand new Jordans at the pickup game. But whoever was ready to play in whatever they were wearing?  For sure they were going to be trouble.

    I advised to use a simple shared document, spreadsheet or presentation, because ultimately OKRs are simple: Select a few objectives, find a small number of meaningful metrics to measure progress against those objectives, track progress. This should not be artificially complicated through a specialized digital tool.

    For smaller teams that line of reasoning still holds true even as comfort with OKRs develops. Most OKR management tools are designed for larger teams. While well intentioned, they tend to distract in the beginning – not unlike productivity porn or tweaking a fancy IDE before learning how to code.

    However, as a team grows and OKRs permeate the organization more people are getting involved. They all have their part in setting, tracking and reviewing OKRs. In that process multiple sets of OKRs emerge along the management hierarchy that need to align. Managing this through documents, spreadsheets and presentations starts to become unruly. I’ve been there. You start with a document to set OKRs, track them with a spreadsheet only to review them later with a presentation. And throughout the year you are endlessly cycling through those three artefacts. This is highly manual, error prone and massively annoying.

    Once you reach a team size of a few dozen people, it is time to think about investing in software tools. None of them are perfect, but they do provide structure, control and visibility that help deal with growing complexity. Pragmatically, they help keep data consistent, avoid double entries, and help crush the general entropy that comes with growing teams. Ultimately, it’s an investment in a more inclusive and transparent culture.

    Many thanks to Isaac Hepworth for many discussions about this topic, help with this post, and general encouragement.

    Photo by Cesar Carlevarino Aragon on Unsplash

  • Staying Clear of Golden Apples

    Staying Clear of Golden Apples

    Rick Klau once gave one of the most influential intro presentations to Objectives and Key Results: How Google sets goals: OKRs / Startup Lab Workshop – YouTube. It’s an evergreen talk and has gotten nearly 1.2 million views over the past nine years. He recently followed up with a post What my OKRs video got wrong. In that post he mentioned that one of his key learnings is “What you and your team say no to is at least as important as what you say yes to”.

    It reminded me of a story that I often tell when introducing OKRs. It is about Atalanta, a heroine in Greek mythology. If you have watched Disney’s Brave you will notice similarities with Merida, the main character.

    Atalanta was a strong, independent woman, and she was the fastest runner in ancient Sparta. To her father’s chagrin, she did not care to get married. Her father did not agree to that plan and set up a contest in which young men would race to win her hand in marriage.

    To keep her freedom, she asked to be allowed to participate in the race herself, i.e. race for her own hand. Her father, not thinking she had a chance of winning, agreed to the deal.

    At the same time, there was a young man called Hippomenes, who fell in love with Atalanta a long time ago. The race was his chance to marry his love. He knew how fast Atalanta was, so he prayed to Aphrodite. Gossip and intrigue are nothing new, and Aphrodite didn’t like Atalanta. So, she gave Hippomenes three golden apples and told him to drop one at a time during the race to distract Atalanta. To her demise, she was so fond of those golden apples that she stopped to pick them up.

    After each of the first two apples, Atalanta was able to recover the lead, but when she stopped for the third, Hippomenes won the race. It took all three apples and all of his speed, but Hippomenes was finally successful, winning the race and Atalanta’s hand.

    Adapted from Christina Wodtke‘s Execution is everything

    If only Atalanta had set clear goals and stock to them. She would have stayed single, footloose and fancy free.

    Atalanta’s story is surprisingly timely. We all are running into golden apples every day. So much to do, so little time. However, unless we focus on a few things, we spread ourselves too thinly and what feels busy is actually distraction. OKRs help discern the trivial many from the vital few.

    The most obvious example is the selection of key results. When introducing OKRs a lot of teams start with more than five key results for each objective, because those are the metrics they are tracking. Over the course of one or two quarters most realize that focusing on three-ish key results per objective helps them focus their energy and get more done by saying no to more things.

    In other words: If at all possible, avoid the temptation of golden apples!

    Image: Herp Atalanta and Hippomenes.jpg – Wikimedia Commons

  • The dogs won’t eat it – Choosing OKRs well

    The concept of Objectives and Key Results (OKRs) is deceptively easy.

    • Objectives are ambitious, qualitative and time bound goals of a team. Each objective is typically supported by ~3-4 key results.
    • Key Results are measurable achievements that contribute to those goals. They are business outcomes and typically expressed in terms of adoption, engagement, cost, performance or quality.

    An OKR describes both what a team wants to achieve and how it is going to measure its achievement. “We will achieve $Objective as measured by $KeyResult1, $KeyResult2 and $KeyResult3.”

    At the same time, coming up with good OKRs is hard. One has to identify the few key metrics that really matter and to commit on outcomes (e.g. growth) rather than output (e.g. launching a new feature). That requires judgement, uncomfortable leaps of faith and a willingness to experiment.

    Jeffrey Zeldman tells a great anecdote in the context of Marketing that illustrates what happens if you choose your Key Results badly: The dogs won’t eat it.