About saving money in the project
Once I came across a study about the price that our competitors offer for the same services and work as we do. And this data was unpleasant: we were noticeably more expensive. To keep orders and hold positions, we needed changes.
Looking ahead, I’ll say that in the end we restructured our work. Moreover, not only reducing costs, but also raising salaries for programmers. How - read under the cut.
First of all, we decided to understand the structure of labor costs in the project. All work in the project was divided into separate blocks. Each block is known for its rating, est, which is put down by the leading developer, and the time spent by the programmer. We defined the “programmer's work speed” as the ratio (amount est) / (amount spent), and calculated this indicator for one team on one project. The table turned out:
Speed dispersion catches your eye. Where does he come from? Maybe the error of the experiment? At first I thought that different developers got tasks of varying difficulty. Therefore, I gave a table for one project - where the work was similar to each other. Also, the sample was given for one team, where all programmers had the same access to information about the project, the same opportunities for communication and getting help from technical experts, etc. Just in case, similar tables were built for other projects and other teams, and made sure : the scatter is there too.
As I later became convinced, such a wide variation is a non-trivial fact for non-programmers. To reinforce the evidence base before the conversation with the management, I decided to read what software development experts say on this subject. In the book S. Arkhipenkova found mention of the variation in performance. A. Orlov spoke in a similar manner in the book Secrets of Programmer Management .
And in Joel Spolsky’s book , he found interesting data about a study conducted by Stanley Eisenstat, a professor at Yale University. For several years, students were asked to report how much time they spent on homework programming. Here are some of the results:
The above examples are enough to state: the speed dispersion observed in our projects is not a feature, and even more so a mistake, of project management in our company. This is an objective feature of the profession of a programmer to be reckoned with.
So, back to our task: reducing costs when conducting projects. From my very first tablet it follows that the speed dispersion was six times. And the scatter of salaries within this team (the ratio of the maximum rate to the minimum) was about 2. Thus, if we give work to programmer N, we will pay 3 times more for it than when we give the same work to programmer # 1.
The conclusion suggests itself: the greater the proportion of strong programmers in a project, the cheaper it will be made. So, it is necessary to hire new strong developers, to keep already working experienced guys. Moreover, this does not mean a complete rejection of junior-level employees: firstly, there are always simple tasks that someone needs to do, and secondly, a promising junior will eventually grow into middle.
However, it is one thing to draw up a table and draw conclusions for yourself. Another thing is to convey the idea to the leadership and convince him of his innocence.
As I said at the very beginning of the article, the action took place against the background of competition and cost reduction (savings). Usually, in such a situation, the office is not talking about raising salaries - total savings begin (well, you have to somehow lower the price ?!).
So the idea of raising rates + of raising the salary bar in a job vacancy looked, to put it mildly, unexpectedly.
Let's see how the work of, say, a bricklayer at a construction site is paid. His salary most often proportionally depends on the output: he worked 2 times faster, received 2 times more money. The situation is similar, say, with a minibus driver: he drove faster, picked up more passengers per unit of time, collected more money. Honestly and fairly (albeit unsafe).
This default approach sits in the minds of many people, not just managers. Therefore, when a PM non-IT person sees that the middle wage is K% higher than that of a maid, he thinks that the middle works about K% faster. This means that the system is linear: 2 people for $ 1000 = 1 people for 2000. And it is completely unclear why we should focus on “strong employees”. Moreover, there are certain “inconveniences” in working with them.
According to my observations, the higher the level of a programmer, the more requirements he places on the quality of the product he is working on. If a green beginner is already satisfied that he created a working piece of code that got into the product, then more experienced colleagues ask themselves questions: why do we use this technology and not another? What is really cool implemented in the product? Why are we better than competitors? In practice, this translates into the fact that the developer asks to include it in the project more interesting and expresses dissatisfaction if he chronically gets primitive work. Or refuses to build the code “quickly from crutches”, and takes time for normal development.
Sometimes, by mistake, this behavior is classified as “star disease”. And with this formulation, it is really better to work with beginners than with experienced programmers.
In the end, the information was conveyed to the leadership, and the proposed reforms were carried out: we work almost exclusively with strong programmers. As a result, we got the following:
And the matter is not only in monetary indicators - as the situation was explained to middle managers and top managers, their attitude towards developers and the profession of a programmer changed.
Looking ahead, I’ll say that in the end we restructured our work. Moreover, not only reducing costs, but also raising salaries for programmers. How - read under the cut.
Study
Internal analysis
First of all, we decided to understand the structure of labor costs in the project. All work in the project was divided into separate blocks. Each block is known for its rating, est, which is put down by the leading developer, and the time spent by the programmer. We defined the “programmer's work speed” as the ratio (amount est) / (amount spent), and calculated this indicator for one team on one project. The table turned out:
| Developer | "Speed" |
|---|---|
| 1 | 1,61 |
| 2 | 1.55 |
| ... | ... |
| N-1 | 0.31 |
| N | 0.26 |
Speed dispersion catches your eye. Where does he come from? Maybe the error of the experiment? At first I thought that different developers got tasks of varying difficulty. Therefore, I gave a table for one project - where the work was similar to each other. Also, the sample was given for one team, where all programmers had the same access to information about the project, the same opportunities for communication and getting help from technical experts, etc. Just in case, similar tables were built for other projects and other teams, and made sure : the scatter is there too.
Data from external sources
As I later became convinced, such a wide variation is a non-trivial fact for non-programmers. To reinforce the evidence base before the conversation with the management, I decided to read what software development experts say on this subject. In the book S. Arkhipenkova found mention of the variation in performance. A. Orlov spoke in a similar manner in the book Secrets of Programmer Management .
And in Joel Spolsky’s book , he found interesting data about a study conducted by Stanley Eisenstat, a professor at Yale University. For several years, students were asked to report how much time they spent on homework programming. Here are some of the results:
| Project | Average | Minimum | Maximum | Deviation |
|---|---|---|---|---|
| COMPRESS00 | 33.83 | 11.58 | 77.00 | 14.51 |
| COMPRESS99 | 27.47 | 6.67 | 69.50 | 13.62 |
| Tex00 | 21.22 | 6.00 | 75.00 | 12.11 |
The above examples are enough to state: the speed dispersion observed in our projects is not a feature, and even more so a mistake, of project management in our company. This is an objective feature of the profession of a programmer to be reckoned with.
Recipe
So, back to our task: reducing costs when conducting projects. From my very first tablet it follows that the speed dispersion was six times. And the scatter of salaries within this team (the ratio of the maximum rate to the minimum) was about 2. Thus, if we give work to programmer N, we will pay 3 times more for it than when we give the same work to programmer # 1.
The conclusion suggests itself: the greater the proportion of strong programmers in a project, the cheaper it will be made. So, it is necessary to hire new strong developers, to keep already working experienced guys. Moreover, this does not mean a complete rejection of junior-level employees: firstly, there are always simple tasks that someone needs to do, and secondly, a promising junior will eventually grow into middle.
However, it is one thing to draw up a table and draw conclusions for yourself. Another thing is to convey the idea to the leadership and convince him of his innocence.
Why is it difficult to convince management to work with more expensive programmers?
Psychological barrier
As I said at the very beginning of the article, the action took place against the background of competition and cost reduction (savings). Usually, in such a situation, the office is not talking about raising salaries - total savings begin (well, you have to somehow lower the price ?!).
So the idea of raising rates + of raising the salary bar in a job vacancy looked, to put it mildly, unexpectedly.
A superficial look at the problem
Let's see how the work of, say, a bricklayer at a construction site is paid. His salary most often proportionally depends on the output: he worked 2 times faster, received 2 times more money. The situation is similar, say, with a minibus driver: he drove faster, picked up more passengers per unit of time, collected more money. Honestly and fairly (albeit unsafe).
This default approach sits in the minds of many people, not just managers. Therefore, when a PM non-IT person sees that the middle wage is K% higher than that of a maid, he thinks that the middle works about K% faster. This means that the system is linear: 2 people for $ 1000 = 1 people for 2000. And it is completely unclear why we should focus on “strong employees”. Moreover, there are certain “inconveniences” in working with them.
"Star fever"
According to my observations, the higher the level of a programmer, the more requirements he places on the quality of the product he is working on. If a green beginner is already satisfied that he created a working piece of code that got into the product, then more experienced colleagues ask themselves questions: why do we use this technology and not another? What is really cool implemented in the product? Why are we better than competitors? In practice, this translates into the fact that the developer asks to include it in the project more interesting and expresses dissatisfaction if he chronically gets primitive work. Or refuses to build the code “quickly from crutches”, and takes time for normal development.
Sometimes, by mistake, this behavior is classified as “star disease”. And with this formulation, it is really better to work with beginners than with experienced programmers.
What is the result?
In the end, the information was conveyed to the leadership, and the proposed reforms were carried out: we work almost exclusively with strong programmers. As a result, we got the following:
- the average salary of strong programmers in the team grew by more than 50%;
- average costs per unit of work decreased by 50%.
And the matter is not only in monetary indicators - as the situation was explained to middle managers and top managers, their attitude towards developers and the profession of a programmer changed.