How far can co-workers be reasonably expected to carry people with mental problems? [closed]

Question

A colleague of mine was recently hospitalized due to attempts of self harm. His marriage is collapsing, he has inlaw issues, etc. I am not going into details, but all his problems outside work have lead to him being unavailable for work currently.

The co-worker with the problem also did not achieve much in past sprints due to marital problems. It's mean to say, but he has been mostly a burden, despite being the most senior engineer on the project. He spent a ton of time just chatting with people.

Normally, our group might just continue tolerating it. Problem is, this was a do or die sprint for our project manager. He is under the gun because the product owner is under the gun because the division head learned that we can no longer update our existing software which handles millions of dollars, so if it breaks, we are screwed. We have missed several sprint goals (mostly due to this co-worker) and the PO has been openly talking about replacements for the PM.

Because we now have 1/3 of the development capacity (arguably more as he is a senior) and the other dev on the project keeps getting drawn away by other work, the high stakes of this sprint mean that the PM is just driving the junior developer nuts.

I am not really sure what I want from this. Mostly just seeking advice on law, ethics, etc. I am the business analyst on the team, so not in a managerial position. I am located in the USA.

Answer 1

This doesn’t really have anything to do with the mental state of the senior developer - he could have been hit by a bus or won the lottery and it would be the same problem.

You just have not enough people to do the work needed, so that’s where your PM has to start doing his job and manage. Two essential things he needs to do: Don’t allow anyone to take the second developer away, and stop driving the junior developer nuts!

From the top down it seems to be management by pressure, which doesn’t work. Passing the pressure down doesn’t actually get work done, so that needs to stop. When the PO shouts at the PM about sprints not being finished successfully the PM must stop shouting at the junior but shout back at the PO and tell him to get him another senior developer. Because shouting at the junior doesn’t fix the problem, getting another developer does.

Answer 2

other dev on the project keeps getting drawn away by other work

the PO has been openly talking about replacements for the PM

Kind of obvious you have a bad PM. He let his sole dev (the one left) to be distracted by other work while not being able to fill in by some contract or temp his second dev position.

So it's his own work that he don't get anything done (I assume when 1 dev is not working and second is doing oher work the amount of WORK THAT NEED TO BE DONE is 0%).

Now the other thing, the PO is talking about changing PM. But not doing it. A PM to a product that have 2 devs and is critical (or at least very costly). A Product that have bus factor of 1 and they let the sole dev to be doing anything else.

It seems like the PM have no real power, no influence up and the PO don't realize (know?) what management means.

You are not carrying your, one, co-worker (that need all the time they can have with just leaving the job altogether). You are carrying your whole division. The chain of command pass down all responsibility down without giving any real power to change things that pose a problem.

Answer 3

Environments which are "no excuses, get it done" have the problem that the person getting told to get it done has so many constraints placed on them that they are more just a head on a platter in exchange for a title and a slight bump in pay.

A fixed set of features and a fixed deadline requires at least fixed (if not fixed + contingency) resources to complete.

You have partial resources, perhaps about 1/2 of what you should have even if junior is equivalent to senior (and he wouldn't be).

Your senior dev is going to be out for a few weeks. That is not possible to change. You just need additional resources or more time. It is that simple.

Answer 4

You used the word "sprint." That likely means your company is using agile planning methodology. That in turn means that your team, not any single person, is responsible for the work getting done.

If your team has a player "on the bench" (sports metaphor) it's a collective responsibility, and the responsibility of your management. With your co-worker more or less on the "temporarily disabled list" (another sports metaphor) your team has to play a different kind of game.

As a team member, it's best to avoid pointing your finger at any other team member. It's your management's responsibility to "bring somebody up from the minor leagues" (another sports metaphor) to fill in, if they can. And it's your product owner's responsibility to keep management expectations set correctly.

Teams don't usually fire players on the temporarily disabled list. They are patient and kind.

One more thing I have to say: often these "do or die" things aren't really "do or die." They often take a little longer than everybody thinks, and usually the outcome is tolerably OK. Don't say that to anybody: you'll annoy them pointlessly. But don't take it all on yourself either.

Good luck.

Answer 5

Realistically, they should terminate senior dev and replace them with someone who is stable if that is legal where you are. He has essentially been hit by a bus, just one which is not politically correct to discuss in this way.

Getting that project back on track is going to be stressful and they need someone who can handle high levels of stress without trouble, especially since Junior might burn out after a few weeks of this.

Unless there are compelling reasons to keep him, get someone fresh for upcoming crunch period. You can't change management's mentality of giving someone responsibility without power (your PM). It is usually absurdly difficult to get an increased budget. The clearest fix is to remove the non functional senior developer and replace them with a functional one. You might want to try through referral hiring so that you know they don't come with external baggage.

EDIT: A lot of this is a hiring problem. Companies which push pressure down need to hire people who don't break. A company I worked for in the past valued engineers over CS students at our target schools simply because the engineering program was more stressful. Banks like Ivy Leaguers in part because they are kids who did everything anyone asked for years and years without snapping.

From how you describe the environment, it wouldn't surprise me if the workplace contributed to his issues. Your PM feels free to pressure a junior dev and there aren't usually high expectations of junior devs. How did he treat senior? For your next senior, try to find someone used to high levels of pressure.