How to deal with a lead developer who questions every action or process suggested by QA lead?

Question

This is a very specific question: I am QA Lead with reports who are senior QA engineers. Half of my team is new. I have more experience in terms of some of the SDLC processes followed in our company than the other QA team members. And I have also brought in a few process streamlining in our team and continuously doing so.

There have been situations where the Devs and the QAs ask questions about this same process. And I always jump in to clarify when this happens. Since I have been there, done that. However, in most of these instances, the Dev lead says something to this effect after my response: "We will discuss this with the QA engineer and the PM" OR "I will ask release". Though I don't mind this, since I am definitely not the 'know-it-all' person, her responses are generally for those things that I have already done myself, asked and know the answer of. It is as if she doesn't trust me. And always, the answer she gets from the 3rd party is exactly what I had suggested or replied.

But when she does this, she forgets that overriding the info I give, or suggest and not acknowledging it undermines my value in the team, and especially so in the eyes of my reports. Not that they don't already know that I was right, but the fact that the Dev lead thinks I am not reliable.

I want to approach her with this face to face to understand why she does this and make her understand its effects but I want to know how to approach it. Any advice?

Answer 1

Emphasis added:

There have been situations where the Devs and the QAs ask questions about this same process. And I always jump in to clarify when this happens. Since I have been there, done that. However, in most of these instances, the Dev lead says something to this effect after my response: "We will discuss this with the QA engineer and the PM" OR "I will ask release".

If the questions aren't being directly asked of you, you are doing two things:

1. Jumping in to answer questions directed at another, and
2. Feeling bad when your interjection is not taken as the final word.

Now admittedly I may be missing parts of the broader picture. But this is what's conveyed to me by reading your question post.

---

(It also appears that the advice you are referring to is "soft" advice about process implementation details, rather than about specific technical issues observed and tested from your role as QA. The rest of this answer is written from this assumption.)

My recommendations are:

1. Start consciously validating others' contributions to the conversation. This doesn't have to be (and shouldn't be) over the top. Remarks like,

   "That's a good point," or

   "Thanks for bringing that up," or

   "Yes, that matches what I've experienced."

2. If a question is directed at someone else, let them answer.

3. If you have something to say from your own experience about a question that was either directed to another, or was directed generally, let whoever is speaking finish, and then open your statement with,

   "I have some experience on that I'd like to share," or

   "I'd like to expand on Joe's remarks," or

   "I see where you are coming from; ____ and ____ are important factors to keep in mind. However, there's a situation I've seen before that I want to avoid, which is ____ and ____."

   In short, get agreement from your audience to receive your communication rather than just "jumping in." (Note: It's possible you're doing this already, but from what's conveyed in your question I think the area would benefit from conscious attention.)

4. Realize that the dev's communication with others is okay. It won't hurt you. Just because you've said something about a certain subject, if she then discusses it with someone else also, that's okay.

   The flip side of this:

5. If you don't feel she really got what you said, try politely responding when she says, "We'll talk to Release," with something like,

   "Yes, of course you will. Did you get what I'm driving at, though?"

   Or, "okay, I just want to be sure I've successfully communicated; you got my opinion, at least, right?"

   (Said in a friendly tone, of course.) In other words, elicit an acknowledgement.

---

All of this comes under the heading of the handling of communication. It is this, not technical know-how about SDLC processes, that you should focus on to improve the situation.

Answer 2

I think this is a delicate topic in the software industry, one that I have experienced in the past.

Essentially what I did was have a one-on-one conversation with the person and tried to bring it up conversationally with the development lead. This led to the conversation of job place requirements and what I was responsible for and what the dev. leads responsibilities were.

I explained in clear speech that I was concerned that I was being undermined in these meetings, and how that might translate to my peers.

Ultimately the conversation was then placed in a meeting with our director of development, where the responsibilities were discussed. Overall the dev. lead was pretty annoyed that I brought it up, but I could see an immediate change in the meetings allowing me better control of my team.

Sometimes communication can be hard for some people to hear, but for me this has made a difference in my day-to-day and hopefully overtime the dev. lead can understand what I was trying to do.

This response may not be the answer to your specific situation, but it's my particular method.

Answer 3

I've seen this pattern in nearly every shop with qa/qe and engineers. My advice from being a dev for 20 years and now a qa engineer for 5 years:

• This is a practice that programmers actually do with each other. Did you check this? what about that? What about the other? It's not "questioning the person" though (although it certainly can feel like it), it's going through the assumptions and facts together and seeing what we have. I have seen non-programmers not be able to handle this well as they don't expect it or understand it very well

• Patience. I see my role as QE (Quality Engineer) is to bring up potential issues or things that might be of concern. Don't be alarmed if only 1/4 of them are real bugs or issues. Don't think of it as 75% rejection. Think of it as 25% success and if you didn't find that 25% the company would likely have lost customers / revenue, etc. You may be surprised to find out how much the devs value to 25%.

• Communication. It is essential to have good communication. With managers and peers I recommend a 15-30 minute 1:1 every week. For 'collaborators' such as the position you describe I recommend monthly 1:1's During these meetings (maybe not the first!) you can start to bring up the issues you mention. However I recommend you do this one issue at a time. Don't turn the whole session into a complaining one. Try to bring up several positive points or other work details and then have 1 "why do we/you do this and how can we do it better".
  You should also have regular communication with your boss and ask them to help. At some point up the chain is a managerial position such as director or vp that overlooks both of you. You may need to appeal to that person.

• Trust over time. If there is currently distrust I would look to take more time to establish trust. Make sure all your observations, bugs, etc are well-grounded, documented well, represent real issues to the business, etc. One example I can give is that it took me 9 months at my current company to 'prove' that better error handling would increase the bottom line. Once I had actually done that, trust went up - but it took 9 months.

• Make sure you test the right things. Make sure you relate your findings and observations to the business you are in. "Users can't read the font" comes across differently than "New user sign-up rates will drop, potentially affecting new user growth as currently required by our business model". Guess which gets you more resources (and respect) from the business?

• Be aware that some devs will take criticism of their code very personally. I myself often struggle with this when I am writing code. It's easy to say 'divorce your personal emotions from the code', but can be much harder to actually do as a professional who does care about the quality of your work. So some devs will take the criticism personally and want to 'check' it against another source instead of just accepting what they feel is like a criticism of them from you.

• Talking about criticisms... Remember that you are double-checking their work in your role. Think of them as double-checking your quality work as a helpful second set of eyes.

Finally,

Evaluate the situation

If all the above do not help... maybe it's time to move - and ask the right questions in the interview to make sure it is better at the new place.