OKRs at Akeneo

TL; DR: it is not easy delivering good OKRs

Innovation is saying no to a thousand things.

Steve Jobs

Definition

OKRs are, in today’s world, the most popular ‘goal-setting’ framework.

It stands for Objectives & Key Results, and companies use it to define goals and track their outcomes. Your Objective is the destination you want to reach by the end of the quarter. Your Key Results are the outcomes (not tasks, nor tactics!) that you must achieve to reach your destination.

• Objectives are qualitative descriptions of what you want to achieve. They are short and should be inspirational, e.g. build a stable, secure, and scalable platform.
• Key Results are a set of metrics that measure your progress towards the Objective, e.g. average deployment downtime < 30 minutes or 99 percentile API response time < 2 seconds.

John Doerr introduced them at Google in the early 2000s and quickly spread to large tech companies and startups such as Linkedin, Github, and Twitter. However, OKRs are much older than that. John Doerr discovered OKRs thanks to Andy Grove while working at Intel. Grove introduced them in his High Output Management book in 1983, but Doerr remembers hearing about them as early as 1975. After more than 40 years in the field, there are still controversy and discussion about how to create good OKRs. It is difficult to find the correct wording, set the right objectives, follow up on them, or avoid the binary side of the exercise with 0 or 1 (0% or 100%).

Why do we use it

OKRs are present in companies because they bridge the gap between objectives and operations. Companies usually have annual objectives that must be expressed in operational tasks. It is, therefore, a question of ensuring that the operations effectively serve the business strategy and these objectives.

The main goal is to align the work of each team with the company strategy. We define team “objectives” along with the measurable “key results” representing each Objective’s achievement.

We launched OKRs at Akeneo in 2017, to align our ever-growing number of teams. Keeping the teams’ ownership, efficiency and agility were also essential. For us, OKRs represent a framework that allows us to define ambitious objectives while monitoring the results of what we do to achieve these objectives. I recommend Nicolas Dupont’s talk at Yolocracy https://yolocracy.org/publications/comment-faire-des-okr-un-vrai-levier-dalignement-et-de-performance-des-equipes/. To illustrate, take the example of a goal set in 2019. I will use the SRE; this team is in charge of our production and overseeing operations 24/7. As soon as a problem occurs, they fix it; thanks to an on-call system there is always someone available. The objective defined by the team was to make this support and on-call activity as serene as possible. They aimed for zero alerts or false positives (alerts that ring for no reason and bring unnecessary noise). The first action was to reduce by half the number of signals requiring manual effort. We are not talking about how we will do it, but rather how we will achieve it. Then, in a context of strong growth, how do we welcome twice as many customers in production with such a strong constraint while maintaining the same team size? We had to be able to cut in half the time it takes to complete all the requests that customers can make on this infrastructure. Automation was vital here. We made just about every mistake possible or close to it!

Our first mistake was to do it top-down, which doesn’t work. We wrote an excel document with the leads in the form of a one-pager, indicating the objectives and the expected results. Seeing the team not take hold of the subject was pretty logical. It was seen as imposed. We had set the bar too high; with too many objectives. We were making them seem unattainable in a quarter. Disappointing from the start and therefore frustrating at the end for the teams. Less is more! We finally concluded that the goals were unclear, poorly expressed, and easily misinterpreted. They were ambiguous, often the teams themselves did not know what they had meant.

Having objectives that are as inspiring as they are ambitious, is difficult. Too ambitious and it can be uncomfortable for the teams- they could feel tell themselves that we cannot succeed. Uninspiring, and the teams don’t feel motivated. How can we strike this balance? In our everyday jobs, we don’t only do things that are inspiring, that is normal. Perhaps it is better to talk about the why of the problem rather than the solution itself; this is the tactic to use; it is not part of the OKRs.

I took over the OKRs when I arrived in June 2019. The first change I implemented was to make them visible to everyone in the organization, not only to the Product department. From an Excel file, we moved to a Notion page that grouped all the objectives by the team.

We quickly saw the limits of making one page per squad. We had to see each page of a team to know their OKRs. We then switched to a searchable database with the possibilities offered by Notion and were inspired by this template. It a much more readable and easy to use. https://anotioneer.notion.site/Company-OKRs-Notion-template-9e787e68ab9b4281ac29cf089494752e.

This database is still used today and allows us to see all team OKRs on one page. We don’t talk about it enough but having the right tool to manage these OKRs is essential and also allows us to record the statistics such as the success rate for the department, a service, or a squad. The right tool is good but not enough to get into the practice of OKRs. If you have a car for transport but don’t know how to drive it; you aren’t going anywhere. It is essential to communicate and implement the associated methods and practices; learn how to drive the car!

In calculating KRs, should we take an affinity score or a confidence level as a measure or a percentage of progress? The affinity score is feeling, which is not very predictive, hence the switch to a rate of progression, which requires not having binary KRs. As far as possible, we avoid having 100% or 0 to 1. Instead, we will take the number of steps for a feature or a breakdown by criteria such as “no more than 5% of users experience an error or average deployment downtime < 30 minutes”. The definition of non-binary KRs is the essential difficulty that teams encounter. So I took matters into hand and made a presentation to each squad. With the help of our VP of Product, I gave another broader presentation on why and how to do OKRs. We went over the focus and commitment aspects and the do’s&don’ts or specific examples.

The OKRs Akeneo practices

Our OKRs are shared and visible across the organization so that every team or department has visibility into goals across the organization, helping to align and focus the effort.

The OKRs help us choose what matters most every quarter. We ask ourselves the strategic orientations for the next 6/12 months in each squad. This question helps us find the right objectives that meet Akeneo’s year-long strategy. This first phase is thought by the Product&Engineering Directors and then explained to the team members. All must clearly understand the objectives. I like to explain it to the teams because if you have to present your goals to a newcomer, he must understand them immediately without thinking. Words have meaning, always. Then you have to measure key results, which are a set of metrics that measure progress towards the goal. They are based on concrete numbers and, as much as possible, progressive. We avoid having to go from a 0 to 100 at the end of the quarter. The definition of these progressive KRs is often the most challenging exercise for our teams.

We also love to remind ourselves: less is more!!! This is only possible if a limited number of key objectives and results are set. We limit to 2 objectives (one product and one technical) with a maximum of 3 KRs for each. Those limits increase the focus, less is more again here, more progress on fewer subjects, enabling the product squad to contribute to the roadmap and to be better connected to the suitable topics.

We have three different phases to produce our OKRs. The first one is the preparation phase. This is often done by Q-1 month and Q-2 weeks with the squads. The squad prepares the Objective Key Results with the guidance of the Engineering Director and Product Director. Then, the validation phase happens 2 weeks before the quarter is started, we have a steering meeting to present the new OKRs for the next quarter. The OKRs are validated by VPE, VPP, CTO, and CPO. This second phase doesn’t scale well with more and more people/teams. We try to optimize using a Slack channel and carrying out asynchronous validation or guidance. The last phase is the follow-up, done by the engineering manager in charge of the squad’s delivery.

Why is hard

Producing good OKRs is hard, it should be understood by everyone, inspirational but not irrational, achievable yet motivational. Definitely not an easy task…

Regarding guidelines, we promote 50% for new features and 30% for tech investment (technical debt, refactoring, scalability, performance topics, or introducing a new tool) to appear in OKRs each quarter. We also give a list of the common pitfalls to look out for:

👎 Our 20% support/maintenance is not part of OKRs: we never put day-to-day or support tasks in the OKRs. This also means that we take this 20% into account when defining the OKRs.

👎 Treat OKRs as Tasks: not all actions or tasks are necessarily or easily quantifiable. But that doesn’t mean they can’t have measurable key results. In this case, we look for a proxy measure that can serve as a performance indicator. For example, a manager in charge of establishing a culture of collaboration may have a goal of having a good NPS score or promoting a hackathon.

👎 Setting too many Os and KRs: the most common problem we encounter. Teams tend to want to do too much or think they are not doing enough. We advise them to reduce to 2 objectives and no more than 3 KRs for each to sharpen the focus. We also tell them not to launch everything simultaneously, to avoid starting everything but finishing nothing.

👎 Misalign with the Business vision: no one likes to feel like something is being forced on them, even if it will improve their work-life in the long run. Any corporate strategy should start with an executive sponsor and incorporate input from the entire company. Once the program is launched, everyone can see the organization’s value and impact.

👎 No time for reviews: defining, communicating, tracking, and reporting on OKRs are necessary tasks. This should be organized with a weekly department-wide meeting to track progress against corporate goals. Management and department heads use this opportunity to reaffirm alignment with key objectives and get all staff on board with the company vision.

Final Words

It is challenging to produce great OKRs, but it is possible with good guidance and help. We will continue to use OKRs in Akeneo’s Product department while continuing to evolve on our current usage. This framework helps us align the teams and give meaning to their work, making it visible to other departments; they directly see the impact. KPIs represent the outputs, whereas OKRs represent the outcomes.