Programmers and management
Visiting programming forums, I constantly encounter the fact that people discuss the organization of affairs in the companies where they work. And often in very offended tones.
Moreover, I myself, it happened, I suddenly, quite unexpectedly received a letter from a good competent developer, about serious managerial management errors that undermine the motivation of the team and its faith in a bright future. The letter usually gave an analysis of some chain of situations, and then it was reported that the author was tired and did not see for himself more opportunity to work in the company. I'm not naive, and I understand that, most likely, the developer saw somewhere else, for example, more attractive financial prospects. However, you should not simplify - sometimes people go to another company for exactly the same salary, and it happened (to us and from us) even with a loss.
Care of the developer is not only extremely distressing, because the team loses a valuable employee. Leaving can be critical, as the Company has already assumed obligations for this employee and failure to fulfill these obligations threatens the Company with various misfortunes up to the impossibility of paying on time a salary to a large number of innocent comrades.
Having found that developers often have a rather vague idea of ​​how the “global” business processes are organized in a company, I decided to try to explain to the developers what problems those who are trying to organize their work and send it to the “peaceful course” face.
')
Managing any structure, managers have to make many different decisions that change both the structure and the processes occurring in it. This is very similar to programming. Suppose there is a need to speed up the work of the program - this is required by the Client, otherwise he will not buy it. You begin to think how to achieve this. You have ideas to test them, you need to make changes to the code - and when you do this, you make management decisions. The manager does exactly the same thing - he makes changes to the code, to the algorithms of interaction between parts of the controlled system, that is, employees. True, the system is much more complex than the program, since it also contains such factors as psychology, emotions, a sense of justice and much more.
Not all solutions are successful. Exactly like a programmer. Some changes in the code in certain cases lead to the deterioration of the program, and sometimes to its collapse. However, unlike the manager, the programmer can launch his own program many times and see what happens, how it works. But even in these cases, as our practice shows, the code can contain many important and even critical errors. What happens next? Your code is thoroughly tested by testers, other specialists (implementers, project managers, etc.) and inform you about the defects found, which gives you the opportunity to correct them.
But after that, the Client may come up with new errors. He reports them. Testers localize them - and the programmer receives the following information: in such and such a place of the program there is such-and-such an error, which leads to such-and-such unpleasant consequences.
Now imagine that everybody is silent about the errors found in your code, they do not tell you anything. But they are offended at all new and new errors, arguing as follows:
“Well, what is it? This guy is making new and new mistakes! How can you give us software with these bugs? Just a stream of errors! Yes, he does not respect us at all! Our motivation to work with him goes lower and lower ... ".
Finally, the decision is made “This can no longer be tolerated! We don't want to work with him anymore! ”
What do you think, is it right to do so with a programmer? Will he have a good code without feedback about errors and the need for certain improvements? Is there a prospect to achieve a good result with this approach? I think the answer is obvious.
But the manager is in this situation. He, like the programmer, makes various mistakes, but the consumers of his management code, his subordinates are most often stubbornly silent and offended, offended and silent. And then they declare their dismissal.
Would it have been normal if the Client had first suffered errors in our software for a long time, without reporting anything about them, and then, in the end, simply sent us, because such errors simply cannot be tolerated any longer!
I think is not normal. The right situation is cooperation with the Client, who points out to us our bugs, makes his suggestions on how to improve the situation - and then with joint efforts we get a decent product that we now acquire from the world's leading companies.
Exactly the same applies to management. Following the needs of our Clients, in the pursuit of improvements, we are forced to change our company, take various management decisions, and make changes to its code. Sometimes we make mistakes. Programmers know that you can write a thousand lines of correct code and a couple more lines that will make the entire program inoperable - both what is written now and what is written before, by yourself and other people before you. The recipe for dealing with this inevitable nuisance is simple: error detection, information about it, localization, correction.
Exactly the same applies to management. Managers, like programmers, will always make mistakes. But thanks to the feedback they can correct them. And together with subordinates to make the system more and more efficient, which can work better and earn more.
In spite of the constant shock and tremendous sincere disappointment, I was almost used to the misunderstandings I described in
the beginning of the letter (because they happened to me dozens of times). But I am always amazed by the naive faith of programmers - people who have real experience in creating complex systems - that everything should be correct in management, and managers should not make mistakes. And if the reality in the Company is not the same, then they are offended (well, or their motivation falls - whatever you want to call it).
That is, the Client does not say: “Guys, you have a mistake here, correct, please,” but he is silent and more and more offended by the wrong attitude to his needs and aspirations. He considers it unfair that they give him a code with errors, and then thousands of people actually suffer. And he considers fair to call it swine on our part.
Imagine when our Client is right, we, by joint efforts, having gone through certain difficulties, anyway, in the end, we can create a truly excellent system that will meet its needs more and more, with which it will be more and more comfortable
And it is absolutely unbelievable that the Client will receive what he needs, something that is comfortable for him if he will be silently offended. Yes, even though we all pervert on the navel, and the result will not be good, because we will make new and new mistakes because of ignorance and misunderstanding, and the situation will get worse and worse.
I am writing this to the fact that we ourselves are blacksmiths of our own happiness. We will be able to effectively move in the right direction, so that everyone in the development will be satisfied and happy if we have feedback and we will work together to improve our system - our company.
From the Client, we need payment for our services in exchange for satisfaction with our product.
From the Developer we need effective work in exchange for satisfaction with his work in our company.
The client, ideally, would like us to work for 20,000 rubles a month and immediately give out what he needs, preferably not in a year, but in a couple of weeks, and so that everything works perfectly and without mistakes, and without stupid questions, how is it better for him - in one way or another (“Do you really not know what I want? You call yourself experts!”)?
We all understand that this is impossible. We will not work for 20,000 rubles a month. Even a genius will not do many things in a couple of weeks, because for half a year a team of three people needs this work, if you are lucky and do not come up with unknown difficulties. The programs work the way they need only after several iterations, correcting many errors and making a number of additional improvements proposed by the Client. But realizing that for a good end result we are responsible for both the Contractor and the Customer, that this result is possible only as the fruit of joint efforts and compromises, the right Client receives, in the end, what he needs, what provides him competitive advantage over rivals.
Ideally, a programmer would like to be paid 150 thousand rubles, while there was never a rework, he could not do what the Company needs, but what he is interested in. And it is desirable that the fines, which the company sometimes has to pay for critical errors in its code, should not concern it at all. The company, which as a result of its jambs was 300 thousand rubles less for the purchase of new equipment, furniture, etc., should simply explain to the project team, which receives a salary much less than the programmers, but receive a bonus from the project income, which they will now receive less for every 100 thousand rubles. But programmers who don’t give the client any code that’s not tested at all can’t be fined even a couple hundred, that is, a percentage of the company’s losses, because they’re so uncomfortable - they would like the responsibility to be financial, even symbolic, compared to the losses of others, programmers did not carry in any case (as they say, "developer fines demotivate").
We understand that this is impossible. It is impossible to get more reward without sacrificing for the sake of it, without becoming better, without going through the difficult path to perfection, to the state when Clients really agree to pay a lot, because we, as a company, are worth it. To do this, we need a reputation that we gradually and difficultly gain and which is easy to lose after several attacks.
It is impossible to always avoid responsibility for blunders. If many people in the company really suffered and morally (the client, with whom they communicate constantly and on which the success of their work depends, considers that he was rudely framed because he stood for a whole day and each of the 200 agents and a couple dozen supervisors this month, 5% of their salary, and the owner of 10% of their profits - and everyone is angry at them), and in material terms: the project's income has become noticeably less - and their remuneration has become noticeably less. The project team (this is a lot of people), who honestly worked and for which the offended Client put up moral and material responsibility, it is impossible to explain why only they can answer for this joint, to which they do not have a direct relationship, who allowed it. Note that it’s not that the code should be bug-free - it’s about the fact that it got to the Client without any testing at all.
In this situation, the manager cannot even make any decisions. Justice is demanded by dozens of victims who are terribly offended by the Company already completely irrevocably, if the real perpetrators of their troubles do not even share real, that is, financial responsibility with them.
But if the programmer, as well as the Client in his case, will not wait for a miracle, will not hope that some uncle-managers will arrange it for him so that for the same work, for which he does not want to bear substantial responsibility , for some reason, over time, he will receive more and more, and, on the contrary, will point managers to their mistakes, help localize the problem, suggest their vision of the solution, then we, as in the case of iterative software development, will iteratively improve our organization our responsibility and our motive methods tion. We will build up and consolidate today's leadership that we have won with such difficulty. And customers will pay us more and more willingly. And ZP programmers will really grow, because their effectiveness will grow. Not only thanks to the growth of individual skills, But also thanks to a more correct, more rational organization of our work. After all, the best strategy for wage growth is the growth of efficiency and quality.
There is such a famous example illustrating the position of a leader. At the golf championship the prize fund for the winner is one million four hundred thousand dollars, the runner-up is paid sixty thousand, and the third only twelve thousand. At the same time, the result of the first is only half a percent better than the second, and one and a half percent better than the third. Exactly the same rules apply in business. The leader, who is a couple percent better than the second, receives many times more rewards. We must strive to be first - and the reward will not keep you waiting. We are doing a very complex business in which everyone is very dependent on each other. Maybe 40 people try hard and work a lot and honestly, and wrong actions of one can ruin the work of many. Remember the adage about a fly in a barrel of honey? We live in the 21st century and do not really understand what tar is. I suggest more understandable. In a whole barrel jam little teaspoon of shit. Hardly you, knowing this, want to eat it. The result of the work of a specific programmer can dramatically affect the result of the work of the entire team of developers, implementers, managers. It would be great if we jointly find a way to increase the individual responsibility of developers, since many people depend on this individual responsibility. Imagine that on a car conveyor in one of the engine assembly sections, the cylinder sleeve is installed with violations of technology. This cant devalues ​​the honest work of all the other participants in the process, because, regardless of the hard work of all the others, the result is a marriage.
The right way, from my point of view, is not to demand an exemption from liability. Because she, all the same, comes and cannot be freed from her - one can only shift it to others. Remember the "Punishment of the innocent, rewarding the uncomplicated"? This is a wrong, disastrous strategy! It is necessary to organize so that this responsibility does not come, because everything with us is really good.
The conditions in which we exist are objective. And managers are mistaken, just like programmers, for the best of reasons, from the desire to make the system better, add features to it, improve speed, cut corners in logic. Only through the correction of managerial mistakes can you make our system better, and our life more interesting and comfortable.
Another couple of programming analogies with control. The fact that decisions often need to be adjusted in the same way as a program code, and that it requires feedback from consumers of management decisions, that is, from employees, we, I think, is already clear.
Clients sometimes show some serious error / problem that cannot be corrected. Sometimes, in order for an error / problem to be solved, serious efforts and a lot of time are needed, because it happens that it is necessary, as in the joke “to change the whole system”. The stupid Client sometimes does not understand: “I reported to you about the problem 3 weeks ago, but it has not been fixed yet! You are not doing anything! ” Sometimes he cannot comprehend that we have a queue of development tasks, and we cannot solve all problems at once simultaneously. That the problem is complex and requires many man-months and changes in a number of interdependent subsystems. If he has patience, he will eventually get what he needs. And his system will be better than that of competitors, because he helped us make it better than that of competitors. The result is unlikely to be good if the Client takes the position: “I am a Client and therefore always right. Do not load me with your problems - just make me happy. ” If the Client is too far for you (sorry, if it is so), then imagine a tester in his place who does not explain anything, does not indicate errors, simply demands that you make him satisfied. And besides, right to the next Wednesday. Tell me, is there a normal constructive perspective for this situation?
So here we are, even if the employees are not silent, this is not enough to solve all the problems. Many employees are genuinely genuinely interested in improvements and give managers feedback on problems. She is very useful and makes managers realize these problems and look for their solution. But I often hear the following - “we already talked about this problem in May, but things are still there — nothing happens in this company” (read: “and therefore our motivation is steadily going down”)!
But do we not tell the Client ourselves that it’s impossible to solve this problem in two weeks - we need persistent and LONG efforts of the whole team. And sometimes even (what a nightmare!) We are aware of the problem, but have not yet figured out how to cope with it. But we will definitely come up with (not yet so that we, in the end, did not decide the tasks set for ourselves!). You need to help find a way out, and you have to be patient. – , .
70 . 250 . , . , , , , , – , . , — , – … . , , . , , . .
, , - , , , , , . , , , - . , , , .
, : « , . ?». – , : «. . ». , , . - , ( ) .
: , , – , . , , – , .
Moreover, I myself, it happened, I suddenly, quite unexpectedly received a letter from a good competent developer, about serious managerial management errors that undermine the motivation of the team and its faith in a bright future. The letter usually gave an analysis of some chain of situations, and then it was reported that the author was tired and did not see for himself more opportunity to work in the company. I'm not naive, and I understand that, most likely, the developer saw somewhere else, for example, more attractive financial prospects. However, you should not simplify - sometimes people go to another company for exactly the same salary, and it happened (to us and from us) even with a loss.
Care of the developer is not only extremely distressing, because the team loses a valuable employee. Leaving can be critical, as the Company has already assumed obligations for this employee and failure to fulfill these obligations threatens the Company with various misfortunes up to the impossibility of paying on time a salary to a large number of innocent comrades.
Having found that developers often have a rather vague idea of ​​how the “global” business processes are organized in a company, I decided to try to explain to the developers what problems those who are trying to organize their work and send it to the “peaceful course” face.
')
Managing any structure, managers have to make many different decisions that change both the structure and the processes occurring in it. This is very similar to programming. Suppose there is a need to speed up the work of the program - this is required by the Client, otherwise he will not buy it. You begin to think how to achieve this. You have ideas to test them, you need to make changes to the code - and when you do this, you make management decisions. The manager does exactly the same thing - he makes changes to the code, to the algorithms of interaction between parts of the controlled system, that is, employees. True, the system is much more complex than the program, since it also contains such factors as psychology, emotions, a sense of justice and much more.
Not all solutions are successful. Exactly like a programmer. Some changes in the code in certain cases lead to the deterioration of the program, and sometimes to its collapse. However, unlike the manager, the programmer can launch his own program many times and see what happens, how it works. But even in these cases, as our practice shows, the code can contain many important and even critical errors. What happens next? Your code is thoroughly tested by testers, other specialists (implementers, project managers, etc.) and inform you about the defects found, which gives you the opportunity to correct them.
But after that, the Client may come up with new errors. He reports them. Testers localize them - and the programmer receives the following information: in such and such a place of the program there is such-and-such an error, which leads to such-and-such unpleasant consequences.
Now imagine that everybody is silent about the errors found in your code, they do not tell you anything. But they are offended at all new and new errors, arguing as follows:
“Well, what is it? This guy is making new and new mistakes! How can you give us software with these bugs? Just a stream of errors! Yes, he does not respect us at all! Our motivation to work with him goes lower and lower ... ".
Finally, the decision is made “This can no longer be tolerated! We don't want to work with him anymore! ”
What do you think, is it right to do so with a programmer? Will he have a good code without feedback about errors and the need for certain improvements? Is there a prospect to achieve a good result with this approach? I think the answer is obvious.
But the manager is in this situation. He, like the programmer, makes various mistakes, but the consumers of his management code, his subordinates are most often stubbornly silent and offended, offended and silent. And then they declare their dismissal.
Would it have been normal if the Client had first suffered errors in our software for a long time, without reporting anything about them, and then, in the end, simply sent us, because such errors simply cannot be tolerated any longer!
I think is not normal. The right situation is cooperation with the Client, who points out to us our bugs, makes his suggestions on how to improve the situation - and then with joint efforts we get a decent product that we now acquire from the world's leading companies.
Exactly the same applies to management. Following the needs of our Clients, in the pursuit of improvements, we are forced to change our company, take various management decisions, and make changes to its code. Sometimes we make mistakes. Programmers know that you can write a thousand lines of correct code and a couple more lines that will make the entire program inoperable - both what is written now and what is written before, by yourself and other people before you. The recipe for dealing with this inevitable nuisance is simple: error detection, information about it, localization, correction.
Exactly the same applies to management. Managers, like programmers, will always make mistakes. But thanks to the feedback they can correct them. And together with subordinates to make the system more and more efficient, which can work better and earn more.
In spite of the constant shock and tremendous sincere disappointment, I was almost used to the misunderstandings I described in
the beginning of the letter (because they happened to me dozens of times). But I am always amazed by the naive faith of programmers - people who have real experience in creating complex systems - that everything should be correct in management, and managers should not make mistakes. And if the reality in the Company is not the same, then they are offended (well, or their motivation falls - whatever you want to call it).
That is, the Client does not say: “Guys, you have a mistake here, correct, please,” but he is silent and more and more offended by the wrong attitude to his needs and aspirations. He considers it unfair that they give him a code with errors, and then thousands of people actually suffer. And he considers fair to call it swine on our part.
Imagine when our Client is right, we, by joint efforts, having gone through certain difficulties, anyway, in the end, we can create a truly excellent system that will meet its needs more and more, with which it will be more and more comfortable
And it is absolutely unbelievable that the Client will receive what he needs, something that is comfortable for him if he will be silently offended. Yes, even though we all pervert on the navel, and the result will not be good, because we will make new and new mistakes because of ignorance and misunderstanding, and the situation will get worse and worse.
I am writing this to the fact that we ourselves are blacksmiths of our own happiness. We will be able to effectively move in the right direction, so that everyone in the development will be satisfied and happy if we have feedback and we will work together to improve our system - our company.
From the Client, we need payment for our services in exchange for satisfaction with our product.
From the Developer we need effective work in exchange for satisfaction with his work in our company.
The client, ideally, would like us to work for 20,000 rubles a month and immediately give out what he needs, preferably not in a year, but in a couple of weeks, and so that everything works perfectly and without mistakes, and without stupid questions, how is it better for him - in one way or another (“Do you really not know what I want? You call yourself experts!”)?
We all understand that this is impossible. We will not work for 20,000 rubles a month. Even a genius will not do many things in a couple of weeks, because for half a year a team of three people needs this work, if you are lucky and do not come up with unknown difficulties. The programs work the way they need only after several iterations, correcting many errors and making a number of additional improvements proposed by the Client. But realizing that for a good end result we are responsible for both the Contractor and the Customer, that this result is possible only as the fruit of joint efforts and compromises, the right Client receives, in the end, what he needs, what provides him competitive advantage over rivals.
Ideally, a programmer would like to be paid 150 thousand rubles, while there was never a rework, he could not do what the Company needs, but what he is interested in. And it is desirable that the fines, which the company sometimes has to pay for critical errors in its code, should not concern it at all. The company, which as a result of its jambs was 300 thousand rubles less for the purchase of new equipment, furniture, etc., should simply explain to the project team, which receives a salary much less than the programmers, but receive a bonus from the project income, which they will now receive less for every 100 thousand rubles. But programmers who don’t give the client any code that’s not tested at all can’t be fined even a couple hundred, that is, a percentage of the company’s losses, because they’re so uncomfortable - they would like the responsibility to be financial, even symbolic, compared to the losses of others, programmers did not carry in any case (as they say, "developer fines demotivate").
We understand that this is impossible. It is impossible to get more reward without sacrificing for the sake of it, without becoming better, without going through the difficult path to perfection, to the state when Clients really agree to pay a lot, because we, as a company, are worth it. To do this, we need a reputation that we gradually and difficultly gain and which is easy to lose after several attacks.
It is impossible to always avoid responsibility for blunders. If many people in the company really suffered and morally (the client, with whom they communicate constantly and on which the success of their work depends, considers that he was rudely framed because he stood for a whole day and each of the 200 agents and a couple dozen supervisors this month, 5% of their salary, and the owner of 10% of their profits - and everyone is angry at them), and in material terms: the project's income has become noticeably less - and their remuneration has become noticeably less. The project team (this is a lot of people), who honestly worked and for which the offended Client put up moral and material responsibility, it is impossible to explain why only they can answer for this joint, to which they do not have a direct relationship, who allowed it. Note that it’s not that the code should be bug-free - it’s about the fact that it got to the Client without any testing at all.
In this situation, the manager cannot even make any decisions. Justice is demanded by dozens of victims who are terribly offended by the Company already completely irrevocably, if the real perpetrators of their troubles do not even share real, that is, financial responsibility with them.
But if the programmer, as well as the Client in his case, will not wait for a miracle, will not hope that some uncle-managers will arrange it for him so that for the same work, for which he does not want to bear substantial responsibility , for some reason, over time, he will receive more and more, and, on the contrary, will point managers to their mistakes, help localize the problem, suggest their vision of the solution, then we, as in the case of iterative software development, will iteratively improve our organization our responsibility and our motive methods tion. We will build up and consolidate today's leadership that we have won with such difficulty. And customers will pay us more and more willingly. And ZP programmers will really grow, because their effectiveness will grow. Not only thanks to the growth of individual skills, But also thanks to a more correct, more rational organization of our work. After all, the best strategy for wage growth is the growth of efficiency and quality.
There is such a famous example illustrating the position of a leader. At the golf championship the prize fund for the winner is one million four hundred thousand dollars, the runner-up is paid sixty thousand, and the third only twelve thousand. At the same time, the result of the first is only half a percent better than the second, and one and a half percent better than the third. Exactly the same rules apply in business. The leader, who is a couple percent better than the second, receives many times more rewards. We must strive to be first - and the reward will not keep you waiting. We are doing a very complex business in which everyone is very dependent on each other. Maybe 40 people try hard and work a lot and honestly, and wrong actions of one can ruin the work of many. Remember the adage about a fly in a barrel of honey? We live in the 21st century and do not really understand what tar is. I suggest more understandable. In a whole barrel jam little teaspoon of shit. Hardly you, knowing this, want to eat it. The result of the work of a specific programmer can dramatically affect the result of the work of the entire team of developers, implementers, managers. It would be great if we jointly find a way to increase the individual responsibility of developers, since many people depend on this individual responsibility. Imagine that on a car conveyor in one of the engine assembly sections, the cylinder sleeve is installed with violations of technology. This cant devalues ​​the honest work of all the other participants in the process, because, regardless of the hard work of all the others, the result is a marriage.
The right way, from my point of view, is not to demand an exemption from liability. Because she, all the same, comes and cannot be freed from her - one can only shift it to others. Remember the "Punishment of the innocent, rewarding the uncomplicated"? This is a wrong, disastrous strategy! It is necessary to organize so that this responsibility does not come, because everything with us is really good.
The conditions in which we exist are objective. And managers are mistaken, just like programmers, for the best of reasons, from the desire to make the system better, add features to it, improve speed, cut corners in logic. Only through the correction of managerial mistakes can you make our system better, and our life more interesting and comfortable.
Another couple of programming analogies with control. The fact that decisions often need to be adjusted in the same way as a program code, and that it requires feedback from consumers of management decisions, that is, from employees, we, I think, is already clear.
Clients sometimes show some serious error / problem that cannot be corrected. Sometimes, in order for an error / problem to be solved, serious efforts and a lot of time are needed, because it happens that it is necessary, as in the joke “to change the whole system”. The stupid Client sometimes does not understand: “I reported to you about the problem 3 weeks ago, but it has not been fixed yet! You are not doing anything! ” Sometimes he cannot comprehend that we have a queue of development tasks, and we cannot solve all problems at once simultaneously. That the problem is complex and requires many man-months and changes in a number of interdependent subsystems. If he has patience, he will eventually get what he needs. And his system will be better than that of competitors, because he helped us make it better than that of competitors. The result is unlikely to be good if the Client takes the position: “I am a Client and therefore always right. Do not load me with your problems - just make me happy. ” If the Client is too far for you (sorry, if it is so), then imagine a tester in his place who does not explain anything, does not indicate errors, simply demands that you make him satisfied. And besides, right to the next Wednesday. Tell me, is there a normal constructive perspective for this situation?
So here we are, even if the employees are not silent, this is not enough to solve all the problems. Many employees are genuinely genuinely interested in improvements and give managers feedback on problems. She is very useful and makes managers realize these problems and look for their solution. But I often hear the following - “we already talked about this problem in May, but things are still there — nothing happens in this company” (read: “and therefore our motivation is steadily going down”)!
But do we not tell the Client ourselves that it’s impossible to solve this problem in two weeks - we need persistent and LONG efforts of the whole team. And sometimes even (what a nightmare!) We are aware of the problem, but have not yet figured out how to cope with it. But we will definitely come up with (not yet so that we, in the end, did not decide the tasks set for ourselves!). You need to help find a way out, and you have to be patient. – , .
70 . 250 . , . , , , , , – , . , — , – … . , , . , , . .
, , - , , , , , . , , , - . , , , .
, : « , . ?». – , : «. . ». , , . - , ( ) .
: , , – , . , , – , .
Source: https://habr.com/ru/post/150288/
All Articles