Saving the drowning is our business: how to deal with team demotivation
I am 18 years old in IT. I lead the last 10 of them: 200 people were under my command at different times.
Interestingly, I remember everyone who quit and for what reason. I remember not because I have a good memory, but because they quit very rarely.
In this article I will tell you what, from my point of view, keeps a person in a team. I’ll share how to encourage people to have a different attitude to work and ultimately overcome the problems of demotivation. And also - I will discuss how we heat up various thoughts and interests inside ourselves, what burns out most, drowns people, and why drowning people can not always get out on their own.
I gave a talk on this topic at Badoo TechLeads Meetup No. 4 ( video) My story is most likely not suitable for those whose team has more than 100 people: I will talk about the level of team lead, technical leader, technical director of a small company. I myself started with a small company. When he joined the mos.ru team, we had three engineers. During the year we grew to 40, in two years - to 80. Now, at different times of the day and depending on the weather, we are up to hundreds of people.
I’ll tell you about them.
What are the problems? Burnout and demotivation.
Who has them? Yes, almost everyone.
Can anyone give a definition of at least one of them?
Most likely no. Because everyone is sick in his own way, and talking about everyone will be too abstract.
Therefore, I will concentrate on simple, frequently asked questions:
At the interview, you ask the candidates: “What do you want?” - “Interesting tasks!” - “What are interesting tasks in your understanding?” At this point, a pause most often arises because few people can explain what an interesting task is. Nevertheless, everyone believes that they should be at work.
All these problems are, of course, a consequence. The investigation has reasons.
Some of the reasons are probably familiar to many of you. First come to mind:
If we now begin to list everything, then at least a hundred will be typed. Moreover, each will have its own, unique reasons, which are often embarrassed to talk about.
They begin to fight with them only when the problem is already there. Most people who suffer from these problems already get sick seriously enough. But when you walk as a team leader and look at the team, the team looks calm enough outwardly: everything is fine, everything works.
Leaders at this moment have a false sense of stability : you look at the situation outside and think that everything is fine. And if you start poking around this business with a knife or file, it turns out that this is not at all the case.
In addition, there is a concomitant problem - a false sense of control. You begin to think that the whole process that takes place in your team is controlled by you: you are great, you know what happens to people and how, what bad and good things are.
In the end, it turns out that you are all so good, but at the same time everything is on fire, your people are on fire. They get bored, for some reason they leave. The reason they usually call is more money. But if we talk more closely with people, it turns out that this is not the problem at all.
How to prevent such situations? I will talk about techniques that I have been using for several years and which, from my point of view, make it possible to make people's lives more comfortable.
Before that, I’ll talk a little about myself. The team I'm working in now makes the portal mos.ru. We are absolutely the same as most IT companies: we have legacy, technology zoo, lack of documentation. Requirements vary with space speeds.
By and large, we are no different except for one fact: we grew from the very beginning using these tricks.
We show how our team is moving forward: it is developing, reaching heights, it is lying (who does not lie, he does nothing). Demonstrations are ongoing.
Previously, only team members came to them. For six months now, we have been inviting everyone who is important to see the system moving for demonstrations. We are holding internal meetings where we discuss what new cool things have been done. These mitaps are not only thematic - for example, for the backend. No, everyone comes to the mitap for the backend, including designers. They are interested in listening, talking, learning what is happening.
An important point that many people forget about is the influence of the external environment: what is happening around us, around the team, and the project. People are interested to see how the movement within the team corresponds to the movement that is happening around.
How does this technique help in everyday life? We, like many, sometimes have to recycle: linger in the evening or go out on Saturday. I never force refining, but I always explain what is happening and why. For example, that there is a new large project that is socially important for Muscovites, where city residents will be able to see what improvements will happen in its area in the near future. That 500 people went through these yards, counted and recorded the necessary information. The developer understands that he is involved in a large and complex process, knows why he works this way. And in most cases I’m ready to help.
For some reason, they usually do not like to talk about such nuances, although there is no secret in them.
The team must understand what is happening and why. Where we are at the current moment in time, how it corresponds to plans and promises, what our future is.
Lack of plans is a thing that greatly affects a person’s internal state. When he realizes that the WP-blog that he is programming now, another five years will be the WP-blog that he will program, the developer is very sad. Therefore, we are trying to tell what changes in the near future will occur in the external environment, what will change, what large projects will be.
We were able to agree with the management that from time to time, every six months we are given information about this. And we learn that, for example, we are not doing anything new just because something new and cool is being prepared.
By the way, in order to do something new and cool in the city — for example, to translate some process into electronic form — very often it is necessary to prepare documentation and legislative base.
Take, for example, recording a child in a pioneer camp. It would seem that it could be simpler: I came, I filled out the form - and please. And then the details begin: how to equalize the rights of those people who submitted the application physically and those who submitted it via electronic form?
Everything connected with the state and society is quite serious. Therefore, we have to explain why everything is so, and not different. Sometimes we don’t release it, because a certain resolution does not reach the phase where we can release the product. This is an infrequent effect, but nevertheless it happens. If the developers know about this, they understand that we did not “dump and quit,” - we just have this mode of operation. They begin to take it calmly.
Freedom is good. But complete freedom is bad.
Since childhood, we are used to having someone caring for us. First, parents followed, then teachers in the kindergarten, then teachers at the institute, then the head. If it seems that the boss is not following you, the question most often arises: maybe he doesn’t care, maybe he is not interested in all this, did he even want to spit on this? Complete freedom is ultimately a problem. Therefore, freedom must be given, but not complete, but limited. Tell people that there is a canvas, and within this canvas they can move.
For example, we agreed that we program in PHP - it happened historically. Inside this - libraries, approaches, OOP, not OOP, to write this way or that, some patterns - this, please, you yourself. But in PHP.
When people come and say: “I want Go,” I say, “Let's think about how much your“ want ”can be realized in“ I can, ”into something useful.” As a result, the developer knows that he has the opportunity to put forward proposals, but in order for these proposals to get into production, you will need to work. They know these rules of the game, they know that there is such an opportunity. Some people use it: therefore, we have not only PHP, but also other programming languages.
We let people into the processes, but with some restrictions. The limitation is that we have nine teams, nine processes, and there is also a root process - a release that governs output. He is one for all.
Around this process, the guys do what they like best.
Our product and business processes are quite different. For example, the command that saws the search is internal. The search requirements are most often generated by ourselves. There are teams that program mobile applications, there is a completely different kitchen. There is a web that exists as a separate product, there is a web that exists as a newsroom with an admin panel. Everything is different there, but the release processes are the same for everyone.
Limited freedom looks like this: do what you want, but don’t touch this piece. Thanks to this, I have already forgotten about what critical errors in production are. Because there is a clear rule that says how to do it. If you want to play, play: in fact, we have not a single documented process right now, except for the release. At the same time, people feel comfortable.
A tricky trick: we call it “spin the drum”, but you can rotate the carousel or concrete mixer - call it whatever you like. The point is that we completely consciously do not bind people to tasks.
We don’t have one so that someone from the frontend, backend or from DevOps could not do any other task. Code ownership - we simply do not have this.
Firstly, it adds interest to people, and secondly, it increases the notorious bus factor. Thirdly, I can quite easily transfer people between teams, assemble teams from four other teams for large projects. They begin to work in just two days: they finish their tasks in two days, and then they got together and drove off.
The largest and most important project that I mentioned above was made by three teams. Moreover, one has never interacted with the other two before: the guys just came and accepted the rules of the game. On average, we do such projects with a hodgepodge of guys every six months. Due to the fact that they are generally not tied to any specific duties, they feel great.
There is one more chip that we try, and we succeed - we do not just let people go, we try to detain them in a team, even in a different area.
Suppose I had an automation engineer, a tester. He wrote autotests in Python. Tired of testing, he said he wanted to be a Python developer. It would seem that one could tell him: “Go and program in Python.” But at that moment it turned out that we needed a Python developer in the mobile. We sent him there: firstly, we did not lose knowledge in autotests, secondly, the person did not disappear, and we saved on search.
I have several such stories. When we introduced the release management process, we converted two testers into release managers, and they feel great. We are turning coders into front-end developers. I recently found out that one of the PHP developers spent the night programming in Python. It would seem that you can also let go, but we decided to play the game: I came to the search team, who have a Python backend, and asked me to give me a difficult non-urgent task. What difference does it make that he programs in Python at night? Let him program something we need. If it succeeds, then we will define it there as a junior Python developer from a senior PHP developer. There is such a desire in people, what can you do?
At these receptions, I did not lose 5-6 people from the team, I just redirected them.
I talked about the techniques that I use. In fact, these are common things, that is, the impact on the entire team. This applies directly to the entire team, all the guys to the very last junior engineer.
But the truth is that the issue of burnout, motivation, everything else - it is quite personal and intimate. They need to deal with a little closer to people than I just said. Therefore, I have built a fairly sophisticated monitoring system.
She lined up long enough. In this system, by and large, the whole team is involved.
Do not confuse monitoring with complaints, with squealing: this is just a way of obtaining information about what is currently happening in the team. From team leaders, from service chiefs, from one-on-one meetings.
Moreover, at these meetings I don’t lock myself with someone in a meter-by-meter-sized meeting room, I don’t put a person in front of me and I don’t stick a lamp in his face: “Stab.” No, that’s not what I do. More often than not, these are everyday conversations when you catch a colleague near a coffee machine and ask how you are doing. Either communicate in the smoking room, or give him a link to an event that you advise to go to, and along the way, clarify something else.
This, including HR: periodically it brings very interesting news. Despite the fact that we now have a whole HR, he copes.
Everything in a row: about the weather, about a hobby, about a guitar accidentally noticed by a colleague. I know who is rooting for someone, who has some cars, who is in the country, who is not in the country, who is mushrooms, who has something that hurts. I listen to the classic whining about the fact that testers are rascals, that the infrastructure is not working.
It is important for me to understand what a person is interested in. Veterans of labor have already come to terms with the fact that they chose the wrong path, and young people are still rushing between React and Angular, between PHP, Python, Go and another 500 other languages. Most often they are interested in something. In some cases, I can satisfy their interest.
It turns out that people do not tell anyone about their interests not because they are reluctant, but because no one asks them about it. When you come and ask what he would like, he says that he would like to engage in architecture, but he doesn’t succeed, because we scoundrels have already come up with architecture, and we have it in iron.
You give him a book: let him go and read. He reads it, begins to engage in a review of the architecture that is. He begins to propose some solutions, and so we remove his problem and pain that he can not do anything new.
The more you know about a person, the more chances are that you will offer him a fairly simple and comfortable solution that will satisfy you all. And he will not disappear, cheer up, and you will not lose him. Such a portrait of a person is needed to understand how to work with him as an individual, a person with his own problems.
Have you seen a herd of horses running? One separates, and everyone looks back: "Where did she rush?" But they continue to run forward. Then the most unstable breaks down behind her. There are already two of them. And so on.
These processes are cumulative. You can sit and wait for a very long time, and then it will all explode. Therefore, you need to know how everything works, and to respond to signals as quickly as possible.
But at the same time, do not forget that sooner or later all this is covered with a copper basin. There is already no way to influence a person: he just burned out. You come, he doesn’t react to anything, says: “Leave me alone! I do not want. I won’t. I don’t like anything. ”
Most often, these people are later found somewhere in Bali. They sit there six months upside down, do nothing, program some startups and believe that everything is fine with them.
It may happen that a person can no longer. It is important to understand the reasons, motivation and demotivation so that this does not happen again.
Typical conversations with HR: “Why are you leaving?” Most often they answer the same thing: “Tired.” This is most likely true. Most of us change jobs because we're tired. Slightly less often due to the fact that they pay little, and more often because they are tired, and there is also more money. Few people leave for some deeper reasons. And in some cases for a good salary we are ready to endure all sorts of bullying.
You have to be prepared for this. And most importantly, you need to be able to prepare people for this, so that the same horse does not work out. It is obvious that those who work in our industry closely understand that the average duration of an employee in a team is 2–2.5 years. Some studies show that less, 1–1.5 years, and that's it, people change jobs.
We are all different, we all burn at different speeds. Therefore, the group therapy that I wrote about is good, but not very good. It still does not affect people in a way that is guaranteed to cover all problems.
Inside each of us has our own power. Usually this power is not associated with any material benefits: more often it is an opportunity to participate in something. And this can be controlled - but in the end, you still have to work one on one, extracting benefits primarily for yourself. A saved employee is the key to your peace of mind.
We live in a world of instruction. For example, there is an instruction on how to distinguish a drowning person from a non-drowning person. If suddenly you don’t know her, I’m telling you. People drown with screams, waving their hands, only in cartoons and movies. In life, people drown silently: just picked up and drowned. This is a grim metaphor, but the meaning is clear: most often people burn out silently. The only way to understand that something is happening is either to constantly monitor it, or to be constantly prepared for the fact that you will have to look for new colleagues.
Interestingly, I remember everyone who quit and for what reason. I remember not because I have a good memory, but because they quit very rarely.
In this article I will tell you what, from my point of view, keeps a person in a team. I’ll share how to encourage people to have a different attitude to work and ultimately overcome the problems of demotivation. And also - I will discuss how we heat up various thoughts and interests inside ourselves, what burns out most, drowns people, and why drowning people can not always get out on their own.
I gave a talk on this topic at Badoo TechLeads Meetup No. 4 ( video) My story is most likely not suitable for those whose team has more than 100 people: I will talk about the level of team lead, technical leader, technical director of a small company. I myself started with a small company. When he joined the mos.ru team, we had three engineers. During the year we grew to 40, in two years - to 80. Now, at different times of the day and depending on the weather, we are up to hundreds of people.
I’ll tell you about them.
Problems
What are the problems? Burnout and demotivation.
Who has them? Yes, almost everyone.
Can anyone give a definition of at least one of them?
Most likely no. Because everyone is sick in his own way, and talking about everyone will be too abstract.
Therefore, I will concentrate on simple, frequently asked questions:
- I stopped liking this project.
- I want new, interesting tasks.
- Tired of it all. I want something different, fresh.
At the interview, you ask the candidates: “What do you want?” - “Interesting tasks!” - “What are interesting tasks in your understanding?” At this point, a pause most often arises because few people can explain what an interesting task is. Nevertheless, everyone believes that they should be at work.
The reasons
All these problems are, of course, a consequence. The investigation has reasons.
Some of the reasons are probably familiar to many of you. First come to mind:
- process dictate: busting with processes that bothers everyone. When they tell you to do just that, and not differently.
- Deafness and blindness of colleagues and superiors.
- Routine.
- Boredom, uninteresting tasks.
If we now begin to list everything, then at least a hundred will be typed. Moreover, each will have its own, unique reasons, which are often embarrassed to talk about.
They begin to fight with them only when the problem is already there. Most people who suffer from these problems already get sick seriously enough. But when you walk as a team leader and look at the team, the team looks calm enough outwardly: everything is fine, everything works.
Leaders at this moment have a false sense of stability : you look at the situation outside and think that everything is fine. And if you start poking around this business with a knife or file, it turns out that this is not at all the case.
In addition, there is a concomitant problem - a false sense of control. You begin to think that the whole process that takes place in your team is controlled by you: you are great, you know what happens to people and how, what bad and good things are.
In the end, it turns out that you are all so good, but at the same time everything is on fire, your people are on fire. They get bored, for some reason they leave. The reason they usually call is more money. But if we talk more closely with people, it turns out that this is not the problem at all.
Tricks
How to prevent such situations? I will talk about techniques that I have been using for several years and which, from my point of view, make it possible to make people's lives more comfortable.
Before that, I’ll talk a little about myself. The team I'm working in now makes the portal mos.ru. We are absolutely the same as most IT companies: we have legacy, technology zoo, lack of documentation. Requirements vary with space speeds.
By and large, we are no different except for one fact: we grew from the very beginning using these tricks.
Reception # 0: Demonstration of Movement
We show how our team is moving forward: it is developing, reaching heights, it is lying (who does not lie, he does nothing). Demonstrations are ongoing.
Previously, only team members came to them. For six months now, we have been inviting everyone who is important to see the system moving for demonstrations. We are holding internal meetings where we discuss what new cool things have been done. These mitaps are not only thematic - for example, for the backend. No, everyone comes to the mitap for the backend, including designers. They are interested in listening, talking, learning what is happening.
An important point that many people forget about is the influence of the external environment: what is happening around us, around the team, and the project. People are interested to see how the movement within the team corresponds to the movement that is happening around.
How does this technique help in everyday life? We, like many, sometimes have to recycle: linger in the evening or go out on Saturday. I never force refining, but I always explain what is happening and why. For example, that there is a new large project that is socially important for Muscovites, where city residents will be able to see what improvements will happen in its area in the near future. That 500 people went through these yards, counted and recorded the necessary information. The developer understands that he is involved in a large and complex process, knows why he works this way. And in most cases I’m ready to help.
For some reason, they usually do not like to talk about such nuances, although there is no secret in them.
Reception # 1: do not hide
The team must understand what is happening and why. Where we are at the current moment in time, how it corresponds to plans and promises, what our future is.
Lack of plans is a thing that greatly affects a person’s internal state. When he realizes that the WP-blog that he is programming now, another five years will be the WP-blog that he will program, the developer is very sad. Therefore, we are trying to tell what changes in the near future will occur in the external environment, what will change, what large projects will be.
We were able to agree with the management that from time to time, every six months we are given information about this. And we learn that, for example, we are not doing anything new just because something new and cool is being prepared.
By the way, in order to do something new and cool in the city — for example, to translate some process into electronic form — very often it is necessary to prepare documentation and legislative base.
Take, for example, recording a child in a pioneer camp. It would seem that it could be simpler: I came, I filled out the form - and please. And then the details begin: how to equalize the rights of those people who submitted the application physically and those who submitted it via electronic form?
Everything connected with the state and society is quite serious. Therefore, we have to explain why everything is so, and not different. Sometimes we don’t release it, because a certain resolution does not reach the phase where we can release the product. This is an infrequent effect, but nevertheless it happens. If the developers know about this, they understand that we did not “dump and quit,” - we just have this mode of operation. They begin to take it calmly.
Reception # 2: give clearly regulated freedom
Freedom is good. But complete freedom is bad.
Since childhood, we are used to having someone caring for us. First, parents followed, then teachers in the kindergarten, then teachers at the institute, then the head. If it seems that the boss is not following you, the question most often arises: maybe he doesn’t care, maybe he is not interested in all this, did he even want to spit on this? Complete freedom is ultimately a problem. Therefore, freedom must be given, but not complete, but limited. Tell people that there is a canvas, and within this canvas they can move.
For example, we agreed that we program in PHP - it happened historically. Inside this - libraries, approaches, OOP, not OOP, to write this way or that, some patterns - this, please, you yourself. But in PHP.
When people come and say: “I want Go,” I say, “Let's think about how much your“ want ”can be realized in“ I can, ”into something useful.” As a result, the developer knows that he has the opportunity to put forward proposals, but in order for these proposals to get into production, you will need to work. They know these rules of the game, they know that there is such an opportunity. Some people use it: therefore, we have not only PHP, but also other programming languages.
Reception # 3: let into processes
We let people into the processes, but with some restrictions. The limitation is that we have nine teams, nine processes, and there is also a root process - a release that governs output. He is one for all.
Around this process, the guys do what they like best.
Our product and business processes are quite different. For example, the command that saws the search is internal. The search requirements are most often generated by ourselves. There are teams that program mobile applications, there is a completely different kitchen. There is a web that exists as a separate product, there is a web that exists as a newsroom with an admin panel. Everything is different there, but the release processes are the same for everyone.
Limited freedom looks like this: do what you want, but don’t touch this piece. Thanks to this, I have already forgotten about what critical errors in production are. Because there is a clear rule that says how to do it. If you want to play, play: in fact, we have not a single documented process right now, except for the release. At the same time, people feel comfortable.
Reception # 4: rotate the drum
A tricky trick: we call it “spin the drum”, but you can rotate the carousel or concrete mixer - call it whatever you like. The point is that we completely consciously do not bind people to tasks.
We don’t have one so that someone from the frontend, backend or from DevOps could not do any other task. Code ownership - we simply do not have this.
Firstly, it adds interest to people, and secondly, it increases the notorious bus factor. Thirdly, I can quite easily transfer people between teams, assemble teams from four other teams for large projects. They begin to work in just two days: they finish their tasks in two days, and then they got together and drove off.
The largest and most important project that I mentioned above was made by three teams. Moreover, one has never interacted with the other two before: the guys just came and accepted the rules of the game. On average, we do such projects with a hodgepodge of guys every six months. Due to the fact that they are generally not tied to any specific duties, they feel great.
There is one more chip that we try, and we succeed - we do not just let people go, we try to detain them in a team, even in a different area.
Suppose I had an automation engineer, a tester. He wrote autotests in Python. Tired of testing, he said he wanted to be a Python developer. It would seem that one could tell him: “Go and program in Python.” But at that moment it turned out that we needed a Python developer in the mobile. We sent him there: firstly, we did not lose knowledge in autotests, secondly, the person did not disappear, and we saved on search.
I have several such stories. When we introduced the release management process, we converted two testers into release managers, and they feel great. We are turning coders into front-end developers. I recently found out that one of the PHP developers spent the night programming in Python. It would seem that you can also let go, but we decided to play the game: I came to the search team, who have a Python backend, and asked me to give me a difficult non-urgent task. What difference does it make that he programs in Python at night? Let him program something we need. If it succeeds, then we will define it there as a junior Python developer from a senior PHP developer. There is such a desire in people, what can you do?
At these receptions, I did not lose 5-6 people from the team, I just redirected them.
The most important point
I talked about the techniques that I use. In fact, these are common things, that is, the impact on the entire team. This applies directly to the entire team, all the guys to the very last junior engineer.
But the truth is that the issue of burnout, motivation, everything else - it is quite personal and intimate. They need to deal with a little closer to people than I just said. Therefore, I have built a fairly sophisticated monitoring system.
Monitoring
She lined up long enough. In this system, by and large, the whole team is involved.
Do not confuse monitoring with complaints, with squealing: this is just a way of obtaining information about what is currently happening in the team. From team leaders, from service chiefs, from one-on-one meetings.
Moreover, at these meetings I don’t lock myself with someone in a meter-by-meter-sized meeting room, I don’t put a person in front of me and I don’t stick a lamp in his face: “Stab.” No, that’s not what I do. More often than not, these are everyday conversations when you catch a colleague near a coffee machine and ask how you are doing. Either communicate in the smoking room, or give him a link to an event that you advise to go to, and along the way, clarify something else.
This, including HR: periodically it brings very interesting news. Despite the fact that we now have a whole HR, he copes.
What am I talking about?
Everything in a row: about the weather, about a hobby, about a guitar accidentally noticed by a colleague. I know who is rooting for someone, who has some cars, who is in the country, who is not in the country, who is mushrooms, who has something that hurts. I listen to the classic whining about the fact that testers are rascals, that the infrastructure is not working.
It is important for me to understand what a person is interested in. Veterans of labor have already come to terms with the fact that they chose the wrong path, and young people are still rushing between React and Angular, between PHP, Python, Go and another 500 other languages. Most often they are interested in something. In some cases, I can satisfy their interest.
It turns out that people do not tell anyone about their interests not because they are reluctant, but because no one asks them about it. When you come and ask what he would like, he says that he would like to engage in architecture, but he doesn’t succeed, because we scoundrels have already come up with architecture, and we have it in iron.
You give him a book: let him go and read. He reads it, begins to engage in a review of the architecture that is. He begins to propose some solutions, and so we remove his problem and pain that he can not do anything new.
Why all this?
The more you know about a person, the more chances are that you will offer him a fairly simple and comfortable solution that will satisfy you all. And he will not disappear, cheer up, and you will not lose him. Such a portrait of a person is needed to understand how to work with him as an individual, a person with his own problems.
Have you seen a herd of horses running? One separates, and everyone looks back: "Where did she rush?" But they continue to run forward. Then the most unstable breaks down behind her. There are already two of them. And so on.
These processes are cumulative. You can sit and wait for a very long time, and then it will all explode. Therefore, you need to know how everything works, and to respond to signals as quickly as possible.
Free ticket
But at the same time, do not forget that sooner or later all this is covered with a copper basin. There is already no way to influence a person: he just burned out. You come, he doesn’t react to anything, says: “Leave me alone! I do not want. I won’t. I don’t like anything. ”
Most often, these people are later found somewhere in Bali. They sit there six months upside down, do nothing, program some startups and believe that everything is fine with them.
It may happen that a person can no longer. It is important to understand the reasons, motivation and demotivation so that this does not happen again.
Typical conversations with HR: “Why are you leaving?” Most often they answer the same thing: “Tired.” This is most likely true. Most of us change jobs because we're tired. Slightly less often due to the fact that they pay little, and more often because they are tired, and there is also more money. Few people leave for some deeper reasons. And in some cases for a good salary we are ready to endure all sorts of bullying.
You have to be prepared for this. And most importantly, you need to be able to prepare people for this, so that the same horse does not work out. It is obvious that those who work in our industry closely understand that the average duration of an employee in a team is 2–2.5 years. Some studies show that less, 1–1.5 years, and that's it, people change jobs.
Instead of conclusions
We are all different, we all burn at different speeds. Therefore, the group therapy that I wrote about is good, but not very good. It still does not affect people in a way that is guaranteed to cover all problems.
Inside each of us has our own power. Usually this power is not associated with any material benefits: more often it is an opportunity to participate in something. And this can be controlled - but in the end, you still have to work one on one, extracting benefits primarily for yourself. A saved employee is the key to your peace of mind.
We live in a world of instruction. For example, there is an instruction on how to distinguish a drowning person from a non-drowning person. If suddenly you don’t know her, I’m telling you. People drown with screams, waving their hands, only in cartoons and movies. In life, people drown silently: just picked up and drowned. This is a grim metaphor, but the meaning is clear: most often people burn out silently. The only way to understand that something is happening is either to constantly monitor it, or to be constantly prepared for the fact that you will have to look for new colleagues.