Hello! My name is Egor, I manage the cluster of the App Platform in Avito. My teams are mainly engaged in the development of internal products, tools and processes - what is commonly called platform development.

A year ago, I told in this blog how we implemented and use performance review. Then I mentioned that we look at it as an indicator of the benefits that each individual person brings to the company. To understand this is important and useful. This helps to answer the question “how well is Vasya done compared to Petya?” And to determine which bonus to whom to pay. But when we go to the level of teams, everything becomes much more interesting. It is important to assess the specific result of the team and its impact on the success of the company. The high average performance of all team members does not necessarily mean that the team has achieved steep results. Some correlation is definitely present, but this tool cannot be used to assess the team’s actual contribution to the company's success.

To solve this and a number of other problems, we use the OKR - Objectives and Key Results method in Avito. It allows you to set a tree of clear and easily measurable goals throughout the company, link the results of different teams with each other and achieve the desired results.

With OKR we have been living for almost three years now. Starting with one team, we scaled the process up to 130 different structures - individual units, verticals, clusters, functions. In this article, I will focus on practical techniques for how you can use OKR to benefit from it.

Likbez

First, let's take a quick look at how OKR works and what problem it solves. Here I will not reveal any new secrets, but if you heard about OKR only superficially, then it will be useful. OKR is a goal-setting system that allows you to build a tree of goals throughout the organization, from the strategic level to individual structural units. A tree can branch as you please, ranging from very simple structures to dozens of levels of nesting.

Objectives define key business value. They answer the question “What?” And sometimes “Why?”. Key Results (Key Results) - this is the answer to the question "How?". If the goal is often an abstract slogan, then the key result is the maximum specifics that do not tolerate any water. Let's look at examples.

This is how one of the goals of an abstract bulletin board, laid out according to the OKR methodology, may look like. This is a pretty high level goal. It directly reflects one of the most important strategic objectives for growth.

Key indicators provide a clear and understandable way to measure a goal, because otherwise you can beat anything under steady growth: starting from a headcount and ending with the weight of a javascript on the main page.

Further, the goal set at the company level goes down to the level below - for example, a function, department or vertical. In this example, one of the subsidiaries is the Auto vertical, which wants to increase its market share.

Key results are also narrowing. They now revolve not only around specific numbers, but also set the area where they need to achieve these results.

The third part - the goals of a particular team. To make it more interesting, he gave an example of an infrastructure team that is working to accelerate the delivery of value to users. Directly, these goals are not inherited from the above, but have an impact on them in the long term.

In addition to these key mechanics, OKR has several dozens of principles, of which I have identified several key ones.

OKR principles

• OKR results should be completely untied from financial motivation , even though it is counterintuitive. I understand the desire to multiply the maximum bonus by the percentage of goals achieved by the team, but in no case should this be done. OKR - about honesty. As soon as there is a direct correlation between the goal achievement indicator and the balance in the account, these indicators will immediately begin to be understated by the team, cheating and attempts to break the methodology will appear. Instead of honesty, micromanagement and a culture of suspicion will start. This does not mean that awards are prohibited in a company operating under OKR. They are simply not tied to goals directly.
• Goals must be both ambitious and achievable . The ambition is that the key results are selected indicators in which the team is not quite sure. The whole system is formed so that if the team works on a full maximum and is super-laid out, it can reach about 60-70% of the indicators it has laid down. Such an approach guarantees a constant challenge, the presence of focus on the chosen goals, the growth of competences and ingenuity of the team. We are talking here not so much about a permanent job of overworking, but about healthy complexity.
• As I showed in the examples, any key results should be measurable . No abstract “works well”, all according to the familiar SMART technique.
• Objectives and key results denote the problem and describe it in some indicators, but should not dictate certain solutions . This gives the team room to maneuver - if one of the hypotheses did not perform well, they can always have time to implement some other solution.
• As I have already shown, goals must be linked . This connectedness can be vertical - from company level to specific teams. It can be horizontal, when co-dependent goals are set for achieving large cross-team results in different teams.
• OKR are intended primarily for a decentralized organizational structure. - Despite the vertical connectedness, most of the goals are set by the teams themselves, based on their understanding of their areas of responsibility, key tricks and users' pains. In short, the teams themselves determine what they should do , and formulate it in the form of the same OKR.
• And the last important principle is publicity . Everyone should see the OKR of any part of the company, be able to ask a question and see the choices made. There are exceptions for secret projects, but these are details. Similarly, the results are also available to everyone.

But this is all just a beautiful theory, which, like any other, works rather poorly in its pure form. During the three years that we have been working on OKR, we managed to shake each of these principles. In some cases, they were very hot, and in some, on the contrary, they began to work better. And everything that follows this section is no longer the OKR theory, but the result of our scientific approach!

How to start

As is the case with any framework, OKR should not be rolled out at once on the entire organization on the click of your fingers. Gradually check how your culture will allow you to integrate all of these principles and start getting benefits from them.

It’s best to start implementing OKR with one command. In Avito, for example, we did. Evgeny Emelyanov, our CPO, three years ago was a product of a team that developed tools for professional users - car dealers and realtors. He just became a pioneer. To get the most relevant advice, he went to Google, which actively uses OKR in all its divisions. Using the obtained insights, Eugene returned to us to introduce OKR. Here is his post about the method on Medium .

By the example of his team, the advantages of using OKR as a method of operational goal-setting have become clearly visible. The team, which had been quite stormy before, had learned to measure the results of their work, to understand their importance and to keep the focus. After a few quarters, the scaling began on neighboring teams, which, if possible, set related goals. And even later, when we had several fully working teams on OKR, we started working on vertical connectedness, defining goals at the level of the company, departments, functions and other entities.

At your place you can repeat the same way. Start by choosing one structural unit that is as close as possible to the battlefield. It’s not worth starting right from the level of the company - you can set goals, but there will be no one to carry them out. Your task at this stage is to test the methodology in a “hostile” environment, therefore, choose the pilot team wisely.

• It should be quite mature guys who understand the meaning of their work and business goals. They will not have to explain the importance of focus on the autkams, not the output points. And the buzz from fulfilling business goals such a team will receive significantly more than the usual fakedelyateley.
• The team must be played . They should be able not only to solve problems brought from above, but also to find them themselves. This quality will help them to take an active position at the goal setting stage and independently select and formulate their OKR, this will be a good breakdown of the bottom-up principle.
• The team must be able to contribute to any part of the system on which their achievement of OKR depends. It’s a bad idea to connect functional teams here, either separately with back-end vendors or separate fronts, because they are unlikely to be able to achieve their goals independently without the help of others. And the chance of achieving the goal is inversely proportional to the number of external dependencies of the team.
• The team must understand what problems are solved by the implementation of OKR . Ideally, if they already suffer from defocusing, lack of clear objectives, erosion of responsibility or other similar problems. This will help them even more high, if OKR will work as it should. The whole team should catch on the idea, and not perceive it as bureaucracy and formalism, so get ready to sell it to them.

To make your life easier, I decided to shuffle our OKR template . Google tables still cover most of the needs. Under the link next to the template is a PDF with instructions for working with it, use it.

Before proceeding further, let me remind you the general checklist for the implementation of OKR .

• Decide what goals you want to achieve by implementing OKR.
• Select a team that meets the criteria for maturity, and sell them OKR.
• After a quarter, connect a few more neighboring teams.
• Then add the top of the pyramid - the OKR of the company and carry out the binding of the targets.
• And then, if necessary, connect other intermediate links and new teams.

We set goals and formulate results

No matter what level of organization or implementation stage you are at. But it is very important to learn how to formulate goals and key results correctly and work with them. The OKR methodology is best suited for product teams. By them, I mean autonomous cross-functional teams that are united around some particular value-stream. And success in this part of the product depends entirely on them. When I continue to write about setting goals, I am guided precisely by this type. I will not consider all possible combinations of organizational structures and methodologies, but I believe that many of the practices will be applicable to situations other than ours.

We understand the identity of the team

Let's imagine that you are a team leader. In order to clearly address the issue of putting OKR, you first need to clearly define your place in the company and understand what your team should achieve in the long run. I call this process the search for one’s own identity, and the lack of understanding is called an existential crisis. Several tools can help you with this.

• The mission of the team is a simple and capacious definition of why the team exists.
• Long-term business goals . What exactly should a team achieve in a year or two horizon?
• Directions of work . If you cannot formulate either a mission or a goal, understanding the exact direction of the work can help you navigate in the face of uncertainty.

Understanding at least one, or rather several of these aspects, is imperative in order to approach the OKR staging process. Without such a compass, you will not be able to understand how the direction chosen by the team meets the needs of the business - you can be infinitely effective inside, achieve at first glance cool results, but not bring any benefit in the end.

We formulate goals

Suppose you figure it out and there are no problems. We proceed to the next - we formulate ourselves OKR. Let's start with the goals. When formulating a goal you need to follow a few simple rules. They should be related to what we have just discussed: mission, strategy, areas of work.

• The goal should not appear to the team from nowhere . The question “Why do you do it?” Should not rise, otherwise you did something wrong. OKR is about focusing on the important. Here there is, for example, a team that is responsible in the same Avito for the experience of buyers. The goal of “Improving ad quality” is understandable: better content, better user experience. But the goal of “Make our lib popular” raises many questions: is the team drawn at all to do this?

• Formulations should be qualitative, not quantitative . No "Increase conversion by half a percent." The goal sets the direction of movement, and not the length of the path. A good goal is to reduce the presence in the monolith. It does not indicate how much to specifically reduce, does not set the scale of measurement, nothing. Just shows the direction of work. But the story with the drank of five microservices is much worse - it starts to frame hard.

• Goals should be well remembered . This is another focus tool that allows the team not to spray their efforts and keep in mind what they are doing their job. And in order to be remembered, the goal must be expressed concisely, use the usual objective language, put pressure on something important for the team. “Breaking Craigslist” is memorable, loud, motivating. “To achieve a meaningful advance” is toothless, such a goal obviously will not enter aphorisms. She is what is, that is not.

• No bullshit and bureaucracy , otherwise the meaning will simply be lost. Use the same language, the same momentum as in normal speech. A minimum of common vague words.

• The goal should be set so that at the end of the quarter you can be proud of the progress on it . If you can objectively become leaders of the market only in two years, you do not need to set such a goal for a team, starting from the first quarter, because if there is no progress, positive reinforcement will disappear.

• The goal should be clear to everyone : from the developer to the CEO. If you leave goals too complex and based on some little-known details, the transparency factor is lost. On the one hand, all the OKRs lie in one file, on the other - no one understands anything anyway.

• There should not be many goals . Ideal - two or three per team. Adequate maximum - about five. It is clear that everything strongly depends on the texture, but, again, do not forget about the need to focus and highlight important.

Formulate key results

The next step is the formulation of key results. Compared to setting goals, this is a more difficult task. Practically all the practices of their language allow large deviations to the side.

• The key idea of ​​the KR is that they translate qualitative into quantitative , that very inspiring goal into concrete measurable quantities. And here is an important point: the key results should not simply relate to a common goal in any way, but translate it into a measurable category. In fact, of course, it turns out differently, sometimes a goal can act as an umbrella direction, which unites several separate streams within itself. For example, my teams now have a goal to “Increase the speed of feature delivery to the user”. This goal is already living with us for several quarters, and in addition to KRs directly describing it (frequency of releases), metrics like the number of canary releases or the stabilization of test benches fall into it. Directly they do not lead to an increase in the speed of delivery, but indirectly affect. Let's imagine that the team has a goal - to increase the length of the session. A good KR reveals the goal and shows how specifically we need to increase the length of the session and by what formula the result is considered. But in a bad example, a third-party initiative is indicated - the quality of the images in the ad definitely affects the session length positively, but not at all directly.

• One example of a bad key result is “Running a project”: 0 if it is not running, 1 if it is running. The main trouble with this approach to measurement is that during the quarter it is not at all visible whether the team is getting closer to the goal. She can have everything as well as horrible. But metrics don't show it. In the real world, such things are not always avoided, and sometimes they are accepted as a necessary evil. In this case, we are trying to decompose such a result into a set of smaller steps, which nevertheless reflect intermediate results . In general, the ideal case is when the metric is continuous (say, the same number of releases, conversion rates, or something else. Well, regardless of the scale chosen, it is important that key results can be measured as often as possible. For the purpose of "Increase release speed "a key result that indicates how many releases we specifically want is good. But stitching in on a specific initiative, besides poorly described, is definitely bad.

• The team must have full leverage on the selected results . This means that she either has all the necessary competencies, or can get them guaranteed in a short time. If any other team can critically affect the achievement of results, it becomes very risky. But it cannot be considered a contraindication to setting cross-team goals, you just need to clearly describe the limits of responsibility of each team, fix agreements and have a backup plan. In my memory there were quite a few cases when one of the teams could not cope with their part and then the second picked it up. The classic example is NPS. We learned from our experience that it cannot be used in the quarterly OKR, because it is very inertial. There may be more time between implementing some improvement and evaluating its effect on the NPS. But the same retention is a much more easily measurable parameter that can be influenced.

• The set of key results should be chosen so that they can be 100% fulfilled only under the most fortunate set of circumstances. The easiest way is achieved by the fact that every single KR is bullied a little higher than the confidence level of the team. Thus, it usually turns out that good results vary between 0.6-0.8 . Imagine that we are working in a company with cool financial forecasting. The scale between 97 and 102 percent of budget execution looks good. If we execute 100%, this is just 0.6. And for edinichki need a healthy challenge. A bad idea is to lift the bar too high and make the goal unrealistically ambitious: it will demotivate the team.

• The measurement scale you selected should show exactly the result, not the steps to achieve it . This is an important and useful rule, but it often breaks down to the fact that in order to start getting results, you must first develop some big project. And again it turns out that half a block passes, and the team still has nothing to say zero. Therefore, we often break such KR into several components. One of them shows the development progress, and the second - the results from its use. In KR there is no need to tell how many new products you plan to launch, these are just steps to achieve a specific result. In a good example, it is described explicitly - this is an increase in DAU.

Do not worry!

The biggest mistake you can make is to keep up the purity of compliance with all these principles. In real life, unfortunately, one often has to compromise and in some cases sacrifice one of the principles for the sake of another. If you do not do this, then you will get just synthetics, which looks good on paper, but is not very useful in operational management.

In general, while working on setting goals in different teams, I met a lot of different myths and cognitive distortions, which eventually turned out to be overcome. One of them is the confidence of the team that goals must change quarter by quarter, otherwise they will be considered a weak team. This degenerated into the fact that a number of directions were abandoned, not being carried through to the end. In fact, this is still not true.

Continuity of goals in OCD is welcome. There is nothing to worry about when the goal is held for several quarters, it is important to always achieve tangible progress on it.

Another example. The team has already decided exactly what it wants to do and what project to file, and then it is already trying to adjust the goal and metrics to it.

I can not say that it is directly antipattern. Indeed, it happens that the team has a great idea of ​​how to move forward in their global areas of work. Do not take it into account only because it does not fit into the methodology - it is stupid. But on the other hand, if such a project still does not really fall on the goals and metrics of the team, then perhaps this is offtopic.

Often I meet the conviction that OKR should describe everything the team does, including support stories and the fight against bugs.

I disagree with that. It makes sense to share OSes and creating new value, moving along the path to the goal. In OKR, you need to put out what we want to keep focus on, those goals, the achievement of which is really important for business.

And here is a funny example. The first quarters, when Avito only learned to live on OKR, the remarkable goal “To learn to measure something” went from team to team. Within its framework, metrics, deshbords were built, analytics were connected and other similar things were done.

I can not say that it is very bad. If a team has never thought about any metrics and measurements of its work, then it can really measure the whole quarter. Another question is whether to take it to the OKR level or leave it out of bounds. I have no definite answer, I have to look at the circumstances.

But really antipattern. The goal for some reason became irrelevant in the middle of the quarter, but the inertia team continues to pull it.

You can't do that. If the result of the activity is useless, neither the team nor its customers need it, then it’s silly to waste time on it. You need to reconsider your commit, notify interested parties about it, and move on with other goals.

But the story about the same 0.6-0.8, which many do not give rest. It's hard enough to accept the fact that you initially subscribe to failure.

You just have to look at it differently. First, the goals must still be achievable. If you take something in advance that you cannot do with it directly, then you don’t need to do that. Secondly, you need to tune yourself to success in any case, and try to figure out how to achieve your goal. It is then that the remarkable effect of the development of employees and the team, which gives OKR.

The product here is a common noun. Under it, you can keep in mind any leadership that puts down on the team invented goals. OKR don't work like that. OKR is the overall commitment of the whole team, under which they subscribe. If team members do not participate in their compilation, they will accept this commit and will not. Goals will be alien, motivation to achieve them - much less. All involvement disappears.

Building a rhythmic goal setting process

The process of setting OKR is not as easy and simple as we would like. On average, it takes us about a month at the junction of two quarters. It is clear that this is not a full-time job, but the team eats several hours a week. In Avito, the OKR staging process is organized plus or minus as follows.

Somewhere three weeks before the end of the quarter, the team is going to the first meeting. It is as follows.

• First, a review is made of the long-term goals of the team, company and other related structures.
• The next stage is a brainstorming of new goals, metrics, initiatives that will help either bring these long-term goals closer or fall under the responsibility of the team.
• Well, after the classic - the results are clustered and everything is digitized.

Then the most difficult stage begins - cyclical work on the OKR draft. Brainstorm results are recorded in the form of goals and key results. And each item from the list of the team begins to challenge from different positions - and performers, and stakeholders. Questions are asked about the priorities of goals, the correctness of the chosen path, the correctness of selected metrics, and many others. The main goal of this part is to ensure that all team members subscribe to the chosen goals and are confident that it is necessary to go this particular way. In parallel with this, the process of synchronization with other teams is underway, either at the level of general drafts or at separate meetings. Here there are agreements on cross-band projects.

And the last part is preliminary grooming of targets and roadmap compilation. Yes, according to the methodology, the team does not know how it will achieve the goal, but this does not prevent it from sensibly approaching the assessment and compiling the backlog of key initiatives.

, . , .

.

• , . , .
• . OKR , , .
• , . -, « , » - . .

.

, OKR, , . , .

, OKR . , — . - , .

, - . — - , - . : OKR , .

, .

, OKR Review. 5-6 , 10 : , , , . — , , .

OKR, . , OKR , .

. OKR . , , : , , OKR. , , OKR . , , OKR, - .

. : , , , . , , , ( ) — Action Items, . , .

• - . , . , .
• , , . , . KR — , .
• . , . , ? OKR — .

, , OKR.

• , . , — , . : , , , , .
• OKR , , . , , - , .
• . OKR , , , . , , .

OKR ?

, OKR . , OKR .

: , . , , . : R&D , . , . OKR , .

Data-driven

. , , . OKR .

Company Overview

— . , , , , . . OKR, , .

Total

OKR — , . , , . OKR , . , 4 OKR. , .

, OKR , . , .