From engineer to manager. Part 1: Sense of Justice
Working for a long time as a software engineer, in addition to experience and knowledge, I also collected discontent and comments on the work process and the authorities in particular. Every time I encountered a problem, I thought about how I could solve it and what I can do in this situation. Something could be done, but something broke about the process and the governing apparatus. And each time the problem and its solutions were postponed by me, with the knowledge that if I had the necessary levers, then I could change and do it the right way. I even formed a mental system, which, however, was too lazy to formalize on paper. The injustice reigning around me was for me, though hidden, but a lump in my throat turning into a stone in my soul. I expected a chance and an opportunity for everything accumulated to be realized and corrected, and once the opportunity turned up.
Be careful of your desires - they come true!
')
And so it happened that I was unexpectedly offered a leadership position that assessed my talents and skills and allowed me to realize my ambitions. The conversation with the manager ended in the best traditions of “ You are now the boss - manage ”. And now I had to embody the radiant and crystal clear light of justice and make people happy, carry the word and byte to people. However, almost immediately it turned out that this is somewhat more complicated than it previously seemed to me, that the angle of view on the problems from below and above differs somewhat, and the native code turned out to be more friendly than the vastness of problems and concerns. So now I decided to finally draw my dogmas on paper on behalf of the performer and from the prism of the chief. It is unlikely that I will say something new, except for what is written before me in good books, with the exception of examples from practice and jokes with jokes, so either scroll right away, or welcome under cat.
First of all, I will start by doing something and achieving something that you need to know, want and do. It is not enough to nod to luck or Peter’s principle: “ In a hierarchical system, any worker rises to the level of his incompetence .” Although this happens more often than I would like natural programmer justice. It is necessary to know more than the principle requires, than the possession of a diploma paper, than participation from the work process seen from your point of view gives. Being an ordinary employee, I was interested in how IT system architects and project managers do IT, how everything is connected and how it works, and why the hell do I write code. No, of course I understood abstractly that my software would be written into the controller’s memory, and the customer would give the money for the controller. But besides my code, there was still a lot of everything else, often, as it seemed to me, unnecessary (and sometimes it was), and it was vitally important for me to understand the essence and purpose of that mission, justice, which I carry in the name of the Moon.
Programmers, developers have a heightened sense of justice . If not, then this specialist is bad. Do not deal with him and do not rely on him. Good programmers do not compromise until they find the solution fair. Therefore, one of the most important motivations is a holy goal, goal management. A good example is the examples of Apple with its pacifism or Google with its freedom for employees. A good example is the same against the "evil" in the face of other companies. Having a goal, both in the workflow and at the company level, it is easier to determine the opportunities and resources that the contractor will use for his actions, he will eventually understand why and why he works, and that his captured bug will not fly anymore in the air, somewhere sitting in an airplane control controller, with hundreds of unsuspecting people about it, because his company, for example, set the highest goal for people's lives. The developer, having his own ideals and the measure of justice, will never go to a company that kills fur seals or cuts the budget for patching holes, if it contradicts his ideals. The style of the code will be critical for him (no, not the Indian code!), The number of cookies (do not allow someone to get!), The view from the window (at the head of the river, and the programmers at the brick wall) and the noise in office (managers always chat instead of work). From the point of view of other participants in the process, the developer may not always be right, but he has his own holy goals, dogmas, the violation of which is far worse than, for example, remuneration.
This is a very important point, the developer’s remuneration should be such that he does not think about his worries and does not look for fragments how to make money. And his success does not need confirmation in the form of awards. He works for the goal, for his justice, but not for encouragement. After eating a developer, you risk simply destroying an excellent specialist who could burn in his place much longer, illuminating the whole workflow with his ideas. However, if the developer puts money at the forefront, and regularly goes to ask the boss for bonuses - this is a sign of a problem. With a man or a process. A mistake was made, from which there is no reverse, but from the point of view of the process and management there is an opportunity for other employees to avoid a similar problem in the future.
I was not always paid as much as I would like and how much I needed, and sometimes I simultaneously climbed freelance sites, but at work I took the initiative to do my job ahead of time, helping lazy employees, in general, I I worked diligently, albeit with shoals, but I tried to work, not for prizes, but for success: "We are in the same team." In relation to myself, I was honest, but here a feeling of internal justice leaped: I work for the result, and a colleague for hours. I could work for two hours instead of eight with the same exhaust, I would not have to stand extra hours in traffic jams. I could not pay bonuses (if such was provided for), but from the result, from the budget of that employee-lazy. It would be possible to restore justice in different ways. But no one did. It was a management mistake, resulting in a drop in motivation and sitting out of hours on a chair. Never, under any circumstances, give a reason for developers to do someone else's work, even on their initiative. Change plans, expel negligent, let the complex tasks take the initiative, but do not allow the developer to feel the unfair division of labor. From the developer’s side, it’s worthwhile not to get carried away by the measure of his work, but it’s worth planning your time and letting your resources go in a different direction: learn, communicate, improve the process.
Perhaps from the point of view of the reader, you can say that it is your fault, that I myself did not do this? What did I plow on “that guy”? If many people can read the workplace and preserve the appearance of work, then it was hard for me, flipping through the manuals and writing the Qt code (let's say) for the place of the assembler, again due to a heightened sense of justice - to deceive the authorities? Yes, and doing something else at work is not welcome anywhere, and even more so to have side-projects. This is another of the management mistakes - not to train employees. The second important quality of the developer is learning . We, people associated with IT, are in a permanent state of study and improvement. It’s not enough for us to sharpen skills, and it’s interesting to write hello world on brainfuck, Tetris on Haskel and a lot of things that they don’t ask from us. We are interested in learning new things. And when I asked the management “Do you have any trainings, seminars?” - I was answered in the negative. They may not always be associated with work, which could bring risks and loss of resources on the part of the employer, but it would be positive to expand my sphere of knowledge and influence, exchange experience with other programmers, and know new products in my field. And there is nothing surprising in the fact that it was often fun for us to write an unreadable code, either beautiful or super-fast and low-level, where the battle took place for every bit, not byte, but for every beat. That, ultimately, although it did not contradict internal standards, caused management discontent: the code became person-dependent. The need for us fills the injustice.
This Google employee has the right to 20% of his time to engage in their projects, with the possibility of introducing them in the future, i.e. take the initiative. In practice, this is almost always not the case. Moreover, routine usually prevails in front of interesting tasks, and the absence of side projects is also detrimental to the atmosphere and motivation of developers. However, it is very difficult to kill the developer’s motivation, and his ideas and movements sooner or later reach the leadership. Not all of them are useful, of course, but none of them, as a rule, are harmful (unless, of course, the expert collapses the whole build with the latest commit'om with an extravagant and unapproved feature). However, throwing the results in the trash will be a cruel blow to it. For example, one that should in no way concern the whole architecture and subsequent iterations / testing. As an example, I can cite a purely aesthetic licking of code, tabs, typos in the comments (besides the new written function), or the addition of unit tests to MC \ DC. Obviously, such changes will not change anything functionally, they will simply lead to the fact that others will get into the update instead of one part of the code, and in general the changes will be more than expected. Problem: the result of the initiative will be thrown into the trash. Given that this is not a violation or a joint in the working process. Or the reverse side - innovation (feature, workflow, tool) will be accepted not under the author of the idea, but under the name of another employee or intermediate chief. On the one hand, this can be regarded as blatant theft, and on the other, as a signal to distrust the employee, which will affect his own assessment much worse.
In addition, the protection and cohesiveness of the development team is also important. The protection means the following fact that all that falls on the developer from above is accounting reports, rallies, SCRUM sprints (if the process is not adjusted), inventory, technical equipment, and the opportunity to participate in the life of the company, should be filtered by a buffer in the person of managers and management. Developers have a special life paradigm, a special ecosystem into which it is very risky to launch something incomprehensible. Keeping in mind a huge model, the interrelations of the project and the code cannot be distracted by “trivialities”, otherwise everything starts to collapse like a house of cards, and the hope to resume the work process becomes a mess, which the entire company will have to collect . But along with this it is important to note that participation in the life of the company is not just a way to see a bright goal, but also to feel its importance. The most common problem is the message “you are not making money”. IT people spend money without producing anything. And the sales department earns. Sells. Support works with customers. This statement is a beacon of a huge systemic problem, when even in a distributed concern the role of IT personnel is “unprofitable”, although, as a rule, automation and projects of one development team can bring thousands and millions of items for sale. The situation is especially bad with IT infrastructure departments, especially if they work well (rather than constantly pulling cables) and with testing (the code is written!). Such an attitude, although it generates a defensive reaction “stupid selling women”, but most importantly, often leads to neglect of the cog-developer, which holds the whole concern (and the final profit in the end): in domestic terms - in second-class chairs, in an opportunity to save (they do not complain to whom? they don’t work with people), cut the budget for cookies or mobile communications, leaving them to be devoured by wolves in a black forest, if the unfortunate programmer was lucky enough to go on a business trip to an object through dark forests.
Developers are very patient people, because they usually know that, firstly, they are not offended by fools, and secondly, they carry water to offended people. But if the employee initially came to the company where there were free cookies, and the view from the window was on the undergrowth, and as time passed, this was deprived of it - wait for trouble. The conviction that in the financial department and boiling water paid is unlikely to work. It was better - it became worse, and besides, now the view from the window on the pet cemetery. This is because the developer is a progressive creature, and if he sees regression, which he cannot cope with, from which there is no protection, then this also demotivates him.
Team cohesiveness is a very important thing, and it is somehow difficult to form it into a management form. Solidarity is the ability of a team to go together in the same team and complement each other, to have common interests, not highlighting the “worst and best”. I have already said above that goals and tasks should not intersect; there should be no competition and rivalry between people. Ratings, promotions, carrots and cookies, especially cookies for the elect, are the dark side of evil. And no less evil - the team itself. The developer comes to work with the desire to be understood and accepted. And the points of contact are important. Often the points of contact form subgroups, interest groups. In any society, this is normal, but unacceptable in the work process. What am I worse, in fact, that I do not belong to this group of fans of poker interfaces? The problem is when the core of the group simply diverges from the core of the person. For example, a daily discussion of news portals or an unloved sport will cause discontent. Just because a person does not read the yellow news and does not look at the fascinating kicking of the nuclei with his left little finger. Further, unification into such communities will simply cause internecine gatherings and patronage, the promotion of one over the other. In an ordinary society, these are communication problems, but in a technical society, in the IT environment, as poorly communicative communication skills, this problem can be terminal. Moreover, it is a reason to think if one of the employees is studying manuals, reading thematic resources, and approaching colleagues with a desire to share “I found such a framework here” hears in response “that this is nonsense, we are not interested”. This is a reason for the developer to think about - is he there at all? And an excuse for the management to think about employees: are they busy and are they the right people? The ability to solve problems and tasks without professional interest is a sign of the process and team rotting. Therefore, interest is the third important quality of the developer .
All these problems translate into feelings of injustice and wrongness. The process, people, everything that surrounds a person. And it is with these factors that I, as a manager, had to fight and not repeat the same mistakes.
To do this, you can make a final list of everything I listed above:
Regarding the latter, I can say that this is one of the key points for management. The team is the support of the manager, and the stronger the team, the more satisfied the developer, the more opportunities he has to complete the project on time, hand it over to the customer and make it perfect.
We will talk about other problems, experience and details next time.
Be careful of your desires - they come true!
')
And so it happened that I was unexpectedly offered a leadership position that assessed my talents and skills and allowed me to realize my ambitions. The conversation with the manager ended in the best traditions of “ You are now the boss - manage ”. And now I had to embody the radiant and crystal clear light of justice and make people happy, carry the word and byte to people. However, almost immediately it turned out that this is somewhat more complicated than it previously seemed to me, that the angle of view on the problems from below and above differs somewhat, and the native code turned out to be more friendly than the vastness of problems and concerns. So now I decided to finally draw my dogmas on paper on behalf of the performer and from the prism of the chief. It is unlikely that I will say something new, except for what is written before me in good books, with the exception of examples from practice and jokes with jokes, so either scroll right away, or welcome under cat.
First of all, I will start by doing something and achieving something that you need to know, want and do. It is not enough to nod to luck or Peter’s principle: “ In a hierarchical system, any worker rises to the level of his incompetence .” Although this happens more often than I would like natural programmer justice. It is necessary to know more than the principle requires, than the possession of a diploma paper, than participation from the work process seen from your point of view gives. Being an ordinary employee, I was interested in how IT system architects and project managers do IT, how everything is connected and how it works, and why the hell do I write code. No, of course I understood abstractly that my software would be written into the controller’s memory, and the customer would give the money for the controller. But besides my code, there was still a lot of everything else, often, as it seemed to me, unnecessary (and sometimes it was), and it was vitally important for me to understand the essence and purpose of that mission, justice, which I carry in the name of the Moon.
Programmers, developers have a heightened sense of justice . If not, then this specialist is bad. Do not deal with him and do not rely on him. Good programmers do not compromise until they find the solution fair. Therefore, one of the most important motivations is a holy goal, goal management. A good example is the examples of Apple with its pacifism or Google with its freedom for employees. A good example is the same against the "evil" in the face of other companies. Having a goal, both in the workflow and at the company level, it is easier to determine the opportunities and resources that the contractor will use for his actions, he will eventually understand why and why he works, and that his captured bug will not fly anymore in the air, somewhere sitting in an airplane control controller, with hundreds of unsuspecting people about it, because his company, for example, set the highest goal for people's lives. The developer, having his own ideals and the measure of justice, will never go to a company that kills fur seals or cuts the budget for patching holes, if it contradicts his ideals. The style of the code will be critical for him (no, not the Indian code!), The number of cookies (do not allow someone to get!), The view from the window (at the head of the river, and the programmers at the brick wall) and the noise in office (managers always chat instead of work). From the point of view of other participants in the process, the developer may not always be right, but he has his own holy goals, dogmas, the violation of which is far worse than, for example, remuneration.
This is a very important point, the developer’s remuneration should be such that he does not think about his worries and does not look for fragments how to make money. And his success does not need confirmation in the form of awards. He works for the goal, for his justice, but not for encouragement. After eating a developer, you risk simply destroying an excellent specialist who could burn in his place much longer, illuminating the whole workflow with his ideas. However, if the developer puts money at the forefront, and regularly goes to ask the boss for bonuses - this is a sign of a problem. With a man or a process. A mistake was made, from which there is no reverse, but from the point of view of the process and management there is an opportunity for other employees to avoid a similar problem in the future.
I was not always paid as much as I would like and how much I needed, and sometimes I simultaneously climbed freelance sites, but at work I took the initiative to do my job ahead of time, helping lazy employees, in general, I I worked diligently, albeit with shoals, but I tried to work, not for prizes, but for success: "We are in the same team." In relation to myself, I was honest, but here a feeling of internal justice leaped: I work for the result, and a colleague for hours. I could work for two hours instead of eight with the same exhaust, I would not have to stand extra hours in traffic jams. I could not pay bonuses (if such was provided for), but from the result, from the budget of that employee-lazy. It would be possible to restore justice in different ways. But no one did. It was a management mistake, resulting in a drop in motivation and sitting out of hours on a chair. Never, under any circumstances, give a reason for developers to do someone else's work, even on their initiative. Change plans, expel negligent, let the complex tasks take the initiative, but do not allow the developer to feel the unfair division of labor. From the developer’s side, it’s worthwhile not to get carried away by the measure of his work, but it’s worth planning your time and letting your resources go in a different direction: learn, communicate, improve the process.
Perhaps from the point of view of the reader, you can say that it is your fault, that I myself did not do this? What did I plow on “that guy”? If many people can read the workplace and preserve the appearance of work, then it was hard for me, flipping through the manuals and writing the Qt code (let's say) for the place of the assembler, again due to a heightened sense of justice - to deceive the authorities? Yes, and doing something else at work is not welcome anywhere, and even more so to have side-projects. This is another of the management mistakes - not to train employees. The second important quality of the developer is learning . We, people associated with IT, are in a permanent state of study and improvement. It’s not enough for us to sharpen skills, and it’s interesting to write hello world on brainfuck, Tetris on Haskel and a lot of things that they don’t ask from us. We are interested in learning new things. And when I asked the management “Do you have any trainings, seminars?” - I was answered in the negative. They may not always be associated with work, which could bring risks and loss of resources on the part of the employer, but it would be positive to expand my sphere of knowledge and influence, exchange experience with other programmers, and know new products in my field. And there is nothing surprising in the fact that it was often fun for us to write an unreadable code, either beautiful or super-fast and low-level, where the battle took place for every bit, not byte, but for every beat. That, ultimately, although it did not contradict internal standards, caused management discontent: the code became person-dependent. The need for us fills the injustice.
This Google employee has the right to 20% of his time to engage in their projects, with the possibility of introducing them in the future, i.e. take the initiative. In practice, this is almost always not the case. Moreover, routine usually prevails in front of interesting tasks, and the absence of side projects is also detrimental to the atmosphere and motivation of developers. However, it is very difficult to kill the developer’s motivation, and his ideas and movements sooner or later reach the leadership. Not all of them are useful, of course, but none of them, as a rule, are harmful (unless, of course, the expert collapses the whole build with the latest commit'om with an extravagant and unapproved feature). However, throwing the results in the trash will be a cruel blow to it. For example, one that should in no way concern the whole architecture and subsequent iterations / testing. As an example, I can cite a purely aesthetic licking of code, tabs, typos in the comments (besides the new written function), or the addition of unit tests to MC \ DC. Obviously, such changes will not change anything functionally, they will simply lead to the fact that others will get into the update instead of one part of the code, and in general the changes will be more than expected. Problem: the result of the initiative will be thrown into the trash. Given that this is not a violation or a joint in the working process. Or the reverse side - innovation (feature, workflow, tool) will be accepted not under the author of the idea, but under the name of another employee or intermediate chief. On the one hand, this can be regarded as blatant theft, and on the other, as a signal to distrust the employee, which will affect his own assessment much worse.
In addition, the protection and cohesiveness of the development team is also important. The protection means the following fact that all that falls on the developer from above is accounting reports, rallies, SCRUM sprints (if the process is not adjusted), inventory, technical equipment, and the opportunity to participate in the life of the company, should be filtered by a buffer in the person of managers and management. Developers have a special life paradigm, a special ecosystem into which it is very risky to launch something incomprehensible. Keeping in mind a huge model, the interrelations of the project and the code cannot be distracted by “trivialities”, otherwise everything starts to collapse like a house of cards, and the hope to resume the work process becomes a mess, which the entire company will have to collect . But along with this it is important to note that participation in the life of the company is not just a way to see a bright goal, but also to feel its importance. The most common problem is the message “you are not making money”. IT people spend money without producing anything. And the sales department earns. Sells. Support works with customers. This statement is a beacon of a huge systemic problem, when even in a distributed concern the role of IT personnel is “unprofitable”, although, as a rule, automation and projects of one development team can bring thousands and millions of items for sale. The situation is especially bad with IT infrastructure departments, especially if they work well (rather than constantly pulling cables) and with testing (the code is written!). Such an attitude, although it generates a defensive reaction “stupid selling women”, but most importantly, often leads to neglect of the cog-developer, which holds the whole concern (and the final profit in the end): in domestic terms - in second-class chairs, in an opportunity to save (they do not complain to whom? they don’t work with people), cut the budget for cookies or mobile communications, leaving them to be devoured by wolves in a black forest, if the unfortunate programmer was lucky enough to go on a business trip to an object through dark forests.
Developers are very patient people, because they usually know that, firstly, they are not offended by fools, and secondly, they carry water to offended people. But if the employee initially came to the company where there were free cookies, and the view from the window was on the undergrowth, and as time passed, this was deprived of it - wait for trouble. The conviction that in the financial department and boiling water paid is unlikely to work. It was better - it became worse, and besides, now the view from the window on the pet cemetery. This is because the developer is a progressive creature, and if he sees regression, which he cannot cope with, from which there is no protection, then this also demotivates him.
Team cohesiveness is a very important thing, and it is somehow difficult to form it into a management form. Solidarity is the ability of a team to go together in the same team and complement each other, to have common interests, not highlighting the “worst and best”. I have already said above that goals and tasks should not intersect; there should be no competition and rivalry between people. Ratings, promotions, carrots and cookies, especially cookies for the elect, are the dark side of evil. And no less evil - the team itself. The developer comes to work with the desire to be understood and accepted. And the points of contact are important. Often the points of contact form subgroups, interest groups. In any society, this is normal, but unacceptable in the work process. What am I worse, in fact, that I do not belong to this group of fans of poker interfaces? The problem is when the core of the group simply diverges from the core of the person. For example, a daily discussion of news portals or an unloved sport will cause discontent. Just because a person does not read the yellow news and does not look at the fascinating kicking of the nuclei with his left little finger. Further, unification into such communities will simply cause internecine gatherings and patronage, the promotion of one over the other. In an ordinary society, these are communication problems, but in a technical society, in the IT environment, as poorly communicative communication skills, this problem can be terminal. Moreover, it is a reason to think if one of the employees is studying manuals, reading thematic resources, and approaching colleagues with a desire to share “I found such a framework here” hears in response “that this is nonsense, we are not interested”. This is a reason for the developer to think about - is he there at all? And an excuse for the management to think about employees: are they busy and are they the right people? The ability to solve problems and tasks without professional interest is a sign of the process and team rotting. Therefore, interest is the third important quality of the developer .
All these problems translate into feelings of injustice and wrongness. The process, people, everything that surrounds a person. And it is with these factors that I, as a manager, had to fight and not repeat the same mistakes.
To do this, you can make a final list of everything I listed above:
- be reasonable and see the point of view of the developer;
- be open to feedback;
- have the authority of a person who knows the subject;
- to develop people without fear that they will leave;
- trust and delegate control;
- not make promises that cannot be fulfilled;
- manage the team and the selection of people;
- develop a goal and values;
- have an open and clear process;
- protect the interests of the team first.
Regarding the latter, I can say that this is one of the key points for management. The team is the support of the manager, and the stronger the team, the more satisfied the developer, the more opportunities he has to complete the project on time, hand it over to the customer and make it perfect.
We will talk about other problems, experience and details next time.
Source: https://habr.com/ru/post/146917/
All Articles