November 4, 2010 at 11:20Overtime? Now you have two problems!
- Transfer
One old joke says: if you have a problem and you are going to solve it using regular expressions, then you have two problems. It seems to me that overtime is something from the same series. I would put it this way: if the team has a problem, and it is planned to work overtime to solve it, then the team has two problems. What is the second problem?
Regular overtime work has many harmful consequences - both for the team and for the company. Let's look at them.
Obviously, people working overtime a lot get tired, and over time, fatigue becomes exhaustion - both physical and moral. Of course, health is not good enough.
The more time people spend on work, the less it remains not only on vacation, but also on personal life in all its manifestations. Consequently, they will be less focused at work and more distracted. In the limit, they will inevitably begin to solve personal issues during working hours, absenteeism, sick leave and times of "remote work" will become more frequent - and it will be extremely difficult to deal with this. The combination of these factors is called undertime.
Another obvious consequence of persistent overtime is demotivation. Who likes these survival races? Who is pleased to hear again and again from the leadership “your concern is justified, the project will inevitably fail, but we must continue to try to write something acceptable by the deadline”? Personally, I would not want to spend much time in such a company.
Over time, employees who are exhausted and have lost all faith will begin to look for another job - and find it. As a result, implicit knowledge about what has already been done on the project will be irreversibly lost . Thus, further work will become even more complicated - people who understand what is spinning here and how are not working here.
When deadlines are running out, but no one has the strength, they sacrifice quality first of all. This is normal - we all know about technical debt (a metaphor for the results of careless design and development of the system), and this time we can owe a bit - we will definitely pay later, right? Not. Companies that consider overtime as a normal solution to problems never repay this debt. Negligence today means a few more urgent bugs tomorrow, which will have to be dealt with in the same mode. In addition, the quality of the code itself is deteriorating, it is becoming more difficult to refine, and the changes take even longer.
It is becoming more difficult to predict the future development of the project. In the middle of the next stage or project, an error from the previous one can suddenly come out and derail it. In addition, due to the complexity of accounting for the time actually spent working in a busy mode, it becomes more difficult to evaluate the effectiveness of a team in normal mode. The schedule for the following projects is becoming increasingly unreliable. However, you can not worry about this, you can always work overtime to catch up with the schedule ... Damn. Somewhere I already heard it.
Ok, move on to the next level. Who in your company volunteers to work overtime? Usually these are not developers, but managers, either asking or requiring labor exploits. From the point of view of the team, they make sacrifices to help out the management from the trap they fell into because of the inability to plan work or communicate with clients. This is only partially true: the forced unpredictability of the team that fell into this vicious circle leaves the manager only with a choice of a random term that is not too offensive for the client and believable for the team. But this is not a developers problem - although developers can give ideas for technical implementation or change of approach to help solve it, this is a business problem. Since things went wrong - for one reason or another - plans need to be changed. In such a situation, a triangle of possibilities is usually considered,
Why is the client not reporting this problem? Yes, because this is a difficult conversation, and most people (including managers) are afraid of such conversations and avoid them at all costs. It’s easier to say “running for work!” To the team than “we won’t be able” to the client. In fact, it’s necessary to talk about such things - a good relationship with the client should be based on respect, trust and openness, including in those moments when things are going badly.
It should be noted that if it came to such a conversation, it does not matter who is to blame. This should not be about fault, but about the current objective situation and what to do with it. Then there will be time to discuss where and what can be improved in the process, so that the situation does not happen again, but this is a completely different story.
What if the client insists on the team working overtime? In fact, for this, there are managers - they must explain to the client the possible side effects of such a decision. In addition, the client must undertake to compensate for the additional costs incurred, recovery time and time to work out the technical debt accumulated during this time. Good managers will always convince the client that overtime is a ladder leading down.
Now the original joke can be rephrased even more precisely. When managers encounter a problem in planning, they think, “Oh, instead of a business conversation with a client, I’ll just make the team work overtime.” Now they have a lot of unpredictable problems that will come around in the future at the most unexpected moment, a worn out team on the verge of rebellion and a dissatisfied client who does not trust the team.
Do you still want to work overtime?
It should be noted that this is not about episodic overtime, when a bug is detected on the eve of the project’s launch and it really needs to be fixed right now, but about regular overtime, when they “cure” the delay from the schedule by a month or two or simply use it as a tool to reduce development time when planning. It takes 2 to 6 weeks to exhaust a team with additional work, while the first week is characterized by a surge in productivity. In addition, overtime at the initiative of the team and on orders from above - these are two big differences, which should also be taken into account.
A lot has been said about the dangers of overtime, but this article caught me with 100% accuracy in describing the situation of one team, which I have the opportunity to observe. Regular (paid, but forced) work on the weekend, “no one will go home until the error is fixed,” the eternal “who is to blame?” Instead of “what should I do?” ... Three people quit from the team “1 manager + 5 performers” within six months performers, the remaining symptoms described are also evident. And yes, in such a team I would not want to work :-)
Regular overtime work has many harmful consequences - both for the team and for the company. Let's look at them.
Exhaustion
Obviously, people working overtime a lot get tired, and over time, fatigue becomes exhaustion - both physical and moral. Of course, health is not good enough.
Flaws
The more time people spend on work, the less it remains not only on vacation, but also on personal life in all its manifestations. Consequently, they will be less focused at work and more distracted. In the limit, they will inevitably begin to solve personal issues during working hours, absenteeism, sick leave and times of "remote work" will become more frequent - and it will be extremely difficult to deal with this. The combination of these factors is called undertime.
Demotivation
Another obvious consequence of persistent overtime is demotivation. Who likes these survival races? Who is pleased to hear again and again from the leadership “your concern is justified, the project will inevitably fail, but we must continue to try to write something acceptable by the deadline”? Personally, I would not want to spend much time in such a company.
Staff turnover and loss of implicit knowledge
Over time, employees who are exhausted and have lost all faith will begin to look for another job - and find it. As a result, implicit knowledge about what has already been done on the project will be irreversibly lost . Thus, further work will become even more complicated - people who understand what is spinning here and how are not working here.
Loss of quality and technical debt
When deadlines are running out, but no one has the strength, they sacrifice quality first of all. This is normal - we all know about technical debt (a metaphor for the results of careless design and development of the system), and this time we can owe a bit - we will definitely pay later, right? Not. Companies that consider overtime as a normal solution to problems never repay this debt. Negligence today means a few more urgent bugs tomorrow, which will have to be dealt with in the same mode. In addition, the quality of the code itself is deteriorating, it is becoming more difficult to refine, and the changes take even longer.
Unpredictability
It is becoming more difficult to predict the future development of the project. In the middle of the next stage or project, an error from the previous one can suddenly come out and derail it. In addition, due to the complexity of accounting for the time actually spent working in a busy mode, it becomes more difficult to evaluate the effectiveness of a team in normal mode. The schedule for the following projects is becoming increasingly unreliable. However, you can not worry about this, you can always work overtime to catch up with the schedule ... Damn. Somewhere I already heard it.
Managers and Clients
Ok, move on to the next level. Who in your company volunteers to work overtime? Usually these are not developers, but managers, either asking or requiring labor exploits. From the point of view of the team, they make sacrifices to help out the management from the trap they fell into because of the inability to plan work or communicate with clients. This is only partially true: the forced unpredictability of the team that fell into this vicious circle leaves the manager only with a choice of a random term that is not too offensive for the client and believable for the team. But this is not a developers problem - although developers can give ideas for technical implementation or change of approach to help solve it, this is a business problem. Since things went wrong - for one reason or another - plans need to be changed. In such a situation, a triangle of possibilities is usually considered,
Why is the client not reporting this problem? Yes, because this is a difficult conversation, and most people (including managers) are afraid of such conversations and avoid them at all costs. It’s easier to say “running for work!” To the team than “we won’t be able” to the client. In fact, it’s necessary to talk about such things - a good relationship with the client should be based on respect, trust and openness, including in those moments when things are going badly.
It should be noted that if it came to such a conversation, it does not matter who is to blame. This should not be about fault, but about the current objective situation and what to do with it. Then there will be time to discuss where and what can be improved in the process, so that the situation does not happen again, but this is a completely different story.
What if the client insists on the team working overtime? In fact, for this, there are managers - they must explain to the client the possible side effects of such a decision. In addition, the client must undertake to compensate for the additional costs incurred, recovery time and time to work out the technical debt accumulated during this time. Good managers will always convince the client that overtime is a ladder leading down.
Conclusion
Now the original joke can be rephrased even more precisely. When managers encounter a problem in planning, they think, “Oh, instead of a business conversation with a client, I’ll just make the team work overtime.” Now they have a lot of unpredictable problems that will come around in the future at the most unexpected moment, a worn out team on the verge of rebellion and a dissatisfied client who does not trust the team.
Do you still want to work overtime?
Translator Commentary
It should be noted that this is not about episodic overtime, when a bug is detected on the eve of the project’s launch and it really needs to be fixed right now, but about regular overtime, when they “cure” the delay from the schedule by a month or two or simply use it as a tool to reduce development time when planning. It takes 2 to 6 weeks to exhaust a team with additional work, while the first week is characterized by a surge in productivity. In addition, overtime at the initiative of the team and on orders from above - these are two big differences, which should also be taken into account.
A lot has been said about the dangers of overtime, but this article caught me with 100% accuracy in describing the situation of one team, which I have the opportunity to observe. Regular (paid, but forced) work on the weekend, “no one will go home until the error is fixed,” the eternal “who is to blame?” Instead of “what should I do?” ... Three people quit from the team “1 manager + 5 performers” within six months performers, the remaining symptoms described are also evident. And yes, in such a team I would not want to work :-)