6

There's a QA in our team who's proving a bit of a headache.

'Q' is a likable young software tester who joined our team a few months ago. I think he graduated last year. He's energetic, has bags of enthusiasm, and cares deeply about both the products we build and the general philosophy of software testing.

The problem, however, is that the way he works is very unfocused and often quite disruptive.

For example, Q loves to write documentation. Writing posts in our company wiki is probably Q's favorite activity of all. Not a day will go by without Q leaping into a conversation and proposing he writes some. He'll push and push and push, until someone vaguely assents, and then will resist all calls to do any testing, as writing the docs has become his new 'project'.

This is Q's general modus operandi. He seems to get very excited by work outside his core responsibility, will trample others to get an excuse to do it, and then prioritize that work above what the team needs. Q does not communicate when he's doing this, and there have been several times now he's committed to do certain work in the standup, only for me to discover late in the day that he's actually decided to do something totally different.

Q is also being shared among multiple teams. He seems to have great trouble planning his work and carving out time for each project's work. More than once has he agreed that today he'll work for our team, only to get pulled into doing something for another. Again, this would be acceptable if Q communicated more. He never, ever does, unless it's something of personal interest.

Q also has problems with attention more generally. He spends a lot of time on workplace Slack. He is by far the most vocal user in the company. He involves himself in conversations that he doesn't really need to engage in, and starts new ones that are frankly irrelevant. Q says he is giving himself important business context, which I do appreciate, but he is really struggling to complete the work we tell him we need. Honestly, to me, most of these conversations seem a bit irrelevant to his work.

I've been working with Q for several weeks now and this seems a consistent pattern. I'll be approaching his line manager tomorrow. I want to communicate that I like Q and want him to succeed, but that he needs to focus better and understand the difference between his own interests and the team's needs.

My questions:

  1. What can we do to help him focus?
  2. How do we help him differentiate between urgent and nonurgent, important and unimportant?
  3. How do we get him to understand that work isn't necessarily about what's fun and interesting, but about getting a product shipped?
  4. Could I have the wrong end of the stick completely? How can I find out?
  5. How can I diplomatically get his line manager to take a more hands-on approach?
  • If you have stand-ups, do you have the opportunity to call out what is blocking issues? If this is a recurring pattern, your scrum master or team leader needs to go talk to Q's manager – HorusKol Dec 10 '17 at 20:02
  • @HorusKol - it's a bit ambiguous, but I seem to have become the team leader (it's not formalized - which of course complicates things). I do raise issues when work gets stuck, but don't know if it's appropriate for me to publicly challenge Q too far. Generally speaking he is defiant anyway - he just reasserts that what he's doing is more important than anything else. Between my ambiguous authority and his self-centered attitude, Q is really causing me a headache. – IrksomeEric Dec 10 '17 at 20:20
  • @IrksomeEric The fact that the team lead is not sure whatever he (or sort of is) is the team lead seem to be the problem (not a stab at you, but seem company culture/structure seem to be lacking). Q seems to be hard working, I assume he thinks he is doing good for the company. He however does not seem to be managed properly. – Jeroen Dec 11 '17 at 8:28
  • So if Q is not doing the tasks as assigned, are they getting done? Is his manager just reassigning those tasks to other people in his department? If the tasks are not getting done, and are important (blocking) tasks to your team, then you need to bring it up and hold the QA department accountable... (this is in reality a separate issue than issues with Q, even though he might ultimately be responsible for both). – Phil M Dec 11 '17 at 17:42
7

The short answer is: show him how to work effectively instead of hoping that he will figure it out.

Young folks entering the workforce are used to the extremely structured environment of school. Stepping out of that environment is a difficult transition. He sounds like he is enthusiastic and trying to do a good job, but no-one has shown him how to work effectively in an environment where there are no syllabi, homework assignments, office hours, assigned lab partners, etc.

New-to-the-workforce teammates need an experienced coworker to mentor them when they first join the company. What I have done in the past is get a project that isn't time critical, and then do that project pretty much elbow-to-elbow with the new team member. That gives me the opportunity to demonstrate what sort of communication is expected, show them our process, and since we're working side by side, keep them focused on what's important.

It requires some sacrifice on the mentor's end, because that project will take a lot of your time and, at times, challenge your patience. It's a "pay me now or pay me double later" situation though. I've found that spending the time up front will help the new team member become independent and productive much faster then just expecting them to figure it out. The "just come ask if you have any questions" tactic doesn't work well in my experience, because often they have no idea what they should be asking about.

There are certain tasks, like documentation, that are really attractive to inexperienced workers because they are tasks that are easily understood, can be worked on independently, and have a nice visible result. If he's jumping at the chance to do that kind of work, then my guess is he is not getting the support he needs to feel comfortable taking on the "real" work.

You may not be able to resolve this situation if you can't find him a mentor from the QA team, but you may be able to make it better by helping him with the aspects of his work you do know about. How do you keep Slack from becoming a distraction? Could you explain the best way to communicate changes across the teams? There are probably a hundred little tricks you know for being effective at work that you picked up over the years that could benefit a new team member.

  • Also worth pointing out that it can be a win-win for new hires to work on documentation. They get a better understanding of the “as-is” state (which they need in any case), and you get better documentation :-) – Joe Stevens Dec 11 '17 at 7:35
1

For solving issue of distractions, we find "making ordered lists" as a very good activity. Basically, team should come up with all the important activities for current cycle of the project, and then decide on what should go first (order it). Same thing should be applied by Q's manager to his workload. Of course, it can be internally generated by Q but subject to peer-review. We all get sometimes entrenched in fun workload that is not crucial to the project.

For example, writing docs is extremely important, but it can't get in front of extinguishing real fires. I think I take this approach from Joel Spolsky's "Picking a ship date".

On relation side, it seems like you are trying to be hands-on, and to some extent solve XY problem. Maybe it is better to discuss this in terms of your real problems, for example, saying that you can't rely on Q because other team will pull him aside.

Finally, there are few questions for you. What is the exact relationship between you and this Q fella? Are you in parallel teams, what is relation of Q to your own manager? It is more appropriate to talk to your manager, not to the Q's. As far as I understand communications, jumping diagonally is not good, talk to Q when he is on your team, or your immediate supervisor.

  • 1
    The relationship is ambiguous, as my own role is. This is of course a problem in itself. I seem to have recently 'become' the team leader (though this hasn't been formalized - frustratingly). Q is managed therefore by one of my peers. As to your advice: I think ordered lists, with managerial review, is a great idea. Q could construct his list and then review it (daily?) with his manager. This could help him learn how to identify priorities and ensure important-not-urgent doesn't trump important-and-urgent. – IrksomeEric Dec 10 '17 at 20:17
1

5. How can I diplomatically get his line manager to take a more hands-on approach?

This is really the only question that matters.

You approach his line manager, and complain that you don't have enough QA resource. If he asks you about "Q", then you have your opportunity to explain the situation. If he just sends you someone to work alongside "Q", then your problem is solved in a different way.

Your question reads to me that you want him to work mostly on important-to-you topics.

That is obviously fine, if you are his manager.

As you are not his manager, you really need to leave it to them to make clear that the needs of other teams, or the department generally (Slack / wiki) are not as important as yours.

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.