How does one tactfully express concern over a team member's capabilities?

Question

I'm a developer and the person I'm describing has been with us for over a year as part of the Quality Assurance team. They've been trained up by a true veteran of QA and while they aren't exactly the most software literate, they're capable of producing decent test plans and thoroughly testing pieces of functionality if they're given sufficient explanation as to what it is and what it needs to do.

However, this requires quite a degree of hand holding; explaining some relatively simple shell commands*, database queries used to validate results**, and the general meaning of certain stack traces that really shouldn't be brought to development's attention as something urgent. This sort of situation has been going on for a while; it did slow down while they were being trained and mentored by the veteran QA member, but since they announced their resignation, the person in question has needed more hand holding.

This afternoon I was helping them with a typical RESTful request, with query parameters attached. I explained to them that the resource needed to be written in a specific way and that it required two specific query parameters. They seemed confused at the notion of query parameters even though they had been testing our RESTful application for about seven months.

I'd like to raise my concerns with my manager. I'm not known for being blunt or confrontational, I'm normally a peaceable developer who looks to help the team out when they need it. However, I feel that this issue does need to be brought to their attention.

I'm not sure how to go about it tactfully. In communicating this concern to my manager, what should I seek to avoid saying, in addition to expressing my concerns? I don't want to sound panicked in an already panicked situation (the testing needs to be wrapped up in a relatively short time frame).

---

^{*: The person in question has been using these commands most the entire time they've been here, and they involve things like tailing logs, listing the contents of a directory, and changing directories.}

^{**: These were queries that they requested that development author, which seems strange all unto itself.}

Answer 1

I suggest that you focus on what you are trying to achieve here: your goal presumably is not simply to tactfully express concern, but you are trying to express concern for a wider purpose.

What is that purpose? Are you trying to get better training/mentoring for this person? Are you trying to get them to not do certain things that they keep doing? Are you trying to improve communication?

If you focus on what you are trying to achieve, and try and be constructive about it (i.e. don't just bring your boss a problem, try and bring suggestions too), this is probably a good way to approach your boss.

In summary, I would avoid saying things that summarise as "I am concerned"; I would avoid talking about characteristics of the person; instead focus on specific technical/communication problems that need to be solved.

Answer 2

I would say this is partly dependent on how much the 'hand-holding' is affecting your work and that of others in the office.

It is also worth considering what it is about this person's work that they are finding difficult - for example is it the concept of query parameters that they find confusing or perhaps just the terminology that you are using.

Personally I would reccommend first discussing this more with the trainee if possible before going to the manager. Next time you have to explain something you can pause periodically and check that they are still following you or you could just generally ask them in as friendly way as possible how they are finding the work.

Answer 3

You said yourself that the QA team is capable of doing a thorough job if they gain a sufficient understanding of what your software does. Anyone who tests something needs to understand at a fairly detailed level how it works even if they themselves aren't developers. This requires a certain level of interaction. The amount of interaction is what is causing you concern, right?

You have to be careful about making assumptions about what you think the tester should know. For example, you mentioned that the meaning of a certain "stack trace" should not be brought to the attention of developers as something urgent. Well, how would a tester KNOW if one stack trace is a real problem and another one is not? You simply have to explain this and take it seriously every time.

You also mentioned problems with shell commands for listing/changing directories. I find it hard to believe that the tester can't perform these. Perhaps their questions are not really about the form of those commands, but more about WHAT they are looking for. Developers often get caught up in answering each question to them literally without being mindful about what the asker is getting at. Maybe questions about changing directories are really questions about the file structure of your application?

That said, it might be that this person really can't do their job. On the other hand, it is far more likely that this is fallout from having just experienced the removal of a senior lead. You should expect to have to interact more with this department as a result. Depending on the complexity of the application, you may need to specifically allocate more time for this. That's normal and if I were in your shoes that's what I would indicate to my manager.

Answer 4

I learned RESTful services on mu own within 30 minutes - OK,I admit it. I do third level sys engineering and my boss told me that I could teach a PhD level course in TCP/IP v4. And at that time, I knew something about web programming. I am way past knowing a bit of web programming now :)

Your trainees(*) may be missing something fundamental about the nature of CRUD requests in their on the job training, which looks very on the spot,catch as catch can and ad hoc to me. If all they are getting from you is bits and pieces and dribs and drabs that don't make any particular sense, then the problem is you not them. These people need some form of formal, dedicated training on the basis, and I am not sure that your org has provided this boot camp type of training.

The other problem may be that some of you are not the best explainers around I used to work with a very bright fellow, who was nil in imparting any kind of knowledge. Fortunately, as a senior engineer, I knew my stuff inside out and could make out what he was trying to say. After a while. And I was successful only that because I knew at least about the subject as he did. Needles to say, neither the top management nor I were not relying on him to train the staff.

If the students fail, the first people I blame is the teachers. From what I gather from your post, you team did not provide any basic, formalized training and you did not get your most effective communicators to provide it. When it comes to training on the basics, you need to be systematic about it. Hand holding works if the trainees have a grasp of the basics. Otherwise, you are talking past them and bombing out. You are providing them with bits and pieces of fish with little to no explanation on how the fish ended up in your hands, while deluding yourselves that you actually taught them how to fish.

Having said that, I learned RESTful services on my own within 30 minutes and I am disturbed that after seven months, the trainees could not dedicate a weekend of their own time to learn about RESTful services on their own.

I'd try to stir up the pot and apply some heat to it by requiring the trainees to provide lightning talks about RESTful services during the lunch hour. Today is Friday, the weekend is coming up, so they have plenty of time to prepare each a 5-minute lightning talk on some aspect of RESTful services by Monday or Tuesday of next week.

(*) I realize that you have on trainee - I am using "trainees" to scale the answer up to several trainees. Your trainee will have to come up with the 5-minute lunch hour lightning talks about RESTful services all by themselves.