44 lesson control technicians
I offer Habr's readers my translation of the article “44 lessons on the management of technicians” of Slava Akhmechet, co-founder of RethinkDB . In the original article, the term “engineers” is used, but in the context of the article I will also use the term “techies” - a more comprehensive, I think, word from the point of view of the Russian language, covering IT professions, of which I am also a part.
A little about the original text. The article was written in 2014 in the personal blog of the author, in October 2016, the RethinkDB company could not go into profit and closed, which was written here and here on Habré, and Slava thought about it here .
In the comments to the article, I would like the readers to give their assessment of these lessons and express their opinion on the question that will be asked at the end of the article.
')
A source
Oh, and one last minute. In some places, the author’s wording was quite intricate, so all comments and suggestions for translation are welcome in the format of personal messages.
So let's go.
Welcome to the techie management lesson. The process is cool, exhausting, rewarding, but, more importantly, it is completely new. Approaches that used to work no longer work. You will need to pump new skills and in the process to get rid of some bad habits. Here you have a little instruction on where to start.
1. Involve, educate, be a mentor and a keeper of talents. Talk with your engineers to see what's bothering them. If there is something like this, try to solve this problem right away if you can.
2. Discuss with each engineer the following big task that he will have to work on. This is the second important point affecting the performance of a techie.
3. Be the arbiter if the team cannot agree.
4. Be a source of information. Stay up to date on what each of your engineers is working on and help build connections where they never appear without you.
5. Provide administrative support. If necessary, scatter tasks in the bugtracker, coordinate releases of product versions and keep your finger on the pulse of the bureaucratic machine - it should work.
6. Introduce performance standards and behavioral philosophy. Dismiss inadequate and unqualified employees.
7. Do not try to fix the code and cut the features yourself. You can write code only in one case, if you need to resolve the conflict between developers. Everything.
8. Do not control the quality and amount of work that employees do. The development process is not a pipeline. ( Approx. Translator - I would argue with that. Depends on the project. For each individual developer, this is not a conveyor, but the scale of the information system that the team creates, even to yourself. ) If you enter the process with your control too often, This means that you have not connected the right people or have given them an incentive to grow.
9. You are the one who hires and dismisses. Everything that happens in your team is your personal responsibility.
10. IT is a market: people work for you because they believe in you. Access to the talent of people is a privilege.
11. Authority does not come just like that - it is earned by making the right decisions every day.
12. Do not make decisions, except when you are forced to do so. Always, if possible, let the team generate ideas and make decisions on their own.
A source
13. Be sure to make decisions in exceptional situations. Few things in the world are so demotivating the team as the feeling that the project has stalled.
14. Do not kill ideas on the vine, if this is not necessary. Create an environment in which each employee will feel relaxed and confident when proposing and discussing ideas. The guys "in the fields" ( approx. Translator - here I deliberately made a generalization, as it concerns not only the development team ) much more information than you have. Rely on your team, and your decisions will be more informed and correct.
15. Developing intuition in making the right decisions and creating a close relationship with your team is 95% success on the way to achieving your goals. Many high-level frameworks for organizing workflow IT teams do not have a very strong impact on the result. Frameworks make good managers better, and bad they only hurt.
16. Being a leader is considered prestigious in modern culture, but it is the same skill as everyone else. Aura prestige distracts - it is inconstant and random. Fight the feeling that you are something better than anyone around you. The sooner you overcome the sense of superiority, the sooner you can concentrate on doing your job well.
17. Leaders are often surrounded by contempt. Do not pay attention to this. People who consider managers useless do not understand the subtleties of the process of creating a winning team.
18. If you feel that something is wrong, most likely you are right. Do not let anyone bring you to a state where you stop trusting your instincts.
19. If you catch yourself in the process of scolding your employee for a joint at work, most likely you are wrong. No one wakes up in the morning to come to work and make a special mess. In 95% of cases, you can solve a problem just by talking to people.
20. Most people have a hard time sharing their true emotions. Try to talk informally, catch the mood of a person, and if you find out that something is wrong, correct this problem if you can.
21. Your team expects leader behavior from you. Have the courage to say out loud everything as it is, especially if everyone understands this, but does not talk about it.
22. You get paid to identify and correct cultural problems, the existence of which your team may not even guess. Take courage and tell us what everyone should know, but still do not know.
23. Hire valuable people and trust them completely. Introduce a monthly or quarterly system of reports to measure progress; use the results to identify those with whom you should say goodbye. Do not require daily reports, this approach will drive everyone crazy, including you.
24. The most reasonable arguments are rooted in strong internal emotions. Your effectiveness will increase significantly if you learn to recognize these emotions.
25. Do not rush to judge too quickly: in fact, you are right less often than you think. Even if every time you are sure you are right, wait for everyone to speak out.
26. As soon as everyone speaks out, summarize what he heard so clearly and clearly that each of the participants could say: “Thank you! From this perspective, I would not even have thought of looking at this story. ” List everything with which you agree, and indicate what you learned from each of the interlocutors. Then make a decision.
27. Make a decision, implement it. Do not allow the team to stagnate, so as not to provoke discontent.
28. Go back to the story in case of new important information.
29. When in disagreements they become personal, conflict arises.
30. Most conflicts originate from the fact that people think that they have not been heard. Speak with each situation personally, specify what the person thinks about it. Ask again. And again. After that, tell how you understood what was said. In most cases, this alone will help solve the problem.
A source
31. If the conflict continues to grow after you have exhausted all reasonable opportunities to listen to everyone and solve problems, it is time for difficult conversations.
32. Do not delay a difficult conversation! This will only complicate the situation.
A source
33. Do not assume anything and do not draw conclusions in advance. Do not think of people as monsters. Do not blame, do not shout, do not denigrate anyone.
34. Resort to "non-violent communication" (NNO) : this is the best way I know to criticize people without offending them. Yes, it sounds like another managerial trick, but the truth works (I promise).
35. Do not be afraid to talk about what you feel and what you need. People are attracted by the vulnerability of others, but their own is annoying. Vulnerability is not a weakness.
36. Expect people to do the same. If because of someone you feel awkward, expressing your thoughts and feelings, the reason is in them, not in you.
37. People will constantly provoke you to determine your limit. To know when to stand to the end, and when to retreat is half the battle won.
38. One day someone will go too far. When this happens, clearly and firmly report this, otherwise you risk losing credibility in the eyes of the team.
39. Usually the phrase “Do not do that”, pronounced with a serious look, is enough.
A source
40. Do not laugh at things that do not seem at all ridiculous. Do not be afraid to show exactly the emotions that you experience.
41. If you repeat “Do not do this” too often, to the same person, your job is to part with it.
42. Dismissal is a difficult process, and you will invent excuses not to bring this up (unless, of course, you are a sociopath). If you find yourself constantly thinking about someone’s usefulness to the team, have courage and do what is right.
43. Do not let others force you to make decisions with which you disagree. Then they will call you responsible for this, and, by the way, they will be right. Making decisions is your responsibility.
44. Believe in yourself. You will not be able to lead a squad of cavalrymen into battle if you think that you look ridiculous on a horse.
OK. All lessons are over, now - the promised questions.
On the one hand, RethinkDB has closed.
On the other hand, the RethinkDB team created a product that even after the closure of the company continues to live and develop within the Open Source community. I am sure that this happened also thanks to the culture and atmosphere that we managed to create in the team of technicians not without the help of "44 lessons."
Now let's think, if companies open and close, products are created, some do not even die, and techies are increasingly not working “in companies”, but “wander” between projects interesting for them, is it worth it for companies to invest in the strategic development of techies , to recruit students without experience, to pump them so that they later went to work on another project? Wouldn't it be more correct to put together a team for a project, do business and go away, get your hard-earned money and not bother?
For myself, I decided on the answer to this question, but, in my opinion, the topic is ambiguous and strongly depends, as they say, on the context.
I would like to hear the opinion of Habr's readers on this subject and at the same time try to jointly formulate the criteria for that very “context” when it is necessary to apply “44 lessons” or something similar, and when it is enough to do the good old lesson of “carrot and stick”.
A little about the original text. The article was written in 2014 in the personal blog of the author, in October 2016, the RethinkDB company could not go into profit and closed, which was written here and here on Habré, and Slava thought about it here .
In the comments to the article, I would like the readers to give their assessment of these lessons and express their opinion on the question that will be asked at the end of the article.
')
Oh, and one last minute. In some places, the author’s wording was quite intricate, so all comments and suggestions for translation are welcome in the format of personal messages.
So let's go.
Welcome to the techie management lesson. The process is cool, exhausting, rewarding, but, more importantly, it is completely new. Approaches that used to work no longer work. You will need to pump new skills and in the process to get rid of some bad habits. Here you have a little instruction on where to start.
# Do
1. Involve, educate, be a mentor and a keeper of talents. Talk with your engineers to see what's bothering them. If there is something like this, try to solve this problem right away if you can.
2. Discuss with each engineer the following big task that he will have to work on. This is the second important point affecting the performance of a techie.
3. Be the arbiter if the team cannot agree.
4. Be a source of information. Stay up to date on what each of your engineers is working on and help build connections where they never appear without you.
5. Provide administrative support. If necessary, scatter tasks in the bugtracker, coordinate releases of product versions and keep your finger on the pulse of the bureaucratic machine - it should work.
6. Introduce performance standards and behavioral philosophy. Dismiss inadequate and unqualified employees.
#Do not do it
7. Do not try to fix the code and cut the features yourself. You can write code only in one case, if you need to resolve the conflict between developers. Everything.
8. Do not control the quality and amount of work that employees do. The development process is not a pipeline. ( Approx. Translator - I would argue with that. Depends on the project. For each individual developer, this is not a conveyor, but the scale of the information system that the team creates, even to yourself. ) If you enter the process with your control too often, This means that you have not connected the right people or have given them an incentive to grow.
# Motivation and culture
9. You are the one who hires and dismisses. Everything that happens in your team is your personal responsibility.
10. IT is a market: people work for you because they believe in you. Access to the talent of people is a privilege.
11. Authority does not come just like that - it is earned by making the right decisions every day.
12. Do not make decisions, except when you are forced to do so. Always, if possible, let the team generate ideas and make decisions on their own.
13. Be sure to make decisions in exceptional situations. Few things in the world are so demotivating the team as the feeling that the project has stalled.
14. Do not kill ideas on the vine, if this is not necessary. Create an environment in which each employee will feel relaxed and confident when proposing and discussing ideas. The guys "in the fields" ( approx. Translator - here I deliberately made a generalization, as it concerns not only the development team ) much more information than you have. Rely on your team, and your decisions will be more informed and correct.
15. Developing intuition in making the right decisions and creating a close relationship with your team is 95% success on the way to achieving your goals. Many high-level frameworks for organizing workflow IT teams do not have a very strong impact on the result. Frameworks make good managers better, and bad they only hurt.
# Emotions and people
16. Being a leader is considered prestigious in modern culture, but it is the same skill as everyone else. Aura prestige distracts - it is inconstant and random. Fight the feeling that you are something better than anyone around you. The sooner you overcome the sense of superiority, the sooner you can concentrate on doing your job well.
17. Leaders are often surrounded by contempt. Do not pay attention to this. People who consider managers useless do not understand the subtleties of the process of creating a winning team.
18. If you feel that something is wrong, most likely you are right. Do not let anyone bring you to a state where you stop trusting your instincts.
19. If you catch yourself in the process of scolding your employee for a joint at work, most likely you are wrong. No one wakes up in the morning to come to work and make a special mess. In 95% of cases, you can solve a problem just by talking to people.
20. Most people have a hard time sharing their true emotions. Try to talk informally, catch the mood of a person, and if you find out that something is wrong, correct this problem if you can.
21. Your team expects leader behavior from you. Have the courage to say out loud everything as it is, especially if everyone understands this, but does not talk about it.
22. You get paid to identify and correct cultural problems, the existence of which your team may not even guess. Take courage and tell us what everyone should know, but still do not know.
23. Hire valuable people and trust them completely. Introduce a monthly or quarterly system of reports to measure progress; use the results to identify those with whom you should say goodbye. Do not require daily reports, this approach will drive everyone crazy, including you.
24. The most reasonable arguments are rooted in strong internal emotions. Your effectiveness will increase significantly if you learn to recognize these emotions.
# Conflicts and their resolution
25. Do not rush to judge too quickly: in fact, you are right less often than you think. Even if every time you are sure you are right, wait for everyone to speak out.
26. As soon as everyone speaks out, summarize what he heard so clearly and clearly that each of the participants could say: “Thank you! From this perspective, I would not even have thought of looking at this story. ” List everything with which you agree, and indicate what you learned from each of the interlocutors. Then make a decision.
27. Make a decision, implement it. Do not allow the team to stagnate, so as not to provoke discontent.
28. Go back to the story in case of new important information.
29. When in disagreements they become personal, conflict arises.
30. Most conflicts originate from the fact that people think that they have not been heard. Speak with each situation personally, specify what the person thinks about it. Ask again. And again. After that, tell how you understood what was said. In most cases, this alone will help solve the problem.
A source
31. If the conflict continues to grow after you have exhausted all reasonable opportunities to listen to everyone and solve problems, it is time for difficult conversations.
# Difficult conversations
32. Do not delay a difficult conversation! This will only complicate the situation.
33. Do not assume anything and do not draw conclusions in advance. Do not think of people as monsters. Do not blame, do not shout, do not denigrate anyone.
34. Resort to "non-violent communication" (NNO) : this is the best way I know to criticize people without offending them. Yes, it sounds like another managerial trick, but the truth works (I promise).
35. Do not be afraid to talk about what you feel and what you need. People are attracted by the vulnerability of others, but their own is annoying. Vulnerability is not a weakness.
36. Expect people to do the same. If because of someone you feel awkward, expressing your thoughts and feelings, the reason is in them, not in you.
# Roughness
37. People will constantly provoke you to determine your limit. To know when to stand to the end, and when to retreat is half the battle won.
38. One day someone will go too far. When this happens, clearly and firmly report this, otherwise you risk losing credibility in the eyes of the team.
39. Usually the phrase “Do not do that”, pronounced with a serious look, is enough.
40. Do not laugh at things that do not seem at all ridiculous. Do not be afraid to show exactly the emotions that you experience.
41. If you repeat “Do not do this” too often, to the same person, your job is to part with it.
42. Dismissal is a difficult process, and you will invent excuses not to bring this up (unless, of course, you are a sociopath). If you find yourself constantly thinking about someone’s usefulness to the team, have courage and do what is right.
43. Do not let others force you to make decisions with which you disagree. Then they will call you responsible for this, and, by the way, they will be right. Making decisions is your responsibility.
44. Believe in yourself. You will not be able to lead a squad of cavalrymen into battle if you think that you look ridiculous on a horse.
OK. All lessons are over, now - the promised questions.
On the one hand, RethinkDB has closed.
By the way, this is a fairly frequent story in the industry.
For example, recently the company Basho, the developer of the Riak DB, went into debt and was purchased by Bet365 (I will not give you the link, their website does not open on the territory of the Russian Federation). They promise to give all the code to the community, which is now in the process of working on a new charter .
On the other hand, the RethinkDB team created a product that even after the closure of the company continues to live and develop within the Open Source community. I am sure that this happened also thanks to the culture and atmosphere that we managed to create in the team of technicians not without the help of "44 lessons."
Now let's think, if companies open and close, products are created, some do not even die, and techies are increasingly not working “in companies”, but “wander” between projects interesting for them, is it worth it for companies to invest in the strategic development of techies , to recruit students without experience, to pump them so that they later went to work on another project? Wouldn't it be more correct to put together a team for a project, do business and go away, get your hard-earned money and not bother?
For myself, I decided on the answer to this question, but, in my opinion, the topic is ambiguous and strongly depends, as they say, on the context.
I would like to hear the opinion of Habr's readers on this subject and at the same time try to jointly formulate the criteria for that very “context” when it is necessary to apply “44 lessons” or something similar, and when it is enough to do the good old lesson of “carrot and stick”.
Source: https://habr.com/ru/post/339712/
All Articles