Programmers and Management
Visiting programmer forums, I constantly come across 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 unexpectedly received a letter from a good competent developer about serious managerial mistakes by the leadership that undermine the motivation of the team and its belief in a bright future. The letter usually gave an analysis of a chain of situations, and then it was reported that the author was tired and did not see for himself more opportunities to work in the company. I am not naive and I understand that, most likely, the developer saw somewhere in another place, for example, more attractive financial prospects. However, do not simplify - sometimes people transfer to another company for exactly the same salary, and sometimes (both to us and from us) even with a loss.
The departure of the developer is always not only extremely upsetting, because the team loses a valuable employee. Departure can be critical, because the Company has already assumed obligations for this employee and failure to fulfill these obligations threatens the Company with various troubles, up to the inability to pay salaries on time to a large number of innocent comrades.
Having discovered that developers often have a rather vague idea of how the “global” business processes in a company are organized, I decided to try to explain to developers what problems those who are trying to organize their work and direct it in a “peaceful direction” face.
When managing any structure, managers have to make many different decisions that change both the structure itself and the processes occurring in it. This is very similar to programming. Suppose there is a need to speed up the program - this is required by the Client, otherwise he will not buy it. You begin to think how you can 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 interaction algorithms of the parts of the managed system, that is, employees. True, the system is much more complicated than the program, since there are still 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 a deterioration of the program, and sometimes to its crash. True, unlike a manager, a programmer can run his program many times and watch 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 of the defects found, which gives you the opportunity to fix them.
But even after this, new errors may emerge from the Client. He reports them. Testers localize them - and the following information arrives to the programmer: in such and such place of the program there is such and such an error that leads to such and such unpleasant consequences.
Now imagine that everyone is silent about the errors detected in your code, they don’t tell you anything. But on the other hand, they are offended by more and more mistakes, reasoning as follows:
“Well, what is it? This guy is making more and more mistakes! How can I give us the software with these bugs? Just a stream of mistakes! Yes, he does not respect us at all! Our motivation from working with him falls lower and lower ... ".
Finally, the decision is made: “You can’t stand it anymore! We don’t want to work with him anymore! ”
Do you think it’s right to do this with the programmer? Will he get good code without feedback on errors and the need for any improvements? Is there any prospect of achieving a good result with this approach? I think the answer is obvious.
But the manager is in such a situation. He, like a programmer, makes various mistakes, but the consumers of his managerial code, his subordinates are most often stubbornly silent and offended, offended and silent. And then they announce their dismissal.
Would it be normal for the Client to first make mistakes in our software for a long time without reporting anything about them, and then, in the end, just send us, because such errors are simply impossible to tolerate anymore!
I think it's not normal. The right situation is cooperation with the Client, who points out our bugs, makes suggestions on how to improve the situation - and then, together, we get a decent product, which the leading world companies are now acquiring from us.
Exactly the same applies to management. Following the needs of our Clients, in the pursuit of improvement, we are forced to change our company, make 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 whole program inoperative - both what is written now and what is written earlier, by you and other people up to you. The recipe for dealing with this inevitable nuisance is simple: detecting an error, informing about it, localizing, correcting it.
Exactly the same applies to management. Managers, like programmers, will always make mistakes. But thanks to the feedback, they will be able to correct them. And together with subordinates to make the system more efficient, which can work better and earn more.
Despite the ever-present shock and enormous sincere grief, I was almost used to the misunderstandings I described at the
beginning of the letter (because they happened to me dozens of times). But I am always amazed at the naive faith of programmers - people with real experience in creating complex systems - that everything should have been correct in management, and managers should not make mistakes. And if the reality in the Company is not like that, then they are offended (well, or their motivation drops - whatever you like).
That is, the Client does not say: “Guys, you have a mistake here, correct it, please,” but he is silent and more and more offended for his incorrect attitude to his needs and aspirations. He considers it unfair that they give him a code with errors, and then really thousands of people suffer. But he considers it fair - to call it a swine on our part.
Imagine when our Client is the right one, we, through joint efforts, going through certain difficulties, all the same, in the end, we can create a really excellent system that will more and more meet his needs, with which he will be more and more comfortable.
And it is absolutely unbelievable that the Client will receive what he needs, what is comfortable for him, if he is silently offended. Yes, even though we all dodge on the navel, but the result will not be good, because we will make more and more mistakes due to ignorance and misunderstanding, and the situation will be worse and worse.
This I write to the fact that we ourselves are the blacksmiths of our own happiness. We can effectively move in the right direction, to ensure that everyone in the development is satisfied and happy if we have feedback, and we will work together to improve our system - our company.
From the Client, we need to pay 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 immediately and without errors, and without stupid questions, how is he better - one way or another ("Do you really not know what I want? Do you call yourself specialists!")?
We understand that this is not possible. We will not work for 20,000 rubles a month. Even a genius will not do many things in a couple of weeks, since a team of three people takes six months to do this job, if they are lucky and unknown difficulties do not emerge. Programs, however, work as they need only after several iterations, correcting many errors and introducing many additional improvements proposed by the Client. But realizing that we are responsible for a good end result, both the Contractor and the Customer, that this result is possible only as a result of joint efforts and compromises, the right Client receives, in the end, what he needs, what provides him competitive advantage over rivals.
The programmer ideally would like to be paid 150 thousand rubles, while there was never any processing, he could do not what the Company needed, but what he was interested in. And it is desirable that the fines that the company sometimes has to pay for critical errors in its code do not concern him at all. A company that, as a result of its stocks, has received 300 thousand rubles less to purchase new equipment, furniture, etc., should simply explain to the project team, which receives an RFP much less than programmers, but receives a bonus from the project’s income, which they will now receive less than 100 thousand rubles in all. But programmers who don’t give the test code to the Client at all can’t be fined even a couple of hundred, that is, a percentage of the losses of the company, because they are so uncomfortable - they would like to,
We understand that this is not possible. It is impossible to receive a greater reward without sacrificing anything for this, without becoming better, without having passed the difficult path to excellence, to the state where 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 hard to gain and which is easy to lose after several flights.
It is impossible to always avoid liability for misses. If many people in the company really suffered and in moral terms (the client with whom they communicate constantly and on which the success of their work depends, considers him to be rude, because he stood for a whole day and each of 200 agents and a couple of dozens of supervisors underused this month, 5% of his salary, and the owner of 10% of his profit - and everyone is angry at them), and in material terms: the project income has become noticeably less - and their remuneration has become noticeably less. It is impossible to explain to the project team (this is a lot of people), which worked honestly and to which the offended Client put both moral and material responsibility, why only they should be responsible for this jamb, to which they are not directly related, who allowed it. Notice
In this situation, the manager can’t even make any decisions. Justice is demanded by dozens of victims who will be terribly offended by the Company completely irrevocably, if the real culprits of their troubles at least do not share real, that is, financial responsibility with them.
But if the programmer, as well as the Client in his case, does not wait for a miracle, does not hope that some uncle managers will organize everything in such a way that for the same work for which he does not want to bear significant responsibility , for some reason, over time, it will receive more and more, but, on the contrary, it will tell managers about their mistakes, help localize the problem, suggest its vision for the solution, then, as in the case of iterative software creation, we will iteratively improve our organization , our responsibility and our motive methods tion. We will build and strengthen with such difficulty the leadership we have won today. And customers will pay us more and more willingly. And ZP programmers will really grow, because their effectiveness will grow. Not only due to the growth of individual skill, but also due to a more correct one, more rational organization of our work. After all, the best strategy for wage growth is to increase efficiency and quality.
There is such a well-known example illustrating the position of a leader. At the golf championship, the prize pool for the winner is one million four hundred thousand dollars, sixty thousand are paid to the second place winner, and only twelve thousand to the third. Moreover, 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. One must strive to be the first - and the reward will not take long. 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 the wrong actions of one spoil the work of many. Remember the proverb about a fly in the ointment? We live in the 21st century and do not really understand what tar is. I suggest more clearly. In a whole barrel a small teaspoon of shit was seen. It is unlikely that you, knowing about it, want to eat it. The result of the work of a particular programmer can dramatically affect the result of the work of the entire team of developers, implementers, managers. It would be great if we jointly found a way to increase the individual responsibility of developers, since sometimes many people depend on this individual responsibility. Imagine that on a car conveyor in one of the sections for assembling engines, the cylinder bushing is installed with violations of technology. This jamb devalues the honest work of all the other participants in the process, because, regardless of the diligent work of everyone else, the result is a marriage. want to eat it. The result of the work of a particular programmer can dramatically affect the result of the work of the entire team of developers, implementers, managers. It would be great if we jointly found a way to increase the individual responsibility of developers, since sometimes many people depend on this individual responsibility. Imagine that on a car conveyor in one of the sections for assembling engines, the cylinder bushing is installed with violations of technology. This jamb devalues the honest work of all the other participants in the process, because, regardless of the diligent work of everyone else, the result is a marriage. want to eat it. The result of the work of a particular programmer can dramatically affect the result of the work of the entire team of developers, implementers, managers. It would be great if we jointly found a way to increase the individual responsibility of developers, since sometimes many people depend on this individual responsibility. Imagine that on a car conveyor in one of the sections for assembling engines, the cylinder bushing is installed with violations of technology. This jamb devalues the honest work of all the other participants in the process, because, regardless of the diligent work of everyone else, the result is a marriage. so that we together find a way to increase the individual responsibility of developers, since sometimes many people depend on this individual responsibility. Imagine that on a car conveyor in one of the sections for assembling engines, the cylinder bushing is installed with violations of technology. This jamb devalues the honest work of all the other participants in the process, because, regardless of the diligent work of everyone else, the result is a marriage. so that we together find a way to increase the individual responsibility of developers, since sometimes many people depend on this individual responsibility. Imagine that on a car conveyor in one of the sections for assembling engines, the cylinder bushing is installed with violations of technology. This jamb devalues the honest work of all the other participants in the process, because, regardless of the diligent work of everyone else, the result is a marriage.
The correct way from my point of view is not to demand exemption from liability. Because she, nevertheless, comes and cannot be freed from her - you can only shift her to others. Remember the “Punishment of the innocent, the rewarding of the innocent”? This is the wrong, disastrous strategy! It is necessary to organize in such a way that this responsibility does not occur, because everything with us is really good.
The conditions in which we exist are objective. And managers are mistaken, just like programmers, for good reasons, out of a desire to make the system better, supplement it with features, improve performance, cut corners in logic. Only through the correction of managerial errors can we make our system better, and our life more interesting and more comfortable.
A couple more programming analogies with control. The fact that decisions often need to be adjusted in the same way as the program code, and that this requires feedback from consumers of management decisions, that is, from employees, we already understand.
The Customers sometimes find some serious error / problem that cannot be fixed. Sometimes, in order to resolve a mistake / problem, serious efforts and a lot of time are needed, because it happens that it is necessary, as in the anecdote “to change the whole system”. A foolish Client sometimes does not understand: “I informed you about the problem 3 weeks ago, but it has not yet been fixed! You are not doing anything! ” He sometimes cannot understand that we have a line of development tasks, and we cannot solve all problems at once. That the problem is complex and requires many months and changes to a number of interdependent subsystems. If he has patience, then, in the end, he will get what he needs. And his system will be better than the competition, because he helped us make it better than the competition. It is unlikely that the result will be good if the Client takes the position: “I am the Client and therefore I am always right. Do not burden me with your problems - just make me happy. ” If the Client is too far for you (sorry, if that is the case), then imagine a tester in his place who does not explain anything, does not indicate errors, just requires you to make him happy. And besides, right to the next Wednesday. Tell me, does this situation have normal constructive prospects? And besides, right to the next Wednesday. Tell me, does this situation have normal constructive prospects? And besides, right to the next Wednesday. Tell me, does this situation have normal constructive prospects?
Here we are, even if employees are not silent, this is not enough to solve all problems. Many employees are genuinely interested in improvements and give managers feedback on problems. It 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 happening there - nothing happens in this company” (read: “and therefore our motivation is steadily dropping”)!
But do we not tell the Client ourselves that this problem of his cannot be solved in two weeks - the persistent and LONG efforts of the whole team are needed. And sometimes even (what a nightmare!) We are aware of the problem, but have not yet figured out how to deal with it. But we’ll definitely come up with (it wasn’t yet so that we, in the end, did not solve the tasks set for ourselves!). You need to help look for a way out, and you need to be patient. Patience is a virtue that is rewarded in the right place.
Two years ago, the company employed 70 people. And now it employs 250 people. All these people are very dependent on the work of programmers, that is, on you. In order not to flinch at night, they need to be sure that those on whom they depend so much are calm, reasonable and responsible people. And they won’t say at any moment, you - as you wish, but I - went ... Here is my application for leaving. The promises you made to me do not bother me. What will happen to the colleagues who personally confirmed these promises in the eyes of the Clients, I don’t care. I can’t baptize children with them.
When this, unfortunately, still happens, the leadership has to take into account not only the interests of the one who was about to leave, but also the interests of those two and a half hundred people who remain and who have done nothing wrong to anyone so easily suffer. Therefore, we try to explain in this case that it will help us a lot if they work for at least a month, and we can somehow orient ourselves and negotiate with the Clients. Those who want to quit have rights, but our managers would have been worthless if they had not defended the rights of those who remain.
We always have great respect for candidates who say: “I want to work for you, but I have obligations in the old place and I must close them. Can you wait?". Responsibility is a very important quality, and we always say: “Of course. We will tolerate. Close your debts. ” We would like our needs to be treated as responsibly as we relate to strangers. By our request to work out a month or two instead of two weeks, we keep the guys from doing the wrong thing, for which then (when they grow up) they would be ashamed.
I repeat once again: Our company, our organizational structure, our processes are the code that we write together. Give us feedback, ideas about improvements, help implement them - and we will be proud of our company, because it will work comfortably and interestingly.
Moreover, I myself, it happened, I suddenly unexpectedly received a letter from a good competent developer about serious managerial mistakes by the leadership that undermine the motivation of the team and its belief in a bright future. The letter usually gave an analysis of a chain of situations, and then it was reported that the author was tired and did not see for himself more opportunities to work in the company. I am not naive and I understand that, most likely, the developer saw somewhere in another place, for example, more attractive financial prospects. However, do not simplify - sometimes people transfer to another company for exactly the same salary, and sometimes (both to us and from us) even with a loss.
The departure of the developer is always not only extremely upsetting, because the team loses a valuable employee. Departure can be critical, because the Company has already assumed obligations for this employee and failure to fulfill these obligations threatens the Company with various troubles, up to the inability to pay salaries on time to a large number of innocent comrades.
Having discovered that developers often have a rather vague idea of how the “global” business processes in a company are organized, I decided to try to explain to developers what problems those who are trying to organize their work and direct it in a “peaceful direction” face.
When managing any structure, managers have to make many different decisions that change both the structure itself and the processes occurring in it. This is very similar to programming. Suppose there is a need to speed up the program - this is required by the Client, otherwise he will not buy it. You begin to think how you can 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 interaction algorithms of the parts of the managed system, that is, employees. True, the system is much more complicated than the program, since there are still 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 a deterioration of the program, and sometimes to its crash. True, unlike a manager, a programmer can run his program many times and watch 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 of the defects found, which gives you the opportunity to fix them.
But even after this, new errors may emerge from the Client. He reports them. Testers localize them - and the following information arrives to the programmer: in such and such place of the program there is such and such an error that leads to such and such unpleasant consequences.
Now imagine that everyone is silent about the errors detected in your code, they don’t tell you anything. But on the other hand, they are offended by more and more mistakes, reasoning as follows:
“Well, what is it? This guy is making more and more mistakes! How can I give us the software with these bugs? Just a stream of mistakes! Yes, he does not respect us at all! Our motivation from working with him falls lower and lower ... ".
Finally, the decision is made: “You can’t stand it anymore! We don’t want to work with him anymore! ”
Do you think it’s right to do this with the programmer? Will he get good code without feedback on errors and the need for any improvements? Is there any prospect of achieving a good result with this approach? I think the answer is obvious.
But the manager is in such a situation. He, like a programmer, makes various mistakes, but the consumers of his managerial code, his subordinates are most often stubbornly silent and offended, offended and silent. And then they announce their dismissal.
Would it be normal for the Client to first make mistakes in our software for a long time without reporting anything about them, and then, in the end, just send us, because such errors are simply impossible to tolerate anymore!
I think it's not normal. The right situation is cooperation with the Client, who points out our bugs, makes suggestions on how to improve the situation - and then, together, we get a decent product, which the leading world companies are now acquiring from us.
Exactly the same applies to management. Following the needs of our Clients, in the pursuit of improvement, we are forced to change our company, make 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 whole program inoperative - both what is written now and what is written earlier, by you and other people up to you. The recipe for dealing with this inevitable nuisance is simple: detecting an error, informing about it, localizing, correcting it.
Exactly the same applies to management. Managers, like programmers, will always make mistakes. But thanks to the feedback, they will be able to correct them. And together with subordinates to make the system more efficient, which can work better and earn more.
Despite the ever-present shock and enormous sincere grief, I was almost used to the misunderstandings I described at the
beginning of the letter (because they happened to me dozens of times). But I am always amazed at the naive faith of programmers - people with real experience in creating complex systems - that everything should have been correct in management, and managers should not make mistakes. And if the reality in the Company is not like that, then they are offended (well, or their motivation drops - whatever you like).
That is, the Client does not say: “Guys, you have a mistake here, correct it, please,” but he is silent and more and more offended for his incorrect attitude to his needs and aspirations. He considers it unfair that they give him a code with errors, and then really thousands of people suffer. But he considers it fair - to call it a swine on our part.
Imagine when our Client is the right one, we, through joint efforts, going through certain difficulties, all the same, in the end, we can create a really excellent system that will more and more meet his needs, with which he will be more and more comfortable.
And it is absolutely unbelievable that the Client will receive what he needs, what is comfortable for him, if he is silently offended. Yes, even though we all dodge on the navel, but the result will not be good, because we will make more and more mistakes due to ignorance and misunderstanding, and the situation will be worse and worse.
This I write to the fact that we ourselves are the blacksmiths of our own happiness. We can effectively move in the right direction, to ensure that everyone in the development is satisfied and happy if we have feedback, and we will work together to improve our system - our company.
From the Client, we need to pay 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 immediately and without errors, and without stupid questions, how is he better - one way or another ("Do you really not know what I want? Do you call yourself specialists!")?
We understand that this is not possible. We will not work for 20,000 rubles a month. Even a genius will not do many things in a couple of weeks, since a team of three people takes six months to do this job, if they are lucky and unknown difficulties do not emerge. Programs, however, work as they need only after several iterations, correcting many errors and introducing many additional improvements proposed by the Client. But realizing that we are responsible for a good end result, both the Contractor and the Customer, that this result is possible only as a result of joint efforts and compromises, the right Client receives, in the end, what he needs, what provides him competitive advantage over rivals.
The programmer ideally would like to be paid 150 thousand rubles, while there was never any processing, he could do not what the Company needed, but what he was interested in. And it is desirable that the fines that the company sometimes has to pay for critical errors in its code do not concern him at all. A company that, as a result of its stocks, has received 300 thousand rubles less to purchase new equipment, furniture, etc., should simply explain to the project team, which receives an RFP much less than programmers, but receives a bonus from the project’s income, which they will now receive less than 100 thousand rubles in all. But programmers who don’t give the test code to the Client at all can’t be fined even a couple of hundred, that is, a percentage of the losses of the company, because they are so uncomfortable - they would like to,
We understand that this is not possible. It is impossible to receive a greater reward without sacrificing anything for this, without becoming better, without having passed the difficult path to excellence, to the state where 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 hard to gain and which is easy to lose after several flights.
It is impossible to always avoid liability for misses. If many people in the company really suffered and in moral terms (the client with whom they communicate constantly and on which the success of their work depends, considers him to be rude, because he stood for a whole day and each of 200 agents and a couple of dozens of supervisors underused this month, 5% of his salary, and the owner of 10% of his profit - and everyone is angry at them), and in material terms: the project income has become noticeably less - and their remuneration has become noticeably less. It is impossible to explain to the project team (this is a lot of people), which worked honestly and to which the offended Client put both moral and material responsibility, why only they should be responsible for this jamb, to which they are not directly related, who allowed it. Notice
In this situation, the manager can’t even make any decisions. Justice is demanded by dozens of victims who will be terribly offended by the Company completely irrevocably, if the real culprits of their troubles at least do not share real, that is, financial responsibility with them.
But if the programmer, as well as the Client in his case, does not wait for a miracle, does not hope that some uncle managers will organize everything in such a way that for the same work for which he does not want to bear significant responsibility , for some reason, over time, it will receive more and more, but, on the contrary, it will tell managers about their mistakes, help localize the problem, suggest its vision for the solution, then, as in the case of iterative software creation, we will iteratively improve our organization , our responsibility and our motive methods tion. We will build and strengthen with such difficulty the leadership we have won today. And customers will pay us more and more willingly. And ZP programmers will really grow, because their effectiveness will grow. Not only due to the growth of individual skill, but also due to a more correct one, more rational organization of our work. After all, the best strategy for wage growth is to increase efficiency and quality.
There is such a well-known example illustrating the position of a leader. At the golf championship, the prize pool for the winner is one million four hundred thousand dollars, sixty thousand are paid to the second place winner, and only twelve thousand to the third. Moreover, 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. One must strive to be the first - and the reward will not take long. 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 the wrong actions of one spoil the work of many. Remember the proverb about a fly in the ointment? We live in the 21st century and do not really understand what tar is. I suggest more clearly. In a whole barrel a small teaspoon of shit was seen. It is unlikely that you, knowing about it, want to eat it. The result of the work of a particular programmer can dramatically affect the result of the work of the entire team of developers, implementers, managers. It would be great if we jointly found a way to increase the individual responsibility of developers, since sometimes many people depend on this individual responsibility. Imagine that on a car conveyor in one of the sections for assembling engines, the cylinder bushing is installed with violations of technology. This jamb devalues the honest work of all the other participants in the process, because, regardless of the diligent work of everyone else, the result is a marriage. want to eat it. The result of the work of a particular programmer can dramatically affect the result of the work of the entire team of developers, implementers, managers. It would be great if we jointly found a way to increase the individual responsibility of developers, since sometimes many people depend on this individual responsibility. Imagine that on a car conveyor in one of the sections for assembling engines, the cylinder bushing is installed with violations of technology. This jamb devalues the honest work of all the other participants in the process, because, regardless of the diligent work of everyone else, the result is a marriage. want to eat it. The result of the work of a particular programmer can dramatically affect the result of the work of the entire team of developers, implementers, managers. It would be great if we jointly found a way to increase the individual responsibility of developers, since sometimes many people depend on this individual responsibility. Imagine that on a car conveyor in one of the sections for assembling engines, the cylinder bushing is installed with violations of technology. This jamb devalues the honest work of all the other participants in the process, because, regardless of the diligent work of everyone else, the result is a marriage. so that we together find a way to increase the individual responsibility of developers, since sometimes many people depend on this individual responsibility. Imagine that on a car conveyor in one of the sections for assembling engines, the cylinder bushing is installed with violations of technology. This jamb devalues the honest work of all the other participants in the process, because, regardless of the diligent work of everyone else, the result is a marriage. so that we together find a way to increase the individual responsibility of developers, since sometimes many people depend on this individual responsibility. Imagine that on a car conveyor in one of the sections for assembling engines, the cylinder bushing is installed with violations of technology. This jamb devalues the honest work of all the other participants in the process, because, regardless of the diligent work of everyone else, the result is a marriage.
The correct way from my point of view is not to demand exemption from liability. Because she, nevertheless, comes and cannot be freed from her - you can only shift her to others. Remember the “Punishment of the innocent, the rewarding of the innocent”? This is the wrong, disastrous strategy! It is necessary to organize in such a way that this responsibility does not occur, because everything with us is really good.
The conditions in which we exist are objective. And managers are mistaken, just like programmers, for good reasons, out of a desire to make the system better, supplement it with features, improve performance, cut corners in logic. Only through the correction of managerial errors can we make our system better, and our life more interesting and more comfortable.
A couple more programming analogies with control. The fact that decisions often need to be adjusted in the same way as the program code, and that this requires feedback from consumers of management decisions, that is, from employees, we already understand.
The Customers sometimes find some serious error / problem that cannot be fixed. Sometimes, in order to resolve a mistake / problem, serious efforts and a lot of time are needed, because it happens that it is necessary, as in the anecdote “to change the whole system”. A foolish Client sometimes does not understand: “I informed you about the problem 3 weeks ago, but it has not yet been fixed! You are not doing anything! ” He sometimes cannot understand that we have a line of development tasks, and we cannot solve all problems at once. That the problem is complex and requires many months and changes to a number of interdependent subsystems. If he has patience, then, in the end, he will get what he needs. And his system will be better than the competition, because he helped us make it better than the competition. It is unlikely that the result will be good if the Client takes the position: “I am the Client and therefore I am always right. Do not burden me with your problems - just make me happy. ” If the Client is too far for you (sorry, if that is the case), then imagine a tester in his place who does not explain anything, does not indicate errors, just requires you to make him happy. And besides, right to the next Wednesday. Tell me, does this situation have normal constructive prospects? And besides, right to the next Wednesday. Tell me, does this situation have normal constructive prospects? And besides, right to the next Wednesday. Tell me, does this situation have normal constructive prospects?
Here we are, even if employees are not silent, this is not enough to solve all problems. Many employees are genuinely interested in improvements and give managers feedback on problems. It 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 happening there - nothing happens in this company” (read: “and therefore our motivation is steadily dropping”)!
But do we not tell the Client ourselves that this problem of his cannot be solved in two weeks - the persistent and LONG efforts of the whole team are needed. And sometimes even (what a nightmare!) We are aware of the problem, but have not yet figured out how to deal with it. But we’ll definitely come up with (it wasn’t yet so that we, in the end, did not solve the tasks set for ourselves!). You need to help look for a way out, and you need to be patient. Patience is a virtue that is rewarded in the right place.
Two years ago, the company employed 70 people. And now it employs 250 people. All these people are very dependent on the work of programmers, that is, on you. In order not to flinch at night, they need to be sure that those on whom they depend so much are calm, reasonable and responsible people. And they won’t say at any moment, you - as you wish, but I - went ... Here is my application for leaving. The promises you made to me do not bother me. What will happen to the colleagues who personally confirmed these promises in the eyes of the Clients, I don’t care. I can’t baptize children with them.
When this, unfortunately, still happens, the leadership has to take into account not only the interests of the one who was about to leave, but also the interests of those two and a half hundred people who remain and who have done nothing wrong to anyone so easily suffer. Therefore, we try to explain in this case that it will help us a lot if they work for at least a month, and we can somehow orient ourselves and negotiate with the Clients. Those who want to quit have rights, but our managers would have been worthless if they had not defended the rights of those who remain.
We always have great respect for candidates who say: “I want to work for you, but I have obligations in the old place and I must close them. Can you wait?". Responsibility is a very important quality, and we always say: “Of course. We will tolerate. Close your debts. ” We would like our needs to be treated as responsibly as we relate to strangers. By our request to work out a month or two instead of two weeks, we keep the guys from doing the wrong thing, for which then (when they grow up) they would be ashamed.
I repeat once again: Our company, our organizational structure, our processes are the code that we write together. Give us feedback, ideas about improvements, help implement them - and we will be proud of our company, because it will work comfortably and interestingly.