A new officemate is badmouthing an employee on-training for not doing the tasks she thinks she has given him - What to do?

Question

A relatively new officemate (about a month or so) has been badmouthing one of our employees for not doing the task she has given him.

She knows, as I've mentioned to her multiple times, that the guy is currently on training so he won't be able to do the task until he comes back.

Yet she continues to badmouth him for not doing it earlier.

By badmouth, I mean something like :

"I told ___ to do this, why hasn't he done it? We are going to lose this project because of him."

in an aggressive tone (for me, and for other employees as well, as she exclaimed this in public)

She sent a request to said employee to do task A, and the employee has indeed finished the task according to specifications. I read the request, and I confirmed that he did the job. The root of the issue, she said, is that he didn't do what she asked him to do exactly, basically, miscommunication. In an IT person's head, the job was done. I read it and interpreted it as such where he actually did the job correctly, when she actually meant something else.

She has no IT experience (makes me wonder how she became a project manager in the first place, but that's for another topic), so she can't communicate very well with IT staff.

What is the problem here, and what should I do?

Is it the miscommunication? Her lack of IT knowledge? Or the badmouthing? Should I talk to my supervisor about this, and if so, how should I approach this?

Answer 1

What is the problem here, and what should I do?

There's no way for anyone here to know the real problem.

The badmouther could be a poor communicator, could be very insecure, or could be a jerk. The mechanism for detailing the requirements may be lacking. Or you may be completely misunderstanding the situation.

Is it the miscommunication? Her lack of IT knowledge? Or the badmouthing? Should I talk to my supervisor about this, and if so, how should I approach this?

It is not your role to do anything about this, nor is this your problem. If the badmouther wants something different done, she will go to your supervisor.

Do your job, and let your supervisor do her job.

Answer 2

This likely classifies as an attempt at mobbing. She preemptively assigns the blame to the new guy in case the project is late, and she does so publicly. Mobbing doesn't require intent, so there's no point in discussing if she's doing it intentionally or out of habit. An employer that allows mobbing in the workplace is not an employer you want to work for.

So let your employer fix it. This is a line management issue and the proper channel is to tell your line manager privately what happened and why it bothers you. It's then the responsibility of your line manager to contact her line manager or HR. They will take appropriate action which may be as simple as documenting it in a file, which will only become relevant if such events happen repeatedly.

Answer 3

tl;dr version:
You should not ignore these issues, because these problems could one day affect you, too. But you don't deal with one person badmouthing another person, that's not your prerogative - you focus on how to improve the workplace so there is no reason to complain about your department.

As far as I see the situation, there are two distinct issues.

a) Tasks not being finished in time, because the person is actually not available.

b) Result passing formal verification (result does what specification says), but failing the validation (result does not meet expectation of the requester)

For a), you could talk with your superior about the task handling during absence. Not specifically related to this incident, but overall. You can bring up the issue that tasks are assigned to persons who are not available and use that incident as neutral example. There needs to be a process to handle this situation.

For b), the solution is more complex. Results not satisfying the expectations is one of the common problems all the time. Whole development methods were invented just to reduce the effects of this problem. A specification should also contain a use-case. If you understand the intent of a change, it's much easier to validate that your change meets the intention of the change, not just follows a technical specification.

So you could propose that a change request always also includes a use-case and is denied otherwise. Again, you can use the incident as example, when you talk to your superior, but the incident or one of the persons is not the problem and should not be portrayed that way.

Answer 4

I think it's a bad idea to get involved unless you have an actual solution, eg., volunteer to do the task in the interests of keeping the project rolling. Or at the very least a suggestion of how it could be accomplished and a clear way forwards.

That is the only way I can see getting involved leading to anything beneficial.