June 7, 2015 at 23:09Does production run the company, or is the company manufacturing?
We want to share information with the community about how we figured out who controls whom (manager vs programmer) and how we changed the strategy for managing developers.
One of the goals was to get rid of what is in the picture:
Our story began like everyone else:
First, oral instructions to employees: do it, do it, why did you forget? Well, of course, that won’t do that.
Then came the task manager. First, BugZilla, then Mantis, then an attempt to switch to JIRA, then Redmine (it’s worth confessing, we’ve been stuck for 6 years), and then switched to our OneBox . But, these are just task managers; they do not set a strategy for the sequence of task selection and performance indicators.
What happens when you have a task manager? A manager (for example, Project manager) assigns tasks, distributes them among developers. But there are two BUT:
The question arises: does anyone even control the process?
If we add to this all the hourly pay of developers for the time spent, we get a real hell:
A second question arises: who controls whom? Programmer manager or programmer all?
We had such a scheme for 5 years. And instead of recognizing the curvature of this scheme, we first came up with a crutch “and let's ask the developers to estimate the time”. This cool idea led to:
Therefore, the developers quickly figure out that it is necessary to overestimate the estimate a couple of times and do it as quickly as possible (quality suffers): I named 20, and now I will do it for 10, and even better for 5. Wow, what a fellow I am.
In total, it took us more than 6 years to admit that things would not go any further. To recognize that the developers (and they are essentially manufacturing) are managing the company, not the company manufacturing.
Paying for hours, the freedom of choosing a task by developers is all uncontrollable processes, and all attempts to control them come down to inventing crutches on crutches.
And we radically changed the scheme:
It got better, much better. We didn’t ask “what is developer X doing now,” because we knew what his task was in the plan now under priority No. 1. The developers were not bothered by the deadlines.
Later, we learned how to predict how much an average developer does on a daily basis, so we could figure out approximately when what task would be completed. We learned how to make plans for the day, right on the calendar. A simple mechanism. Later we taught our product a CRM system to automatically distribute and group similar tasks so that you don’t have to jump to “project A, then project B, then again A”.
This is what the weekly developer calendar looks like. The developer just needs to follow the plan.
At first it seems strange to require the developer to carry out some kind of plan.
But on the other hand, if you are not working on R&D tasks, then your developers are manufacturing. A factory is also a production. Where did you see the manager at the plant go up to the master on the machine and say “how many blanks will you make today?” Production has a plan, you have to do so much a day.
The developers, too, only need to find the right indicators and set the right and real plans.
And yet, we generally removed the priorities of the tasks. All tasks have one priority. Priority is now the order of the tasks.
And earlier (Redmine) was something like this:
But even after 6 months the sides of this scheme climbed.
Example: a project consists of 120 tasks that need to be done. We learned how to predict when all 120 tasks will be ready. Managers have a deadline. But the developer suddenly does 118 tasks and does not squeeze just 2 tasks in time, and you can’t get him to do it without “kicking”. And “kick” is a violation of our own rules so that developers do not think about deadlines.
In reality, the developer does not squeeze these 2 tasks, because he understands that he has already done a lot, and thinks “well, two more tasks on the RFP will not have much effect”.
The scheme was fixed as follows: they made wage segmentation, and not linear one.
For N completed tasks - X USD.
For 1.5N tasks - 2X USD
For 2N tasks - 3X USD
and so on.
This scheme motivates to do more and more.
And her sides climbed: the developers do as many tasks as possible, and forgot about quality. A bug is also a task, so if I make a bug, and then they find it and I fix it, I will have a +1 task.
Immediately there was a thought “do not pay for bugs and do not count bugs”, but this is the wrong way:
And we introduced the second KPI - quality .
Quality is the ratio of the number of completed tasks for a month to the number of bugs found for this month.
For example, the developer did 100 tasks, and the testers found 15 bugs - that means the percentage of developer bugs = 15%.
And the KPI indicator for developers - the percentage of bugs should be less than 15%, otherwise you can’t jump above the first ZP bar. In other words, always junior.
And at that moment it became bad at first (because 3 developers quit), and then just fine, because bugs stopped appearing. One has only to begin to follow some indicator - and he immediately begins to change and adjust.
After 2 months, we stopped counting quality, because the percentage of bugs was less than 10% for all developers. All tuned.
We guess that this is not the limit, something will break down and after some time will again have to do the following scheme.
Be sure to share the information.
Our company has existed since 2006 and we started like everyone else, like a regular web studio. When it all started, we still did not know anything about personnel management, we did not know anything about hiring and delegating functional duties and responsibilities. Now we are obsessed with the efficiency of employees and the automation of all processes. We have 40 employees, we can train +20 developers in 4 weeks, but more on that in the next article.
One of the goals was to get rid of what is in the picture:
Our story began like everyone else:
First, oral instructions to employees: do it, do it, why did you forget? Well, of course, that won’t do that.
Task Manager
Then came the task manager. First, BugZilla, then Mantis, then an attempt to switch to JIRA, then Redmine (it’s worth confessing, we’ve been stuck for 6 years), and then switched to our OneBox . But, these are just task managers; they do not set a strategy for the sequence of task selection and performance indicators.
What happens when you have a task manager? A manager (for example, Project manager) assigns tasks, distributes them among developers. But there are two BUT:
- the developer decides what task to do now. And, as a rule, he chooses “the most interesting”.
- the manager does not know what is being done until he explicitly asks about it.
- the manager and developer do not know when it will be done.
The question arises: does anyone even control the process?
Hourly payment
If we add to this all the hourly pay of developers for the time spent, we get a real hell:
- what prevents the developer from stretching time? Really 30 minutes task, and he does it 60 minutes?
- what prevents to accelerate?
- then the manager can’t sell, because it’s “expensive”
- in general, this scheme explicitly or not explicitly motivates developers to do a long time, just work out the clock, and the result is not important.
- and constantly a bunch of tasks that need to be done “suddenly”.
A second question arises: who controls whom? Programmer manager or programmer all?
Estimate crutch
We had such a scheme for 5 years. And instead of recognizing the curvature of this scheme, we first came up with a crutch “and let's ask the developers to estimate the time”. This cool idea led to:
The manager gives the task, asks to evaluate it.
The developer says estimate, and in most cases the developer “hit”. If he guessed estimate (which, as we know, never happens), then he is well done. If he didn’t have time, the developer will get angry, he will try to do it as quickly as possible (and not qualitatively), because I called the estimate 10 hours, and I’ve been doing the task for the 12th hour, and they will pay for 10.
Therefore, the developers quickly figure out that it is necessary to overestimate the estimate a couple of times and do it as quickly as possible (quality suffers): I named 20, and now I will do it for 10, and even better for 5. Wow, what a fellow I am.
First production management
In total, it took us more than 6 years to admit that things would not go any further. To recognize that the developers (and they are essentially manufacturing) are managing the company, not the company manufacturing.
Paying for hours, the freedom of choosing a task by developers is all uncontrollable processes, and all attempts to control them come down to inventing crutches on crutches.
And we radically changed the scheme:
- the developer does not choose which task to do. The order of tasks is assigned by the head of the department through our CRM system.
- All tasks are set in such a way that they are not more than 2 hours. That is, everything is split up into the smallest tasks of the first level, which answer one simple question “what needs to be done”.
- KPI developers - do as many tasks as possible per month. Salaries are charged for completed tasks.
It got better, much better. We didn’t ask “what is developer X doing now,” because we knew what his task was in the plan now under priority No. 1. The developers were not bothered by the deadlines.
Later, we learned how to predict how much an average developer does on a daily basis, so we could figure out approximately when what task would be completed. We learned how to make plans for the day, right on the calendar. A simple mechanism. Later we taught our product a CRM system to automatically distribute and group similar tasks so that you don’t have to jump to “project A, then project B, then again A”.
This is what the weekly developer calendar looks like. The developer just needs to follow the plan.
At first it seems strange to require the developer to carry out some kind of plan.
But on the other hand, if you are not working on R&D tasks, then your developers are manufacturing. A factory is also a production. Where did you see the manager at the plant go up to the master on the machine and say “how many blanks will you make today?” Production has a plan, you have to do so much a day.
The developers, too, only need to find the right indicators and set the right and real plans.
And yet, we generally removed the priorities of the tasks. All tasks have one priority. Priority is now the order of the tasks.
And earlier (Redmine) was something like this:
Salary segmentation
But even after 6 months the sides of this scheme climbed.
Example: a project consists of 120 tasks that need to be done. We learned how to predict when all 120 tasks will be ready. Managers have a deadline. But the developer suddenly does 118 tasks and does not squeeze just 2 tasks in time, and you can’t get him to do it without “kicking”. And “kick” is a violation of our own rules so that developers do not think about deadlines.
In reality, the developer does not squeeze these 2 tasks, because he understands that he has already done a lot, and thinks “well, two more tasks on the RFP will not have much effect”.
The scheme was fixed as follows: they made wage segmentation, and not linear one.
For N completed tasks - X USD.
For 1.5N tasks - 2X USD
For 2N tasks - 3X USD
and so on.
This scheme motivates to do more and more.
Quality
And her sides climbed: the developers do as many tasks as possible, and forgot about quality. A bug is also a task, so if I make a bug, and then they find it and I fix it, I will have a +1 task.
Immediately there was a thought “do not pay for bugs and do not count bugs”, but this is the wrong way:
- When we say that fixing a bug counts, the subconscious mind believes that “bugs are good.”
- When we say that fixing bugs does not count, then the subconscious mind believes that “bugs are the norm.”
- Therefore, we had to say “bugs are bad and you can’t do them.”
And we introduced the second KPI - quality .
Quality is the ratio of the number of completed tasks for a month to the number of bugs found for this month.
For example, the developer did 100 tasks, and the testers found 15 bugs - that means the percentage of developer bugs = 15%.
And the KPI indicator for developers - the percentage of bugs should be less than 15%, otherwise you can’t jump above the first ZP bar. In other words, always junior.
And at that moment it became bad at first (because 3 developers quit), and then just fine, because bugs stopped appearing. One has only to begin to follow some indicator - and he immediately begins to change and adjust.
After 2 months, we stopped counting quality, because the percentage of bugs was less than 10% for all developers. All tuned.
What did we get after these implementations?
- we stopped kicking developers “do it, then do it”
- no one can change priorities just like that, only team lead has access to the calendars of their employees
- we learned how to predict the time it takes to complete tasks without asking “how much will you do it”
- really changing the order of tasks - we manage production
- we don’t have any priorities at all, as in most task managers
- Well, when developers make a product whose tasks are in the same product, it blows the roof :)
What's next?
We guess that this is not the limit, something will break down and after some time will again have to do the following scheme.
Be sure to share the information.
Our company has existed since 2006 and we started like everyone else, like a regular web studio. When it all started, we still did not know anything about personnel management, we did not know anything about hiring and delegating functional duties and responsibilities. Now we are obsessed with the efficiency of employees and the automation of all processes. We have 40 employees, we can train +20 developers in 4 weeks, but more on that in the next article.