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?

  • 6
    Updated title - she's not overriding you, but, as your details reveal, she's questioning everything but then ultimately agreeing once she has the other opinions. A dev lead who over-rides you with a differrent opinion is a different situation. Commented Feb 28, 2017 at 21:51
  • she is not agreeing to what i said. instead ignoring it and asking for help from someone else, when im already openly providing it.
    – nysa
    Commented Feb 28, 2017 at 22:42
  • 4
    fair enough, yours to edit. I think that other readers will see the title and expect to see an actual override not a questioning then eventual agree, but up to you. Commented Mar 1, 2017 at 0:57
  • 2
    I'm thinking override is more like To counteract the normal operation of something at en.wiktionary.org/wiki/override Commented Mar 1, 2017 at 0:59
  • 1
    You may get better responses about handling such office politics matters on workplace SE. And probably if you search you will get some great answers. Commented Mar 1, 2017 at 19:38

3 Answers 3


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.

  • These are really good liners that I can use going forward. Hiowever, 1 clarification and follow up question: When you said "If the questions aren't being directly asked of you.." ---- I stepped in to answer when one of my reports who was in question wasnt available.So in that case, I think it is my job to step in to answer
    – nysa
    Commented Mar 1, 2017 at 18:20
  • 1
    @nysa, agreed, but then the handling depends on the type of question being asked and whether you've had specific communication from that person on the subject. (It might also depend on why the person wasn't available.) The most general thing I could say would be, share what you know, and if relevant share what you guess, but make it clear which is which and promise to check or verify your guesses with the person later. "Bob hasn't told me about that specifically, but I know he was looking into it. I expect he would have told me if the test came out negative, but I'll verify with him."
    – Wildcard
    Commented Mar 1, 2017 at 19:40
  • Note that the link is to a scientology site Commented Sep 30, 2017 at 12:05

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.

  • +1, yup, 1:1, discuss requirements and bring in management to help! Added some linefeeds to help clarity and break up the 'wall of text'. Commented Feb 28, 2017 at 21:45
  • @DEnumber50 did u do the 1:1 directly with the dev lead?
    – nysa
    Commented Feb 28, 2017 at 22:57
  • @nysa yes I did; just mentioning to him that I wanted to discuss some "Process Stuff"
    – DEnumber50
    Commented Mar 1, 2017 at 23:50

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.


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.

  • 1
    Thanks @Michael, but your answer is really very generic, and most of it is what I already do. My question here is very specific. Someone overriding your judgment calls and / or decisions without going through the proper channel of communication. I think you didn't get the question.
    – nysa
    Commented Feb 28, 2017 at 20:40
  • I think I did. There is no FIX for this in my opinion and experience. What do you think a fix would be? Tell off the dev? "Correct their mistakes". No, there is no simple fix. My approach is long-term, i.e. the fix will takes weeks or months to slowly apply. But let me add one more bullet point that might (or might not) help. Commented Feb 28, 2017 at 20:55
  • Added a couple more points. Commented Feb 28, 2017 at 21:02
  • 1
    btw "going through the proper channels" is also an anathema for some devs who feel that logical solutions speak for themselves and management is often overhead. ymmv of course. Commented Feb 28, 2017 at 21:05
  • 5
    If you already do the above, what was the most recent specific incident that you discussed with the person in a private 1:1 ? How did the conversation go? Commented Feb 28, 2017 at 21:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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