KPI, or command suicide manual
To write this note was spent:
A lot of money and time. Perhaps the most costly (in terms of nerves, time and money) was an experiment on one’s own team, which I’m incredibly awkward to recall. But more about that - below.
')
Sooner or later, probably, every director has a desire to pay justice. For completed work. And many people are now trying to implement KPI (key performance indicators). It works like this: you, as a business owner, set specific goals for employees. They achieve or do not achieve their goals in the process. Those who have reached - is given a bun (monetary award).
Well, it’s logical that:
But with creative units (designers, programmers) - everything is much more complicated.
We recently conducted a survey of the leaders of leading digital agencies and web studios of the country on the topic “how do you use KPI in relation to the work of creative units,” as a result we got this picture:
Some companies (15%) use KPI to evaluate the effectiveness of the work of programmers and designers.
About 25% of companies are implementing KPIs at the moment / they meet resistance within the company or work in a simplified way.
Approximately 30% of companies pay for employees on the basis of subjective evaluations of managers. Rather, 30% admit it ;-)
Do not admit the remaining 30%.
The most interesting thing is that many have tried to implement KPI or are trying now. And not very successful. This does not mean that "KPI is bad." Poorly cooked food is impossible. Maybe we just do not know how to cook this KPI?
But statistics show that the overwhelming majority have difficulties in implementing. And there is a suspicion that the problem is common for everyone. Let's try to figure it out.
The question arises: what is the most soaring developers in the implementation of KPI?
After conducting several experiments and surveys among colleagues, we identified 6 main reasons:
If you look at this list carefully, you will find that most of the complaints are related to the selection, consideration, transparency and adequacy of the criteria.
Well, those who understand everything, who will not soar anyone, which will be easy to explain, even at the interview. And so that everything was honest, and I wanted to work more and more.
In general, let's try to find good criteria. (By the way, “Good” - for whom?). We have three key affected stakeholder: studio owner, customer and developers.
What could be a good criterion from the point of view of the customer? Usually it all comes down to money (or some actual results):
However, the realities now are such that to come and offer, for example, a designer, the dependence of his salary on ephemeral “satisfaction” of a customer is a guaranteed way to remain without a designer. A very serious crisis is needed for this topic to start working. Or a lot of good extra designers.
OK. These criteria, Good for the customer, obviously, will not be Good for the developer. (I am without illusions, now you can easily come up with another 200 pieces of different criteria relevant to business. Write, discuss in the comments :))
But you can measure productivity! It's so easy!
Or not? What is its measure? If I painted the fence, then everything is obvious. But there is a catch. In our industry a lot of thinking, creative, talented people and fences no one paints. Let's look at the example of programmers. So, what good performance benchmarks come to mind?
In our field, people work mainly because they are interested.
Do not disturb them with stupid corporate rules.
Allows you to predict how many tasks the team will be able to type in the next stage, depending on how much it has completed in the previous one. The problems are the same as for the focus factor, plus one more is added. Often the manager (especially inexperienced), who feels that the team’s performance can be “measured”, begins to use this tool “in the other direction”. But Velocity cannot be an exact criterion, since shows how long the same task can take, performed by the same team under the same conditions. However, after completing the task, the team has already changed: it has gained experience in how to specifically solve this task. And the metric will not work again.
I personally love this metric. One of the key, which is worth measuring and optimizing. But developers do not directly influence this factor. This is a high level metric. If you start to pay the team a salary on the basis of what Cycle Time they have, it means that you, as a manager, do not strive to solve the team’s problems and understand the processes, but simply transfer everything to the team.
An attempt to put a developer’s salary dependence on a high-level metric is evidence of managerial impotence
So, is it possible to measure the effectiveness of a team? Yes, it is possible, especially since we have written a dozen of indicators for this. And a dozen more can be thought up in the comments. Another question - is it worth making a developer’s salary dependent on indicators? But this is already risky.
I start to work, and I do my job - well, because I am a professional and it is interesting to me. But if stupid metrics are starting to spread me, I will optimize these stupid metrics. I will write 1000 lines or draw 10 designs per day. And my interest in work will very quickly run out, I will stupidly want a dough. This is called the substitution of internal motivation - external.
Once, “my good friend”, the head of the studio, had the idea to introduce a very fair salary, where a lot of parameters would be taken into account. Naturally, the case came on a grand scale. Wrote a whole bunch of criteria, like this:
- Monthly plan for man-hours worked and actual hours worked;
- quarterly sales plan;
- the number of wards and their salaries;
- the amount of positive communication from customers (satisfaction);
- the number of repeated customer requests with new projects;
- awards at specialized contests;
- negative communication with the client;
- the number of bugs found by QA;
- increase in accounts receivable;
- the number of bugs found by the client after the start of the project;
- reading books, writing articles.
And still pieces 20. (useful list, take away ;-)).
All this was consolidated into one system. Naturally, the system needed to be balanced. Therefore, in the first few months it was decided to calibrate it on virtual "candy wrappers". A large board was invented on which to draw a list of employees. Various “candy wrappers” were posted on the board - as soon as the payment arrived, the project was completed or some good (or bad) event occurred that would have an impact on the salary in the future.
Literally within 1 hour, the faces of the staff became very, very gloomy. A couple of days later, the questions began: “why do I have less candy wrappers?” Or “why didn’t they give me a candy wrapper - did I help Vasya?”.
The mood was getting alarming. After a week, the evaluation of projects began to go away 4 times longer than it used to go before, and each evaluation turned into an endless dispute between the developer and the project manager. By the end of the month, very few people wanted to help a friend - they explained that “there is enough of their work”. An infinite number of situations that could not be formalized revealed. Many candy wrappers were issued on the subjective sensations.
Few people wanted to work without candy wrappers, the tension grew. Productivity and motivation - fell. A month later, the program turned. After another couple of months, anxiety disappeared.
Different metrics should be measured and thought-think-think how to influence them. But do not transfer high-level metrics directly to developers and designers. And further.
Respect other people and let them do what they like)).
And quite the last. There is a suspicion that every manager himself must understand whether his organization is ready for the transition to KPI. I hope this small selection of articles that we managed to collect will help in making the right decision.
- 68338 kilometers on the trip.
- 72 man-hours for mail correspondence.
- 423 man-hours for experiments with a team of 30 people.
- 88 hours to prepare reports and speeches at conferences.
- 17 cups of coffee for conversation with wise people on afterparty.
- About 25 hours to type this text and edit bugs in it :).
- A tortured copywriter who was forced to disassemble my drafts, audio recordings and in general thanks to him.
A lot of money and time. Perhaps the most costly (in terms of nerves, time and money) was an experiment on one’s own team, which I’m incredibly awkward to recall. But more about that - below.
')
Sooner or later, probably, every director has a desire to pay justice. For completed work. And many people are now trying to implement KPI (key performance indicators). It works like this: you, as a business owner, set specific goals for employees. They achieve or do not achieve their goals in the process. Those who have reached - is given a bun (monetary award).
The meaning of this approach: pay fairly. How much has gained - and got so much. This is honest, this is logical, this is beautiful!
Well, it’s logical that:
- Salespeople need to assign a percentage of turnover. Wolves must be hungry. (Yes, there is an alternative opinion that applying such an approach means “to impose an additional tax on you.” But as for me, everything is fair here :-)).
- Office plankton - to put a salary. Stability for them - sooo important condition of existence.
But with creative units (designers, programmers) - everything is much more complicated.
We recently conducted a survey of the leaders of leading digital agencies and web studios of the country on the topic “how do you use KPI in relation to the work of creative units,” as a result we got this picture:
Some companies (15%) use KPI to evaluate the effectiveness of the work of programmers and designers.
About 25% of companies are implementing KPIs at the moment / they meet resistance within the company or work in a simplified way.
Approximately 30% of companies pay for employees on the basis of subjective evaluations of managers. Rather, 30% admit it ;-)
Do not admit the remaining 30%.
The most interesting thing is that many have tried to implement KPI or are trying now. And not very successful. This does not mean that "KPI is bad." Poorly cooked food is impossible. Maybe we just do not know how to cook this KPI?
But statistics show that the overwhelming majority have difficulties in implementing. And there is a suspicion that the problem is common for everyone. Let's try to figure it out.
The first thing you will encounter when implementing KPI - the resistance of the team
The question arises: what is the most soaring developers in the implementation of KPI?
After conducting several experiments and surveys among colleagues, we identified 6 main reasons:
- Fear of novelty. Everyone is totally afraid of innovation, thinking that it will become worse (less money, more work, etc.).
- Opaque scheme. Using a material compensation scheme with many parameters, we increase the risk that employees will not understand it. People are angry and demotivating when they don’t understand how they achieve the best results or why they suddenly got less money.
- "And so much?" Yes, it happens too. If the scheme is constructed in such a way that the result of this month will appear only after two or three. “This month I worked worse and got more. So, the last time I was not given. The leadership is idiots, they do not understand anything in my work! ”
- ChSV employee. It is almost impossible to get into a person’s self-perception and give him a “fair” bonus.
- Incomplete dependence of the achievement of the criterion of the employee. From the designer, for example, it does not quite depend on whether the design drawn by him will be sold or you will have to make 50 edits.
- Reports I do not know anyone who likes to write reports, record time spent, promise "exact dates."
If you look at this list carefully, you will find that most of the complaints are related to the selection, consideration, transparency and adequacy of the criteria.
OK. So you just need to come up with good criteria!
Well, those who understand everything, who will not soar anyone, which will be easy to explain, even at the interview. And so that everything was honest, and I wanted to work more and more.
In general, let's try to find good criteria. (By the way, “Good” - for whom?). We have three key affected stakeholder: studio owner, customer and developers.
What could be a good criterion from the point of view of the customer? Usually it all comes down to money (or some actual results):
- ROI - roughly speaking, this is “return on financial injections.” The indicator derived by economists is not entirely applicable to developers: after all, they cannot control the returns from their work and measure it in money on the go. That is, they can not directly affect the indicator.
- Low cost features. It is beneficial for the customer to have a low cost of features. And for the developer, this is a template break (“How is this: do I get more money for cheap work?”).
- Degree of satisfaction. I don’t know how to count it, but if one considers that people want happiness or at least take a steam bath (© Dmitriy Satin), then we can offer even this formula:
However, the realities now are such that to come and offer, for example, a designer, the dependence of his salary on ephemeral “satisfaction” of a customer is a guaranteed way to remain without a designer. A very serious crisis is needed for this topic to start working. Or a lot of good extra designers.
- Date of release. It seems to be all logical: we hand over the project on time - we get a lot of money, we hand over it ahead of time - we get even more money. The indicator is valid, but it has already indicated a problem: not everything depends on the developer. A deadline in terms most often arises from the client-managerial side. (Hence the fair: “Why should I lose in salary, although this manager did not dislodge the content from the customer?”).
OK. These criteria, Good for the customer, obviously, will not be Good for the developer. (I am without illusions, now you can easily come up with another 200 pieces of different criteria relevant to business. Write, discuss in the comments :))
But you can measure productivity! It's so easy!
Or not? What is its measure? If I painted the fence, then everything is obvious. But there is a catch. In our industry a lot of thinking, creative, talented people and fences no one paints. Let's look at the example of programmers. So, what good performance benchmarks come to mind?
- KSLOC. Do you know what it is? And what is the Hindu code - you know? Embed - learn. KSLOC is the number of thousands of lines of code. If you tie this figure to the salary, then wait for a thousand lines of copy-paste. A friend of mine received a fulfilled order somewhere in Bangalore - a php script, for only ten dollars, but as much as 20 MB. And he worked!
- The amount of some crap per hour (WTF / h). The number of pages drawn per day, the number of features implemented per hour, etc. It seems to be a normal metric - something can be really calculated and used for distribution of buns. However, a problem arises that is similar to the previous point: a decline in quality at the expense of quantity, an increase in technological debt. Motivation, interest, satisfaction - everything is rapidly falling down. As a result, routine and low qualifications.
- The number of bugs. The fewer bugs - the more we pay. Everything is logical, is not it? Not really. Is there a bugtracker in your studio? If yes - forget it. Your testers will very soon agree with your programmers about how many bugs to write, and how many - not, so that it is not to the detriment of both parties.
- Recycling. "If you stay at work, you work poorly." Is it logical, too? We are struggling with the processing, for example, turn off the electricity after 18:00. However, here we must remember that the developer's psychology is fundamentally different from the office plankton's psychology: if he sits until the evening, then he is interested (and this should be encouraged).
In our field, people work mainly because they are interested.
Do not disturb them with stupid corporate rules.
- Focus Factor. This metric came to us from my favorite scram. It shows how much the task should have taken, ideally, and how much it turned out as a result. "Concentration" of the team on the project. Can I pay money based on this criterion? Quite, but if your managers are not “techies,” then programmers will deliberately overestimate estimates in time, minimizing their own risks. The consequence of this approach is that the terms are stretched, the customer is indignant (or is not buying from you). Yes, and each planning meeting will turn into squabbles and disputes in 10 minutes.
- Velocity. Also from scram. The notorious "performance." It is not obvious here, the humanities may skip the paragraph.
Allows you to predict how many tasks the team will be able to type in the next stage, depending on how much it has completed in the previous one. The problems are the same as for the focus factor, plus one more is added. Often the manager (especially inexperienced), who feels that the team’s performance can be “measured”, begins to use this tool “in the other direction”. But Velocity cannot be an exact criterion, since shows how long the same task can take, performed by the same team under the same conditions. However, after completing the task, the team has already changed: it has gained experience in how to specifically solve this task. And the metric will not work again.
- Cycle time. How quickly time passes from the moment when the idea to implement a feature on a project arose, up to the moment it was made.
I personally love this metric. One of the key, which is worth measuring and optimizing. But developers do not directly influence this factor. This is a high level metric. If you start to pay the team a salary on the basis of what Cycle Time they have, it means that you, as a manager, do not strive to solve the team’s problems and understand the processes, but simply transfer everything to the team.
An attempt to put a developer’s salary dependence on a high-level metric is evidence of managerial impotence
So, is it possible to measure the effectiveness of a team? Yes, it is possible, especially since we have written a dozen of indicators for this. And a dozen more can be thought up in the comments. Another question - is it worth making a developer’s salary dependent on indicators? But this is already risky.
I start to work, and I do my job - well, because I am a professional and it is interesting to me. But if stupid metrics are starting to spread me, I will optimize these stupid metrics. I will write 1000 lines or draw 10 designs per day. And my interest in work will very quickly run out, I will stupidly want a dough. This is called the substitution of internal motivation - external.
The story of one madness
Once, “my good friend”, the head of the studio, had the idea to introduce a very fair salary, where a lot of parameters would be taken into account. Naturally, the case came on a grand scale. Wrote a whole bunch of criteria, like this:
- Monthly plan for man-hours worked and actual hours worked;
- quarterly sales plan;
- the number of wards and their salaries;
- the amount of positive communication from customers (satisfaction);
- the number of repeated customer requests with new projects;
- awards at specialized contests;
- negative communication with the client;
- the number of bugs found by QA;
- increase in accounts receivable;
- the number of bugs found by the client after the start of the project;
- reading books, writing articles.
And still pieces 20. (useful list, take away ;-)).
All this was consolidated into one system. Naturally, the system needed to be balanced. Therefore, in the first few months it was decided to calibrate it on virtual "candy wrappers". A large board was invented on which to draw a list of employees. Various “candy wrappers” were posted on the board - as soon as the payment arrived, the project was completed or some good (or bad) event occurred that would have an impact on the salary in the future.
Literally within 1 hour, the faces of the staff became very, very gloomy. A couple of days later, the questions began: “why do I have less candy wrappers?” Or “why didn’t they give me a candy wrapper - did I help Vasya?”.
The mood was getting alarming. After a week, the evaluation of projects began to go away 4 times longer than it used to go before, and each evaluation turned into an endless dispute between the developer and the project manager. By the end of the month, very few people wanted to help a friend - they explained that “there is enough of their work”. An infinite number of situations that could not be formalized revealed. Many candy wrappers were issued on the subjective sensations.
Few people wanted to work without candy wrappers, the tension grew. Productivity and motivation - fell. A month later, the program turned. After another couple of months, anxiety disappeared.
As output:
Different metrics should be measured and thought-think-think how to influence them. But do not transfer high-level metrics directly to developers and designers. And further.
“The developer consists of four components: body, heart, mind and soul.
1. The body needs money and security.
2. Heart - love and acceptance.
3. Reason - development and self-improvement.
4. Soul - self-realization.
S. Arkhipenkov
Respect other people and let them do what they like)).
And quite the last. There is a suspicion that every manager himself must understand whether his organization is ready for the transition to KPI. I hope this small selection of articles that we managed to collect will help in making the right decision.
- About the dangers of bonuses (Joel Spolsky).
- Do not interfere with my work (Stas Davydov).
- Monetary motivation in software development projects (Askhat Urazbayev).
- Metrics in Agile (meeting AgileRussia.ru
2009-08-18). - Basic indicators of capitalist labor drummers (Larisa Kharakhinova).
- How much should developers pay (Habrahabr, translation).
- Business Intelligence (Habrahabr, V.P. Savchuk).
- Motivation of IT-specialists (Habrahabr).
- Balanced Scorecard as a tool for managing a company / division (Habrahabr).
- Which KPIs can be measured if the schedule and budget are not very important (Habrahabr).
- Performance indicators (KPI) for IT employees (Habrahabr).
- Myths of motivation. Breaking the deadlock (Reinhard Sprenger).
- Employee motivation methods (Julia Lavrik).
- Benefit: how to kill employee gingerbread? Or methods of motivation (Valentin Polyakov).
- Why programmers are not paid in proportion to their productivity (Habrahabr, translation).
Source: https://habr.com/ru/post/152445/
All Articles