6

We recently had a bad software release for a particular customer. I think the problem is that Bob, the QA engineer, isn't doing testing. I think he is shirking at work. I have privately shared my observations about this with Charlene, our boss. Charlene thinks that Bob is merely young and inexperienced, and will improve over time. I think Bob has no intention of improving over time and does not intend to do his job in a minimally adequate fashion, so should therefore be fired.

At a meeting to discuss future work for this customer, Dave, Charlene's boss, asked me directly if I thought there were any staffing changes that were necessary to avoid future problems for this customer's work. I did not tell Dave that I think Bob should be fired; I merely noted the aspects of the situation where Charlene and I agree. This was a meeting where Charlene was present.

My questions are:

  • Should I have told Dave that I think Bob should be fired?
  • Should I tell Dave this now? Work has not yet started on this next project, maybe something could still be done?
  • Was it appropriate not share my to disagree with Charlene in front of Dave?
  • 2
    This is a bit long and I think not all of the detail is needed -- can you condense? Also your questions seem to be to be broad and the answers opinion-based. Is there something more defined and objective you could ask from what's here? – mcknz Apr 8 at 22:56
  • @mcknz I will think about how to do that and revise the question accordingly. – Joe Apr 9 at 19:19
  • The important parts to me are such: Alice (SWE) works with Bob (QA)on a project for a long time client The past few releases have been more buggy than previous iterations. You suspect Bob is not doing his job, while Bob is claiming innocence, due to not knowing what tests to run. You bring the issue up with Charlene she dismisses it. David who manages Charlene asks you directly if there are issues with staffing, you decline to disagree with Charlene. Question: Did you do the right thing by not disagreeing with Charlene? – my_mistakes Apr 10 at 18:06
  • @mcknz Is this better? – Joe Apr 12 at 19:25
  • 1
    Just how reliant are you on Bob? His role should include producing automated tests to cover regressions, at the very least - is there anything measurable to show that he's not doing that? A hunch isn't good enough - and he could equally well be blaming you saying "Joe keeps sending me buggy code"... – Julia Hayward Apr 15 at 7:54
14

I think you should have been honest with David.

You stated he asked you directly. That means he wanted your assessment, not Charlene's. After all he could have also asked Charlene directly.

However, you don't have to throw Charlene under the bus to do it. Stick to the facts and let David make a decision.

Well David, Bob did not perform well when testing on Project X. He failed to identify key testable functionality before we delivered Project X to the customer. In the interest of ensuring new Project Y doesn't have the same issues, I think we might want to pair him with someone more experienced or increase the lead time so I can spot check some of his work or ...(whatever you think should be done)

  • I agree with being honest, directly answering the question and just stating the facts. However it's very common for developers to shift blame to QA/Testers, Business Analysts, and other IT personnel. As such I would think that this is dangerous ground for the OP to cover with his boss' boss. – NotMe Apr 15 at 2:56
  • 3
    @NotMe I may be biased (developer here) but if there are testers and QA, it's their responsibility to make sure the release has no bugs (and the developer's to deliver features and fix bugs in a timely manner). Most developers try to deliver bug-free code, but testing every scenario is time consuming (that's why there are QA and testers jobs) so when there are people in place to do just that, it becomes their responsibility. It's not shifting blame to point out someone is not doing their job (if it is their job). – MlleMei Apr 15 at 9:37
5

I don't think it would have gone well if you tried to undermine Charlene by undermining Bob. In my opinion the only one who would look bad in that situation is you.

If you believe that Bob is not up to the task alone (and as a person early in his career he quite possibly isn't) then a more constructive way of addressing this might be discussing the team structure and processes rather than the individuals in the team.

For example it sounds like you have one junior person responsible for all testing and test sign-off, with no assistance or oversight. A way to improve quality might be to suggest that a second, more experienced, person review the tests and test evidence. This would give Bob an opportunity to improve by learning from someone more senior, and give you, Charlene, and David more confidence that the testing tasks are being completed appropriately. Two pairs of eyes will catch more things than one pair will as well, allowing your team to fix issues before they turn into problems that are visible to your customer.

4

By informing your direct supervisor "Charlene" of your concerns about the quality of "Bob"'s work, you have done your professional duty. By answering "David"'s questions about staffing honestly, you have done your duty there as well.

Keep this in mind: when supervisors are confronted with negative information about an employee, they don't smack their foreheads and say "you're right! He's a lazy idiot! I'll sack him now!" They need time to think it over. If they take some sort of remedial action, they need to keep it confidential.

"David" asked you about the staffing situation. That probably means "Charlene" has had more than one conversation with him about the situation already.

You're right to be worried about satisfying this customer, but dealing with the people problem is above your pay grade (for now). Let "David" and "Charlene" handle it.

2

When things go wrong, it is very common for various people to attempt to blame the other team members for project failures. Sometimes it's the Business Analyst for coming up with bad requirements, or the project manager for not allowing enough time in the schedule, or the testers for failing to handle all the right edge cases, or the client for not knowing what they actually want, or management for not clearing the obstacles, or even the developers for writing crap code, etc.

A manager in this situation may not know exactly where the blame truly lies. Especially if the manager is less technical. For all you know maybe "Bob" has been talking to "Charlene" about the problems he's run into trying to test what was delivered to him. Maybe "Charlene" even told him to approve things in order to meet the delivery dates because of pressure she's received from her boss. Maybe one of the other developers has said that you were the problem.

I'm not saying any of this happened, but the point is that there is likely more going on that you don't know about.

Because of this, you should never throw a specific person under the bus to your boss' boss. It would only look incredibly bad for you.

Now, to the direct questions you asked:

Should I have told Dave that I think Bob should be fired?

No.

Should I tell Dave this now? Work has not yet started on this next project, maybe something could still be done?

Absolutely not. Ultimately this project is under "Charlene"s direction and she is obviously well aware of your concerns. Any failure here is ultimately her failure. It is not your job to attempt to undermine her with her boss.

Unless, of course, you are trying to get her fired in some attempt at taking over her job. If that's the goal, tread carefully.

Was it appropriate not share my to disagree with Charlene in front of Dave?

Yes it was appropriate to NOT share your thoughts about "Bob" other than in generic terms. Getting specific would really just turn out badly for you.


Now, I'm going to add one more thing. I've held every IT job from entry level tech support through CTO and I've probably seen every way a project and team falls apart.

The true Rockstars(tm) on my various teams were not the people coming into my office telling me to fire someone. The Rockstars were the ones who sat down and helped the ones failing. If you want to be a MVP then go sit down with "Bob" and train him on how to do his job. Show him what to look for, how to set up test plans, how to record his results, how to write bug reports, etc. This isn't going to be a one hour thing. Rather we're talking about spending an hour a day with this guy for a couple months.

In short, rather than trying to push him out, help him stand on his own. You'll earn not just his respect but the respect of management and, hopefully, help to ensure the success of the project.

  • That would be good advice for most people who aren’t doing well, and several people on our team have attempted to do that already with Bob. I don’t think that is going to work with Bob because he’s ultimately preoccupied with doing the least amount of work possible, even when that is less than the amount required. – Joe Apr 15 at 11:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.