September 27, 2012 at 08:28KPI, or Team Suicide Allowance
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 my own team, which I am incredibly awkward to recall. But more about that below.
Sooner or later, probably, each director has a desire to pay fairness. For the work done. And so many 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 achieved receive a bun (cash bonus).
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”, and as a result we got this picture:
Some companies (15%) use KPI to evaluate the efficiency of programmers' work and designers.
About 25% of companies are implementing KPI at the moment / meet resistance within the company or work on a simplified scheme.
Approximately 30% of companies pay wages based on subjective assessments of managers. Rather, 30% admit this ;-)
The remaining 30% do not admit.
The most interesting thing is that many have tried to implement KPI or are trying now. And not very successfully. This does not mean that "KPI is bad." Poorly cooked food is impossible. Maybe we just don’t know how to cook this KPI?
But statistics show that the vast majority have difficulties with implementation. And there is a suspicion that the same problem is common to all. Let's try to figure it out.
The question arises: what is the most hovering for developers when implementing 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 claims are related to the selection, consideration, transparency and adequacy of the criteria.
Well, those who understand everything, who will not soar anyone, who will simply be explained even at an interview. And so that everything was honest, and I wanted to work again and again.
In general, let's try to find Good Criteria. (By the way, “Good” - for whom?). We have three key affected stakeholders: studio owner, customer, and developers.
What could be a Good Criterion from a customer perspective? Usually it comes down to money (well, or some actual results):
However, the realities now are such that to come and offer, for example, to a designer, the dependence of his RFP on the ephemeral “customer satisfaction” is a guaranteed way to stay without a designer. A very serious crisis is needed for this topic to work. Or a lot of good extra designers.
OK. These Criteria Good for the customer will obviously not be Good for the developer. (I have no illusions, now you can easily come up with another 200 pieces of different criteria that are significant for business. Write, we will discuss in the comments :))
But you can measure PERFORMANCE! It's that simple!
Or not? How to measure it? If I painted the fence - then everything is obvious. But there is a catch. There are a lot of thinking, creative, talented people in our industry and no one paints fences. Let's look at the example of programmers. So, what Good Performance Criteria come to mind?
In our area, people work mainly because they are interested.
Do not bother them with stupid corporate rules.
Allows you to predict how many tasks the team will be able to type in the next step, depending on how much she completed in the previous one. The problems are the same as the focus factor, plus one more is added. Often the manager (especially inexperienced), sensing that the team’s performance can be "measured", begins to use this tool "the other way." But Velocity cannot be an exact criterion, as shows how much time the same task can take, performed by the same team under the same conditions. However, after completing the task, the team has already changed: she has gained experience on how to solve this particular problem. And the metric will not work again.
I personally really like this metric. One of the key that is worth measuring and optimizing. But developers do not directly affect this factor. This is too high level metric. If you start to pay a team a salary based on what Cycle Time they have, this means that you, as a leader, do not seek to solve the problems of the team and understand the processes, but simply transfer everything to the team.
An attempt to make a developer’s salary dependent 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 about ten indicators for this. And a dozen or two you can think of in the comments. Another question - is it worth making a developer’s salary dependent on indicators? But this is already risky.
I am starting to work, and doing my job is good, because I am a professional and I am interested. But if they start to slander me with stupid metrics, I will optimize these stupid metrics. I will write 1000 lines or draw 10 shit designs per day. And my interest in work will very, very quickly run out, I will stupidly want the dough. This is called a substitute for internal motivation - external.
Once “my good friend”, the head of the studio, got the idea to introduce a very fair remuneration, which would take into account a bunch of parameters. Naturally, they approached the matter on a grand scale. We wrote a whole bunch of criteria, such as:
- a monthly plan for worked man-hours and actually worked time;
- 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;
- growth in receivables;
- the number of bugs found by the client after the start of the project;
- reading books, writing articles.
And 20 more. (Useful list, take it away ;-)).
All this was brought together in one system. Naturally, the system had 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 a list of employees was drawn. Various “candy wrappers” were hung on the board - immediately, as soon as the payment arrived, the project ended or some good (or bad) event occurred that would affect the salary in the future.
Literally within 1 hour, the faces of employees became very, very gloomy. A few days later questions began: "why am I less candy wrappers?" or "why didn’t they give me a candy wrapper - did I help Vasya?"
The mood was becoming alarming. After a week, it began to take 4 times more time to evaluate projects than it did before, and each evaluation turned into an endless debate between the developer and the project manager. By the end of the month, few wanted to help a friend - they explained that “there is enough of their work”. An infinite number of situations were revealed that could not be formalized. Many candy wrappers were issued according to subjective feelings.
Few people wanted to work without candy wrappers, the tension grew. Productivity and motivation fell. A month later, the program was curtailed. After a couple of months, anxiety disappeared.
Different metrics are worth measuring and thinking-thinking-thinking, how to influence them. But do not transfer high-level metrics directly to developers and designers. And further.
Respect other people and give them the opportunity to do what they like)).
And the very last. There is a suspicion that each leader must understand for himself whether his organization is ready for the transition to KPI. I hope this small selection of articles that we have been able to collect will help in making the right decision.
- 68,338 kilometers for travel.
- 72 man-hours for mail correspondence.
- 423 man-hours for experiments with a team of 30 people.
- 88 hours for preparing reports and speaking at conferences.
- 17 cups of coffee for a conversation with wise people at the afterparty.
- About 25 hours for typing this text and editing bugs in it :).
- To death, 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 my own team, which I am incredibly awkward to recall. But more about that below.
Sooner or later, probably, each director has a desire to pay fairness. For the work done. And so many 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 achieved receive a bun (cash bonus).
The meaning of this approach: to pay in fairness. How much has worked out - so much has received. It’s honest, it’s logical, it’s wonderful!
Well, it’s logical that:
- Sales people need to assign a percentage of turnover. Wolves must be hungry. (Yes, there is an alternative opinion that applying this approach means “imposing an additional tax on yourself.” But as for me, everything is fair here :-)).
- Office plankton - salary. Stability for them is a very important condition for 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”, and as a result we got this picture:
Some companies (15%) use KPI to evaluate the efficiency of programmers' work and designers.
About 25% of companies are implementing KPI at the moment / meet resistance within the company or work on a simplified scheme.
Approximately 30% of companies pay wages based on subjective assessments of managers. Rather, 30% admit this ;-)
The remaining 30% do not admit.
The most interesting thing is that many have tried to implement KPI or are trying now. And not very successfully. This does not mean that "KPI is bad." Poorly cooked food is impossible. Maybe we just don’t know how to cook this KPI?
But statistics show that the vast majority have difficulties with implementation. And there is a suspicion that the same problem is common to all. Let's try to figure it out.
The first thing you have to face when implementing KPI is team resistance
The question arises: what is the most hovering for developers when implementing KPI?
After conducting several experiments and surveys among colleagues, we identified 6 main reasons:
- Fear of novelty. Everyone is totally afraid of innovations, thinking that it will get worse (less money, more work, etc.).
- Opaque layout. Using a material compensation scheme with many parameters, we increase the risk that employees will not understand it. It infuriates and demotivates people when they don’t understand how exactly they can achieve the best results or why they suddenly received less money.
- “Why is there so much?” Yes, that happens too. If the scheme is built in such a way that the result of this month will appear only after two or three. “This month I worked worse, but got more. So, the last time I got bored. Leadership - idiots, they don’t understand anything in my work! ”
- ChSV employee. It is almost impossible to get into a person’s sense of self and give him a “fair” bonus.
- Incomplete dependence of achievement of the criterion on the employee. For example, it doesn’t entirely depend on the designer whether the design he has drawn will be sold or if he will have to make 50 edits.
- Reports. I don’t know anyone who likes to write reports, put down time spent, promise “exact dates”.
If you look at this list carefully, you will find that most of the claims 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, who will simply be explained even at an interview. And so that everything was honest, and I wanted to work again and again.
In general, let's try to find Good Criteria. (By the way, “Good” - for whom?). We have three key affected stakeholders: studio owner, customer, and developers.
What could be a Good Criterion from a customer perspective? Usually it comes down to money (well, or some actual results):
- ROI - roughly speaking, this is the “return on financial injections”. The indicator deduced by economists is not entirely applicable to developers: after all, they cannot control the return on their work and measure it on the go in money. That is, they can not directly affect the indicator.
- Low cost features. It is beneficial for the customer to have a low cost feature. And for the developer, this is a break in the template (“How is it: do I get more money for working cheaply?”).
- Degree of satisfaction. I don’t know how to count it, but if you take into account that people want happiness or even less steam (© Dmitry Satin), then you can even suggest this formula:
However, the realities now are such that to come and offer, for example, to a designer, the dependence of his RFP on the ephemeral “customer satisfaction” is a guaranteed way to stay without a designer. A very serious crisis is needed for this topic to work. Or a lot of good extra designers.
- Date of release. Everything seems to be logical: we hand over the project on time - we get a lot of money, we give it ahead of schedule - we get even more money. The indicator is suitable, but has an already identified problem: not everything depends on the developer. The time lag most often arises from the client-manager side. (Hence the fair: “Why should I lose my salary, although this manager did not knock out content from the customer?”).
OK. These Criteria Good for the customer will obviously not be Good for the developer. (I have no illusions, now you can easily come up with another 200 pieces of different criteria that are significant for business. Write, we will discuss in the comments :))
But you can measure PERFORMANCE! It's that simple!
Or not? How to measure it? If I painted the fence - then everything is obvious. But there is a catch. There are a lot of thinking, creative, talented people in our industry and no one paints fences. Let's look at the example of programmers. So, what Good Performance Criteria come to mind?
- KSLOC. Do you know what it is? And what is the Hindu code - you know? Implement - you will find out. KSLOC is the number of thousands of lines of code. If you tie this indicator to the salary, then wait a thousand lines of copy-paste. A friend of mine got a completed order somewhere in Bangalore - a php script for only ten dollars, but for as much as 20 MB. And he worked!
- The amount of some shit per hour (WTF / h). The number of pages drawn per day, the number of features sold per hour, etc. It seems to be a normal metric - something can really be calculated and used to distribute the buns. However, a problem arises similar to the previous paragraph: a drop in quality to the detriment of quantity, an increase in technological debt. Motivation, interest, satisfaction - everything is rapidly falling down. As a result, the turnover and low qualifications.
- The number of bugs. The fewer bugs - the more we pay. Everything is logical, isn't it? Not really. Has a bug tracker been implemented in your studio? If so, forget it. Your testers will very soon agree with your programmers on how many bugs to write, and how many - not, so that this is not to the detriment of both sides.
- Recycling. “If you are late at work, you work poorly.” Is that logical too? We are struggling with processing, for example, we turn off the electricity after 18:00. However, one must remember here that the psychology of the developer is fundamentally different from the psychology of office plankton: if he sits until the evening, then he is interested (and this should be encouraged).
In our area, people work mainly because they are interested.
Do not bother them with stupid corporate rules.
- Focus Factor. This metric came to us from my favorite scrum. Shows how much the task should have taken ideally, and how much came out in the end. "Concentration" of the team over the project. Can I pay money based on this criterion? Quite, but if your managers are not “techies”, then programmers will deliberately overestimate their time estimates, minimizing their own risks. The consequence of this approach is that the time is stretched, the customer is indignant (or does not buy from you). Yes, and each meeting will turn into squabbles and disputes in 10 minutes.
- Velocity Also from scrum. The notorious "performance". Here it’s pretty unobvious, humanities can skip a paragraph.
Allows you to predict how many tasks the team will be able to type in the next step, depending on how much she completed in the previous one. The problems are the same as the focus factor, plus one more is added. Often the manager (especially inexperienced), sensing that the team’s performance can be "measured", begins to use this tool "the other way." But Velocity cannot be an exact criterion, as shows how much time the same task can take, performed by the same team under the same conditions. However, after completing the task, the team has already changed: she has gained experience on how to solve this particular problem. And the metric will not work again.
- Cycle time. How quickly time passes from the moment the idea arose to implement a feature on a project until the moment it was done.
I personally really like this metric. One of the key that is worth measuring and optimizing. But developers do not directly affect this factor. This is too high level metric. If you start to pay a team a salary based on what Cycle Time they have, this means that you, as a leader, do not seek to solve the problems of the team and understand the processes, but simply transfer everything to the team.
An attempt to make a developer’s salary dependent 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 about ten indicators for this. And a dozen or two you can think of in the comments. Another question - is it worth making a developer’s salary dependent on indicators? But this is already risky.
I am starting to work, and doing my job is good, because I am a professional and I am interested. But if they start to slander me with stupid metrics, I will optimize these stupid metrics. I will write 1000 lines or draw 10 shit designs per day. And my interest in work will very, very quickly run out, I will stupidly want the dough. This is called a substitute for internal motivation - external.
The story of one madness
Once “my good friend”, the head of the studio, got the idea to introduce a very fair remuneration, which would take into account a bunch of parameters. Naturally, they approached the matter on a grand scale. We wrote a whole bunch of criteria, such as:
- a monthly plan for worked man-hours and actually worked time;
- 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;
- growth in receivables;
- the number of bugs found by the client after the start of the project;
- reading books, writing articles.
And 20 more. (Useful list, take it away ;-)).
All this was brought together in one system. Naturally, the system had 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 a list of employees was drawn. Various “candy wrappers” were hung on the board - immediately, as soon as the payment arrived, the project ended or some good (or bad) event occurred that would affect the salary in the future.
Literally within 1 hour, the faces of employees became very, very gloomy. A few days later questions began: "why am I less candy wrappers?" or "why didn’t they give me a candy wrapper - did I help Vasya?"
The mood was becoming alarming. After a week, it began to take 4 times more time to evaluate projects than it did before, and each evaluation turned into an endless debate between the developer and the project manager. By the end of the month, few wanted to help a friend - they explained that “there is enough of their work”. An infinite number of situations were revealed that could not be formalized. Many candy wrappers were issued according to subjective feelings.
Few people wanted to work without candy wrappers, the tension grew. Productivity and motivation fell. A month later, the program was curtailed. After a couple of months, anxiety disappeared.
As a conclusion:
Different metrics are worth measuring and thinking-thinking-thinking, 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. To the heart - love and recognition.
3. Reason - development and self-improvement.
4. The soul - self-realization. "
S. Arkhipenkov
Respect other people and give them the opportunity to do what they like)).
And the very last. There is a suspicion that each leader must understand for himself whether his organization is ready for the transition to KPI. I hope this small selection of articles that we have been able to collect will help in making the right decision.
- On the dangers of bonuses (Joel Spolsky).
- Do not bother me to work (Stas Davydov).
- Monetary motivation in software development projects (Askhat Urazbaev).
- Metrics in Agile (meeting AgileRussia.ru
2009-08-18). - Basic indicators of the percussionists of capitalist labor (Larisa Kharakhinova).
- How much do developers need to 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).
- What 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 an employee with gingerbread? Or methods of motivation (Valentin Polyakov).
- Why programmers are not paid in proportion to their productivity (Habrahabr, translation).