Why are goals needed? How should they be formulated? What problems can arise? On the occasion of Y. Subbotnik Pro, I prepared a report based on several years of experience in setting goals for teams in Yandex.
- I'll tell you a little about myself, in the context of why you should listen to my report. I lead a team that is now called management. I've been working here for quite a long time, I've seen a lot of things - the whole evolution of how management is arranged in such a large company, how we lead goals.
I also love tools and methodologies, from development to company-wide. And recently, I, among other things, head the department that is engaged in the creation of our internal tools.
Disclaimer: what won't I cover in my talk? I will not tell you all sorts of encyclopedic definitions - what are SMART, OKR, KPI. All this has already been stated a hundred times in Wikipedia. You've probably heard all these things yourself. If not, a quick search with your favorite search engine will give you the answer. It is full of very good articles. I checked it literally tonight.
What will I tell you about? I will try to share with you such a rather personal experience. And the experience that we have in Yandex about goal setting. I will show you a number of good examples and try to set out warnings - what things, it seems to me, should be taken into account and what rakes should not be stepped on.
This is an experimental talk in an area that is not quite usual for me. Therefore, if you ask questions, I may be able to tell more and more substantively what you need.
Why lead goals?
What does this have to do with you? First, I expect that there are people among you who set goals themselves. And I think it will be useful for you to hear about the experience in order to set goals better. Second: even if you yourself do not set goals right now, but simply achieve them, a common understanding of the methodology and principles will help you achieve them better.
Most likely, the audience present both sets goals and achieves. I myself belong to such people. Usually the person in the middle position is involved in both threads. So I hope it will be interesting and useful to everyone.
Let's talk a little about why setting goals at all. I have several quotes that I heard at different times from different colleagues and acquaintances: they say, all this is bureaucracy, instead of setting some goals and writing tasks, just do it normally, and everything will work out fine. No need to invent anything, no need to waste time on this.
The second popular wisdom is that you just have to work very, very hard, take more and throw away, do not forget to rest. Such hard work will grind everything, and it will not matter what your goals are. This is all, of course, true. But only partially.
Even if you are a very good developer and you work very, very well, there will still come a time when you don’t have enough hands to do everything. And you will have to answer the question: what to undertake in the first place, what exactly to do right now? I have a finite time slice, and more needs to be done. We need prioritization.
Second, if you are a leader, then a problem arises - one and the same thing can be done in a very wide range of different ways. And you need to understand how to review what your subordinates have done.
I have a talk about our review system. There I talk in more detail about how our internal RPG works: with levels, level-ups, ratings, etc.
Watch the report
Life cycle
Let's talk about the life cycle. Actually, I’ll pass on to an exposition of how it works in our country.
I picked up such pictures. What do we see here? Surely, many are familiar with the stages of the life cycle of almost any thing - we aim, shoot, look where we hit. Usually, in the Agile world, this is like sprint planning. Or retro, or demo - who can do it.
But I like to design processes so that complex things can be expressed through simple formulas and principles and scaled fractally. The picture with the Mandelbrot fractal hints to us about this.
What do we have? Different parts of our process fractal. There are six-month employee review intervals.
Every three months - midreview, where we summarize the interim results of the review period.
Once a month, there are greenlights where teams tell related teams what happened on targets. This is necessary so that the commands are synchronized with each other.
And those two-week sprints.
As you can see, the result is a fractal picture, very similar to the methodology that you need to first aim, understand what exactly you will do, do it, and then look at the result.
This is very important because the people who give the aforementioned advice from folk wisdom are closed in the middle picture. They just shoot. Plus or minus they don't aim, plus or minus they don't look where they hit. And this gives much less predictable and controllable processes than if you follow such a simple three stages.
It's like every report should have an introduction, body and conclusion. Likewise, every goal-directed action must have a goal-setting, execution and summing up.
So that these results can be summed up, so that goal-setting can also be done, in order to aim correctly, such an important property as measurability is needed.
In the story about measurability, I will give an anti-example. I have a winged (within Yandex) concept - "checkbox" goals.
Checkbox goals
This is an anti-pattern. Your goals are most likely not very good if they sound like "make a new version of component X", "start service Y" or "refactor Z". Why is that bad?
- , , . . , , , - : , , , , . , .
«», — X? ? - , . , , . — « X», - .
- Assessment of the result becomes more complicated. For example, you need to evaluate two teams. Without the process of review and calibrations, you will not be able to find that one team has done a blunder, MVP-style, and the second has done everything well, for centuries and in great detail.
Therefore, my recommendation is to try to avoid "checkboxing" goals, try to translate them into a more measurable plane.
Creating a metric and defining targets is part of working on a goal
The question may arise that something is very difficult to measure. And sometimes you have to start running. It is already clear that you need to do service X or refactoring Y, but there are still no metrics that would allow you to measure this. We don't understand what targets we want to set ourselves as a target picture. How to be?
We use the pattern that the very process of creating metrics and determining targets is already part of the work on the goal. It is not necessary to block the beginning of work on a goal if you have not fully formulated it.
I'll give you a couple of examples from our real-world goals. Yandex has a team that deals with the so-called Beauty of the Sickle, making it more beautiful. When she appeared, there was only a general idea. Here you are so many people, do it.
The team did not even know what beauty is and how many percent of this unknown beauty can be changed. However, they started to work in parallel. There was an intuitive opinion that some things are more beautiful, and let's do this. And in parallel, they began to come up with a system that would measure this very beauty. And as a result, we got a system, a metric, which Anton Vinogradov told about in his report “Yandex Beauty: Design for Millions”:
Watch the report
The essence of the system: we make a side-by-side comparison of the old version and the new one. Then we calculate the sum of positive changes from each of our implementation over a certain period of time.
In the first semester of work on this goal, we formulated a metric. We made a sight as a percentage - a little from the ceiling. In the next semester, based on how well we did it, we already understood how this metric moves, what implementations affect it, what you might want there.
The second example in the context of working on metrics is one of our oldest contours, the team that deals with the speed of interfaces.
When it started, there was also a general message: please make the Sickle load faster. But how to measure whether it is fast or not? There were complaints like: “I'm opening it on my phone, it seems to me something is slow. The competitors' search engines are faster! " To start doing this work, it was not necessary to formulate exactly the metric. We knew commonplace things: if you send a lot of bytes over the network, run a lot of code in JS, it will take a long time. Let's start doing something, and along the way collect real metrics, understand how we will measure it.
There is also a report on this. Andrey Prokopyuk told about all our details of how speed is measured on real users and on synthetic measurements inside:
Watch the report
At the same time, the guys worked to achieve a meaningful goal - to reduce these same bytes.
Measure the immeasurable
The next question that may arise: well, we want to measure and it is more or less clear at the speed of the frontend - there is a ruler that allows us to detect bytes. But how can you measure something generally immeasurable? With beauty you came up with side-by-side, what if there is nothing? For example, you need to measure the happiness of users in internal development.
First, it's worth thinking again. As I said, with the same beauty that seemed subjective, we were able to derive a more measurable metric.
Secondly, you can think about proxy metrics. Here I will also send you to your favorite search engine: you can find many articles about what a proxy metric is and how to select it. In short, the proxy metric allows you to indirectly approximate your real state of affairs, to make assumptions like: "If we continue to be used a lot, our interface is probably not so bad."
It is clear that this will have some degree of error and permissibility. But if you impose a sufficient number of proxy metrics, in the end you can get an approximation good enough, which will not require the creation of a large complex metric.
The latter was suggested in the comments to my previous report: it is always possible for any very immeasurable subject to gather a jury of users or experts and ask them to rate them on a scale. Do this regularly and thus get a coordinate system, a reproducible metric that will allow you to understand if you are progressing correctly. Even this metric will still be better than those "checkboxing" goals. Like Porthos: "I fight just because I fight!"
A couple of keywords to help with user surveys: csi nps. But I think the idea is clear.
Antibug metric
Another example is about the antibug metric. We have a special process that allows us to improve the quality of our interfaces and make them less bugs.
Now I'll tell you how it works. Several points can be illustrated on it.
First, we have built summary graphs of the weighted number of bugs for teams. That is, we count the number of emerging bugs in the floating window and assign them weights in proportion to their priority. We have minors, trivials, normals, critics and blockers that differ from each other by an order of magnitude. The minor and trivial have a weight of 1, the normal has 10, the critic has 100, and the blocker has 1000. The result is a graph that reflects how many bugs are currently on the service, taking into account their priorities.
Second, we began to build such graphs separately for bugs that the team itself and the team's testers found, and for those that were reported by external users. Then we suspended the component of the target, carried out the target. Within us, this process is called zero bug policy. But it is clear that zero is such an unattainable ideal, and each team may have a different zero at any given time. There a threshold is defined - that the weight is not more than 50 or 100.
If the team is just starting to work on the antibug, we say that it should be reduced by 20% every month. There are six months in the semester, five months for a decrease of 20%, plus another month to keep this result. Thus, it is possible for a semester to reach the target value and have a small number of bugs.
The antibug metric is 20% based on the principle that there should be more bugs found on their own than user bugs. That is, testing on the project should work better, and users should find fewer bugs than we do.
The last criterion is compliance with the closing SLA. Even if you don't have many bugs, but they have been hanging for a long time, this can annoy users: the number of people affected by a bug in production grows every day until this bug is cured.
And here are two points. In addition to the methodology of how we measure, estimate this weight and the number of bugs, there is another example of how you can combine several different criteria into one metric.
You simply put weights and percentages on these criteria and say that one affects 40%, the second 20%, the third 40%. Here is an example, and this metric allows more or less unified work on the antibug to be distributed among dozens of teams in Yandex.
We come back to the keyword "balance". You have to try to find it. I will tell you about several balances that you need to keep in mind when you are doing the goal setting process.
The first is a balance between "too few goals" and "too many goals". There shouldn't be too few goals, because it won't be ambitious enough for the team. You just won't utilize your full potential. Too much is also bad: starting at some point, the overhead of recognizing and maintaining a goal will become too large. They will accumulate in total and will bother you.
We have a couple of such examples. For example, there was a team that consisted of eight people. They had about six goals. They said: “As a team, we cannot keep track of six targets at once. We need to track them on greenlights, constantly understand whether each of them is progressing well with us. Let's split into two teams of four and distribute these three goals to one team, the other three to another. This is a working method that ultimately allows you to focus people a little more narrowly on a specific goal.
The next balance is the balance between our desires and capabilities. If there is no balance in the team that is engaged in goal-setting, then very often there is a bias in one direction or the other. Suppose you have a strong top management and he tells you: "We definitely need to do this." And all goals are set from our desires - we want this to happen, and whatever you want, "take it out and put it down." Such a situation may be fraught with the fact that these desires will not be aligned with reality and simply will not be fulfilled.
In addition, the imbalance is if the sailors seized power on the ship. Then the team will try to formulate goals in such a way that everything is accurately, guaranteed. As I said, this is fraught with the underutilization of your potential. There should always be a challenge, a way out of your comfort zone, a point where you reach. Through tension, evolution occurs. It is important that this tension is not such that you tear your ligaments. It should be developing. And this balance must be sought.
There is also a balance between the so-called width and depth. There is always a choice, which is better - to work out a goal in detail, but only one, or to get many goals, but in the end not have time to work out each of them at least to some extent. There are no universal advice here, because life situations are very different. Some threads are very important to support at least somehow, and in this sense the width is needed. For example, brushing your teeth, eating, playing sports, working are all equally important threads. Here it is impossible to say - let me brush my teeth very well for the first month, three times a day, next month I will go in for sports very well, etc.
But there are also reverse situations, when it is important for us to work it out to the end, it is good to close some issue and then move on. And don't start two repairs at the same time. If possible, you can first do one thing, invest well, follow it, and then do another.
We need a balance between the two formulations: "reorient in time to the changed reality" and "surrender at the first difficulties." Sometimes you can start doing something and find that the tasks are more difficult than expected. Or external factors have happened, such as coronavirus or something else. It is very tempting, being guided by the Agile principle, to flexibly adapt to the changed reality and, for example, to underestimate your KPI, give up some goals or something else. Here we find ourselves in the same situation as in the initial goal-setting, only in dynamics.
Make sure that you do not give up at the first difficulties, even in dynamics, when you continue to change the weight distribution of targets, but also do not bang your head against the wall when this no longer gives any result.
The last thing I want to talk about on this slide is about the balance between different goals. Sometimes goals start to conflict with each other.
In this particular place, we have clear methodologies for exchanging one for the other. But it is also important to assess the rest, the same conflicting goals from a sufficient distance. In what form could one exchange one for another?
And a couple of such analogies and pictures about balance. It, in the form in which I formulate it for myself, is of two types:
- « ». — , , - — , .
, . : « , ». , , . , : . - «». , , . . , : - . , , . , , .
At the end, I wanted to reproduce everything I said and show you the slides again. But there weren't so many of them, and they seem more or less understandable.
A short summary of the entire report: Goal setting is difficult. You may find that goal setting itself takes up a significant amount of time. But it's worth it! At least this is my value judgment based on my personal experience.
I am very glad that we have generally come to a system with goals and continue to evolve and improve it. All these efforts, it seems to me, are paying off.
There could be an advertisement for our or any of your tools, because give or take any tool for conducting tasks or goals can be used. Just search your favorite search engine for [your tool name, space, targets]. You will surely find an article that describes exactly how to do this. Thank you for attention. I wish you all the same successful hitting as in this gif.
