Adventures with Bad Coworkers

We’ve got all sorts of projects going on at the office. Nothing unusual for this time of year. With so much going on, our QA team decided to bring in a few contractors to help handle the load, which is also entirely normal. This was the case for the Very Important project we have going on at the moment, to which more or less 100% of my time is dedicated.

We brought in this guy and started including him in project meetings so he knew what was going on, but he was also being brought up to speed on our assorted processes by the QA team. Now, our environment is quite complex. I know it can take some time to get up to speed on what we’re doing, so we planned for plenty of meetings to explain to the new guy what we’re looking at, what’s going to happen, what the subtleties are, etc. And we started seeing red flags early in to the second meeting or so.

“The use cases says I need to test these people in Group A.” “Err, no, it doesn’t. Look again, we’re testing these other people in Group B.” “Ok but how do I test Group A?” “No, er, you don’t. They’re not at all a part of this. Here’s your info for Group B, just stick to those.” “Oh so we’re leaving Group A out? Do we need to change the use case?”

That had me concerned but the real problem arose when he opened the next meeting asking about Group A testing again. In the end, that issue alone took several meetings to talk out. We had a business analyst, two members of the architecture team, a project manager, and occasionally one of the other QA resources trying to explain as patiently as possible what was going on, while he at first didn’t get it and later began to outright argue. This then set the tone for the five-ish weeks he was with us.

Eventually we’d thought we had him on the right track. Or rather, everyone else did. I knew better, and how did I know better? Because I became the only person he was bothering to contact with this stuff. This became an issue in turn: he’d email me with something that showed the problem was still there. I’d reply with an answer and CC all the people that needed to hear this. He’d reply again only to me. I’d reply all. And so on. I asked him specifically and on multiple occasions to include all the others. This did not happen. I went to the PM and asked that he help me get the point across, so together we gathered the list of people to include, went to the guy, and said PLEASE include all these people because this is the team that needs to know, and can resolve issues you’re having. So the guy started emailing the PM, only.

This all came to a head in a status meeting, which I will attempt to paraphrase here.

“So I’m trying to do what you want but the QA system we use won’t let you assign multiple people.”

We corrected him. We knew that it could.

“Well no, but we can’t get everyone listed in the system to send to all of you.”

Again, we knew that this was not the case.

“Well <more reliable long term QA person> said we can’t do that.”

This was an outright lie.

“Ok so what I’d normally do here is assign the issue to myself, and then forward the emails from the system to the group.”

YES! Do that, we said! That’s perfect, do exactly that.

“No you don’t understand. What I’d normally do is <exactly what he said before>.”

Ok, yes, again, good. Please do that. We want you to do that.

“No, I mean, I’d <same thing as before>.”

By this point voices are being raised, and he backed down and seemed to grasp that we hadn’t needed to spend ten minutes on that. So we went on to the next bit.

“So do you want me to open a defect on everything I see? What if it’s not supposed to be a defect?”

We said yes, do that. If it wasn’t meant to be we could let him know and close it.

“No but, like, EVERY thing?”

Yes. Everything.

“But <more reliable long term QA person> said let’s not do that.”

Well one, she DOES do that, and two, even if she didn’t we want YOU to because we’re not sure we can trust you. (in different, kinder words)

“No, but they said that…”

At this point our architect assigned to it went into his well know “You’re not fucking listening to me” tone and things broke down. This was a half hour meeting and we ran out of time for updates on all the other bits.

Every step of the way with the guy was like slogging through mud. The entire project had to slow down to find the time to explain this crap to him. I checked in with aforementioned more experienced QA lady to ask how her training was going. Having worked with her for years I knew the look she gave me in reply showed that we were, err.. “Sharing” some “opportunities” to “extensively coach” our new peer on some “excitingly rudimentary concepts”.

Finding out that the QA manager had dropped him early this week was sufficiently joyous as to be met with high fives all around. Experienced QA lady took over, re-assigned from her other project, and suddenly our whole project is sailing completely smoothly through testing. It’s so good to have people you can rely on.

When the guy first came in I knew it would take a while to get him acclimated, and I lamented at the time the problem with short-term contractors: you spend so long getting them up to speed, and with multiple people doing so, that it seemed like a waste in the long term. Turns out, this one was just a special someone. I think I’ve never worked with anyone who became such a complete problem to work with so quickly.