Effective OKRs in Practice

OKRs are Objectives and Key Results.
A goal-setting framework for defining and tracking objectives and their outcomes.
They define strategic directions through setting inspirational goals, to be achieved through concrete, time-bound measurable results.

Primarily used for focusing the whole company on the goals, with the added value of visibility.

It’s common to have OKRs per quarter, because in a time span of a year things change too much.

Let’s look at characteristic of effective Objectives and Key Results at the company and team level.

Objective

Sets the strategic direction

• Inspirational, exciting
• Qualitative, not measurable
• Ambitious — hard but not impossible
• Aligned with the strategy
• Single sentence
• Can be done independently
• Max 3 objectives
• Time bound (e.g. end of quarter)
• Not an action, project or initiative

Tips

• Having “committed” (must do) vs. “aspirational” (should do) makes it complicated. Keep it simple — have Objectives rather than buckets of Objectives
• Team level Objective can be directly company level Objective or not, and in this case, it ought to cater to one company Objective
• The word “and” usually implies two different things. For example “Be an attractive company for investors and employees” — investor and employees are very different and may be even contradicting

Good examples

• “Be the go-to place for truck maintenance in Seattle”
• “Transform workplace onboarding”
• “Be profitable”
• “Renowned for a reliable import process”

Bad examples

• “Increase sales by 3%” — not qualitative, not inspiring
• “Implement a new payroll system” — an initiative, not inspiring
• “Revenue of 600,000$” — not qualitative
• “Triple the number of users” — not qualitative
• “Improve quality” — non-inspiring and limiting wording “improve”, action driven

Key Results

Tell us “how we know we succeeded?” for each Objective

• Quantitative
• Easily/simply measurable, e.g. growth, revenue, retention, engagement, performance, quality, conversion
• Incrementally measurable, transition towards a goal, not binary or a “big bang” event
• Outcome, not a project, not output, not an action or initiative, stated in past or passive voice, “what will have been achieved”
• Max 3 KRs per Objective
• No limiting words like “improve”, “rise”, “increase”, “reduce”, “keep”, “maintain”, etc.
• Mention the goal, not the baseline (that is, no “from A to B” sentences)

Tips

• Some KRs might require counter-measures for balance, to prevent gaming. Imagine there is a KR of “Every feature is developed in less than one day”, then it will for sure be, at the expense of quality and acceptance criteria —
  “Tell me how you measure me and I will tell you how I behave”.
  These counter-measures could be other KRs, company values, KPIs or health metrics.
• When it’s hard to measure something, look for a proxy. For example a proxy for how nice the security guards are, could be the number of times they smile and the number of complaints about rudeness.
• If there is no baseline — do your best to estimate it with the desired goal and do better next time.
• We use the outcome over output because the tactics of how to get to the goal may change, we may find a better idea, and also keep the autonomy of teams, and prevent cases where we just focus on the output, not caring about the goal behind it.
• Prefer positive over negative statements, e.g. “Min 90% success rate of imports” instead of “Max 10% failure rate of imports” — associate with success rather than avoidance of failure.
• Be very clear about the measurement, to avoid any dispute about achievements.
  “5 negotiations” — what does it mean? An initial phone call? an agreement draft?
  “Some partners joined” — which size? how many? what is a partner? what is joined?
  “Sales improved” — sales of what? can we sell in loss? is a 0.00001% improvement also an improvement?
• Prefer absolute values over percentage. For example, if you have 5% conversion rate and you want to increase to 10%, is it 5% or 100% change? Absolute numbers are simpler.
• To transition from an initiative or a project into a KR, ask what the purpose is, what will be accomplished, how do we know we succeeded, what numbers will move.
• Some teams, such as operations and support (day to day business) may not need OKRs, for instance when they mostly make the payroll. They can be part of health metrics, such as: NPS, new sign-ups, time to onboard a new client, code health, team health. Such a metric might become an OKR if it needs improvement and focus.
• Measure weekly and use projection to the end of quarter. The visualization is stronger than voting on confidence level of achieving. Checking in only every month does not allow timely corrective decisions.
• Do not tie performance reviews and compensation of individuals to OKRs achievements. This usually ends up being gamed, and people optimize for their own benefit rather than the team’s goal.
• Do not use personal OKRs. They create a conflict between team OKRs and their own, ruin trust and teamwork and incentivize thinking about personal gains over the team.
• Keep in mind that in companies or teams with low psychological safety, people will sandbag in order to not get punished for not hitting targets.
• Achievement of 70% is considered very good. Achieving 100% means that we were not ambitious enough or that we were sandbagging. Achieving less than 60% requires reflecting on what we can improve for the next quarter.

Good examples

• “50 testimonials have been received by existing customers of product X”
• “The newsletter was read by 1000 users”
• “10K accumulated monthly active users” (*active defined as…”)
• “300 paying customers in product Z” (*paying defined as…”)
• “Revenue of €1.5M”
• “Cost of €1.1M”
• “No more than 4 employees that we wish to retain leave”
• “5 Letters Of Intent signed by potential investors”
• “No more than 4 major incidents happened” (*major incident defined as…)

Bad examples

• “Salesforce integrated” — an action
• “32 bugs are fixed” — output, not outcome, no common goal
• “3 safety training completed” — initiative, not outcome
• “Better search functionality” — not measurable, subjective, ambiguous
• “12 user interviews conducted” — output, not outcome
• “4 tech tickets done” — output, not outcome, no specific goal
• “3 initiatives done” — output, not outcome, no specific goal
• “Increase deployments success rate from 95% to 98%” — limiting word, states current baseline
• “Retain NPS of 7.0” — limiting wording “retain”, not using passive voice, not easy to incrementally measure — one week can be 8.0, the next it’s 6.7 — what does it mean for the goal?
  While a KR “NPS of 7.0” is not so bad, maybe expressing it as “Average NPS of 7.0” handles the volatility better
• “5 partners in negotiation” unclear what “negotiation” means — cold email? meeting physically? draft ready?
• “Improve quality” — no numbers, limiting wording “improve”, not using passive voice, no outcome
• “Launch project Y on date W” — initiative, binary result, date has nothing to do with the quarter
• “Average customer satisfaction of 9 every month” — this is a monthly KPI, cannot be tracked weekly
• “Employee engagement of at least 3 out of 10” — not ambitious
• “Great office atmosphere” — not measurable
• Bad alignment — one company which had 2 software modules, had these two contradicting KRs at the same time by different teams:
  - Merge the 2 modules into 1
  - Extract a third module

Rollout and communication to the company

The company leadership sets a timeline and communicates it. It can look like this:

• 2 weeks before start of quarter:
  Based in the company vision, mission and strategy, company level OKRs company level OKRs are published
• 1 week before start of quarter:
  Based on the company level OKRs, each team derives its OKRs — need to cater to one or more company OKRs.
  Teams present their derived OKRs to their departments to align, make sure we work on the important things, and try to identify and reduce dependencies between teams.
  Teams have autonomy to decide how to achieve the goals. They gather all initiatives that may contribute to their OKRs.
• Start of quarter:
  Teams start working on their OKRs based in the priority of the initiatives
• Weekly:
  Track the progress of the OKRs. It doesn’t have to be precise, but give good sense of the real progress, or lack of. It could be based solely on metrics, e.g. we have 40 paying customers out of 100, or achieved milestones of a project that we determined is likely to represent an outcome.
  Check the end-of-quarter projection, it tell us where we’ll end up if we continue in the current pace. Think if there are actions to take, like change of tactics, doubling down, reduce scope, increasing resources, etc.
  Voting on confidence level of of achieving by the team members can be done instead or additionally, for the same purpose. It could be that numbers do not show what humans know is about to come, e.g. resignation of two team members that will risk the OKRs in the near future.
• End of quarter:
  Go over what we’ve achieved or failed to achieve, celebrate the wins and gather learnings for the next quarter

Tracking

There are software tools, and a mere spreadsheet will also do the work:

1. Create a tab of each team, where they update their OKRs and weekly status of progress:

2. Create a tab for the company OKRs, which will automatically calculate the company overall progress based on the teams’ progress status updates and visualize the projection — where we’ll be in the end of the quarter. It can be presented every all-hands meeting:

Initial failure is expected

First quarters tend to fail in several ways, for example very low achievements or achieving more than 100%, expressing OKRs as mere initiatives, having way too many OKRs, not tracking progress, non-measurable KRs and more.
This doesn’t mean that “OKRs doesn’t work”, it means we need to improve in the next quarter.

Engineering teams — how to make a realistic plan

A common mistake is to gather all product initiatives that make sense and decide they are the quarterly plan.

There are two problems here. First, capacity is not estimated and second, all other types of work are ignored. This causes a very low achievement of OKRs and frustration within the teams and management.

The alternative:

1. Count the quarter’s working weeks and multiply by the number of team members. Deduct estimated vacations, average sickness, offsites, etc.
2. Gather all types of work — support cases, incidents, bugs, product initiatives, engineering initiatives by the tech leadership or guilds, legal and compliance (e.g. GDPR or SOC-2 deadline), hiring efforts, onboarding of new members, tech debt initiatives by them team, etc.
3. Break down bigger initiatives to milestones and estimate in person-weeks each item.
4. Prioritize the items by value vs. effort (usually driven by Product) and any other criteria.
5. Cut off the prioritized list where the capacity ends.
6. Voilà — a quarterly plan for the team, which is realistic, not wishful.
   We look at reality as it is, not as we want it to be.
   It is totally fine to have stretch goals, hard but not impossible.
7. We remain agile — if priorities change, we gather new learnings or urgent things come up — we discuss as a team, and take out something else instead of the new work that we pulled, and notify all stakeholders.

What’s the Difference between an OKR and KPI

OKRs provide the missing link between ambition and reality. They help you to break out of the status quo and take you into new, often unknown, territory. If you have a big dream — an inspiring ultimate goal — for your company, you need OKRs that take you there.
A KPI, on the other hand, measures the success, the output, quantity, or quality of an ongoing process or activity. It measures processes or activities already in place.
Very often, a KPI that needs improvement will be a starting point for creating an OKR, and it will become a Key Result of an Objective.

What is a roadmap

A high-level visual summary that maps out the vision and direction of your product offering over time. A product roadmap communicates the why
and what behind what we’re building. A roadmap is a guiding strategic document as well as a plan for executing the product strategy.

It is not the quarterly plan for a team.

The product roadmap has several ultimate goals:

• Describe the vision and strategy
• Provide a guiding document for executing the strategy
• Get internal stakeholders in alignment
• Facilitate discussion of options and scenario planning
• Help communicate with external stakeholders, including customers

What is a person week

A unit of estimation or timeboxing.

E.g.: If a specific refactoring initiative is timeboxed to 2 personweeks, it means we have 2 weeks to work on it, a close to ideal work day (roughy 6 hours per day). It doesn’t mean we have 8 hours * 5 days per week * 2 weeks. It is calendar weeks ideally. In case something major interrupted the work, then we can pause and continue later on.

This is useful for capacity planning guestimation: assuming 4 engineers and 12 weeks, we have 48 personweeks. We deduct vacations, known
hiring efforts, incidents, etc. and maybe end up with 40 personweeks.
Estimating/timeboxing tech and product initiatives in personweeks will allow us to plan to capacity.

What is a tech initiative

A technical task or a set of tasks, that will drive some business outcome. For example: faster delivery of software, less incidents or allowing for upcoming changes.

We can differentiate between small initiatives, for example, upgrading a small library, or a 3 hour refactoring before implementing a “product” ticket, which are part of ongoing sprints, and are communicated to the PM and the rest of the team about their necessity and urgency.
The other type is the bigger initiatives, which involve longer work, might create dependencies, testing efforts, etc. Those are collected before the quarter, with their benefit and estimated cost by personweeks. We prioritize them and timebox or limit scope, and then they are incorporated into the quarterly plan of one of the teams.

What is a product initiative

Initiatives that affect the behavior of the product, for example: new features, new UI, new UX, performance improvements and bug fixing. The initiatives come mainly from Product Managers, based on their ideas, talks with stakeholders, discovery activities, user research, legal, compliance, strategic and tactic goals from management and ideas from engineers. They are prioritized and proposed by PMs in the beginning of the quarter and estimated in personweeks.
They are aligned by Product leadership (that they address all OKRs, they don’t collide, dependencies are manageable, etc.), and eventually end up in the
quarterly plan of a specific team.

Lagging indicator

A measurement of output from a system, that you don’t have direct control over, something that’s already happened, a result of something.

They are good candidates for KRs.

Common examples are revenue, profit and revenue growth. They’re typically easy to identify, measure and compare against elsewhere in your industry, which makes lagging indicators very useful.

However, the obvious downside of backward-looking indicators is they may provide insights too late to do anything about it. By the time you find out that half your customers have defected to the competition, it’s already too late to stop them. Even if it’s not too late, the lagging indicator is probably not telling you why this trend is happening and what you can do to stop it.

Another downside is that lagging indicators encourage a focus on outputs (a number-based measure of what has happened), rather than outcomes (what we wanted to achieve). One example of this will be familiar to anyone who regularly travels by train. As a lagging indicator, the train operator measures how many trains arrive at their final destination on time. To ensure it hits this indicator, the operator regularly amends the service, skipping smaller stations along the route to arrive at its final station on time. This negatively impacts arguably more important measures like customer satisfaction.

This focus on hitting lagging indicators (and how easy it can be to cheat the system to meet them), means lagging indicators are often prioritized
over leading indicators — even when the leading indicators would be much more useful for understanding and improving performance.

Leading indicator

A measure of input into a system, something you have direct control over, something you can act on and change, like an action or task.

They are good candidates for initiatives, not KRs.

Leading indicators are about trying to predict the future. The term “leading indicator” originated in economics, where it’s defined as a measurable
economic factor that changes before the economy starts to follow a particular pattern or trend. The number of mortgage defaults, for example, can predict negative changes in the economy.

In business, brand recognition, new product pipeline, growth in new markets or sales channels, are all examples of forward-looking indicators, pointing to trends that can predict future performance. Customer satisfaction can be an indicator for customer loyalty (and, in turn, future revenue), while employee satisfaction can be an indicator for staff retention (and, in turn, performance and productivity).

Leading indicators are important for building a broad understanding of performance because they provide information on likely future outcomes.
But they aren’t perfect. For one thing, they aren’t always accurate. Many of us were perfectly satisfied with our old Nokia mobile phones, for example, but we still switched to Apple or Samsung when smart phones were released! Therefore, think of leading indicators as what might happen, not what definitely will happen.

In addition, leading indicators are harder to identify than lagging indicators (which tend to be pretty standard across industries). Leading indicators are much more likely to be unique to your company, which makes them harder to build, measure and benchmark.

Indicators example

Reminder: Lagging indicators are typically “output” oriented, easy to measure but hard to improve or influence while leading indicators are typically input
oriented, hard to measure and easy to influence.

Let me illustrate this with a simple example:
For many people a personal goal is weight loss.
A clear lagging indicator that is easy to measure — you step on a scale and you have your answer.
But how do you actually reach your goal? There are two leading indicators:
1. Calories taken in
2. Calories burned
These 2 indicators are easy to influence but very hard to measure. When you order lunch in a restaurant the amount of calories is not listed on the menu. And if you are me, you have no clue how many calories you burn on a given day.

Effective leadership is learned
To learn more or reach out, visit my website or LinkedIn