OKRs in a 2x2 Grid
6 February, 2019
In my experience, it is easy to overthink the process of implementing OKRs (objective and key results). If you survey advice on how to device and apply OKRs, though, it ranges from overly simplistic to a fine level of detail. Thus, there are a lot of different approaches when it comes to this matter. Here is my general advice for implementing OKRs.
- First of all it is extremely important to establish a clear objective. When working with your team to define OKRs, they are going to present a bunch of ideas, but it is your role as the facilitator to ensure that there is clarity in the goal. What is the thing that you are really trying to do? The outcome that you are focusing on should be clear and everybody should agree on it.
- The 2x2 Grid- a visual sketch populated by four sections: clear objective, the implementation steps you are going to take, improvements suggested by your team, and measures you're going to use to determine value. This creates a tight cycle that you can run with your team to go over things as you move towards your dedicated goal. IMPLEMENTATION STEPS - IMPROVEMENTS - OBJECTIVE - MEASURES
- Bottom-left section, The Objective: once you have clarity and consensus on the outcome, write down that objective in this box.
- Top-left section, Implementation Steps: list a few first steps to take so that your team has some sort of direction. They don't have to be very detailed, in fact, they may change or you may not even stick to them, but outline a basic plan. They are good to know and you need to articulate them, even if for yourself.
- Top-right section, Improve Capability: ask the team to brainstorm ideas on how you can make improvements and plug them into this section. This information is not necessary but can be very valuable because it gives equal value to concerns the team has.
- Bottom-right section, Measures: staying along the lines of the core goal and what the ideal outcome of success looks like, write down ways that you're going to measure so that you know whether the steps you are taking are valuable or not. Measures should be fairly tangible and should be your idea of what 'good' looks like. They're meant to serve as an anchor in the process.
- Use smaller time frames for OKRs, think monthly or quarterly, because you are likely going to be doing iterative and incremental work toward the outcome.
- Don't cling to a goal if it's not valuable. Sometimes you find that the objective that you set is way off and it needs to be modified or abandoned all together.
- Keep track of the steps and experiments that you run as well as the changes that are happening as you work toward the goal. This allows you to check-in on how effective the process is, especially if you are doing retrospectives. It's good to be able to go over things that you tried and to talk about why you did them, what worked, and what didn't.
- OKRs are used to establish comprehensive business outcomes, therefore, some implementation steps are going to fail and some are going to succeed. Both are okay and in both cases you should continue asking the question, did these steps move us closer toward the objective that we are trying to reach?
- Measures tend to run on some shippable item, a pretty short order. Usually an order of a week or two can justify your results and is also a good amount of time to review with the team what the cycle has produced.
- Pick metrics that are reflective of success, not reflective of the implementation.
- A way to diagnose whether this process is going well or not is to observe conversations around this topic. If people are jumping directly from the objective to the measurement without talking about the steps along the way, then they do not comprehend the point of the system.
- This method is not about teaching how OKRs work. Instead, it is a chance to lock in a cultural component of your company. You are modeling the kind of behavior and thought process that you want from your engineering organization. You want it to become a natural part of how people communicate about goals and objectives.
Marian Kamenistak, VP of Engineering at Mews, explains why EMs shouldn’t be measuring the output of a team or individual engineers, but the outcome of the whole team.
VP of Engineering at Mews
David La France, VP of Engineering at Kenna Security, explains how managers can level up their skills and scale in their roles by learning to work less, but smarter.
David La France
VP Engineering at Synack
Brad Henrickson, CTO at Scoop, shares how by establishing the Architecture Council he advanced strategic thinking of the engineering team and overall strategic orientation of his organization.
CTO at Scoop
Philip Camilleri, Co-Founder and former CTO at SmartAsset, and now CEO at Founderslist, explains how he approached building a prototype, not meant for production, with limited resources typical for startups.
Cofounder and CTO at Founderslist
Melby Mathew, Engineering Manager at LinkedIn, explains why the collaborative goal-setting yields the best results and how that helped his team improve their performance beyond expected.
Engineering manager at LinkedIn
You're a great engineer.
Become a great engineering leader.
Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.