How to save a developer from burnout? And is it worth saving?

Question

Project management

Good morning everyone!
I am currently working as a project manager in a company with a fully distributed staff. A couple of months ago, we hired a new middle-level mobile developer and added me to the project.

When developing mobile applications, I use the following flow of work:

• The project manager describes the task and provides all the resources for it - designs, api, description of validations, edge cases
  
• Developers decompose the received task and arrange the hours into subtasks. Subtasks are laid out by the developers themselves in the scheduler by day for the week ahead. On average, tasks are set for 4-5 hours a day
  
• When working during the day, developers are given the conditions for focused work. Each developer leads only one project. During the day, no more than one call with the manager for 15-30 minutes
  
• At the end of the working week, the manager looks at how much has been done in relation to the plan / fact
  

When working with a new developer, I heard phrases about "burnout" several times, about the fact that he gets tired of coding and that he often has to stay after work.
I did not attach much importance to these words, since I believed that personal problems should remain outside of work and in general it is strange to hear such things from a new employee.

But yesterday there was an unpleasant situation that I could no longer ignore. The developer deleted his code in two days, as he did not like it and led him to a dead end. When I asked why he did this, he began to refer to burnout, headaches and the fact that he did not get enough sleep and suffer from insomnia. The deletion of the code led to the failure of the deadline on several tasks.

He is a good developer for his level and at the beginning of his work he showed acceptable results. Despite fakap with deadlines and such disruptions, I would like to help him get out of this state so that he can continue to work productively with us. Moreover, the problem of professional burnout is widespread in IT, and in the future I will still encounter such cases.

I would like to hear your opinion/story about how you worked with such programmers? Were you able to bring the developers back into service, or did you have to fire such employees. And what should I do in such a situation.

Answer 1

A very interesting case. And not simple.
But, firstly, something is wrong with your project organization if anyone can easily demolish their code two days before the deadline. And where are the copies, and where is the deletion control?
There is something to work on even without regard to the situation we are considering.
Secondly, the problem of "burnout" is a problem of psychology. I encountered such problems when working remotely once. And to be honest, even in office work it is not easy to deal with them - but here, as it were, a person is in sight, you can always talk on the couch, over a cup of coffee. And at a distance, the contact is much weaker, so I must say that the chances of success will be an order of magnitude lower.
Generally speaking, you should understand that once you - as an employer and as an executor - have made the decision to work remotely, all the executor's personal problems remain out of your field of attention. You must inform him of this immediately. This is his payment, which he bears in exchange for the convenience of his work at home. He must understand that this is not him, it was you who agreed that he would not waste time-money on the road, on being in the office, on tying a tie and shoelaces, on strict control of hours, etc. "Burned out" - it's not COVID-19 caught, not a broken leg, falling off the couch and not a beloved cat got sick, urgently need to see a veterinarian. "Burned out? - well, go get yourself together and work on. If you can't - go to Bali, relax, when you return - submit your resume for a vacancy that is free by that time, then we will decide." Moreover, a project participant is from new ones, and it is always easier to say goodbye to new ones than to those with whom you have done a dozen projects. And after the tenth joint project, I would have "burned out" - I would still have suffered, giving the person a break. And if it starts in the second or third month of the first project?
One more. "Burned out" is one case. "The employee demolished his code, breaking the deadline" - this is completely different. Generally speaking, he caused you (your company) damage, material. Have you talked to him about this? You explained to him that a deadline failure is not a blow to an abstract company or an abstract customer - it is, first of all, a blow to colleagues working with him on the project. Perhaps - deprivation of their bonuses. Did you ask him how he is going to make up for this damage? What did he answer you?
While writing, I realized that in fact there are still two different solutions.
The first, if it would just "burn out". There is a rule of management "management is such an important characteristic of an employee as his qualifications." And it doesn't matter that "not bad for its level." Good, but poorly controlled. You will find another, but from now on, when applying for a job, look not only at qualifications, but also at its socio-psychological characteristics. Therefore, the algorithm is "a conversation - finding out the reasons - and if it did not help, then farewell."
The second - "removed the code". After that, the decision is clear. Saying goodbye without financial compensation, without regret and without "please forgive me."
Somehow like this.
Good luck with solving the problem.

Answer 2

1) About deleting code - the decision depends on the service used, but as far as I know, everyone (GitHub, ...) has the ability to prevent this
2) But even if there was code - it is almost useless if the developer wrote it alone, not according to company standards, without code reviews.
3) As they said, burnout in a couple of months is very strange.