How do you influence teams resisting process improvements?

Overview

Influencing teams resistant to process improvements is a critical leadership challenge in QA, directly impacting release quality and team efficiency. The strategic challenge lies in identifying the root causes of resistance and demonstrating the tangible benefits of change through data-driven approaches and collaborative solutions, ensuring manual testing efforts remain effective and targeted.

Interview Question:

How do you influence teams resisting process improvements?

Expert Answer:

Influencing resistance requires a structured, empathetic, and data-driven approach. My strategy focuses on understanding the "why" behind the resistance, demonstrating tangible benefits, and fostering collaborative ownership.

1. Empathize & Diagnose: First, I conduct 1:1s and team discussions to understand the specific concerns. Is it fear of increased workload, lack of understanding, previous negative experiences, or perceived bureaucratic overhead? This helps tailor the improvement. For example, a team might resist structured exploratory testing sessions if they feel it adds time without clear value, or developers might resist clearer defect reporting if they perceive it as blame.

2. Data-Driven Justification: I link proposed improvements to current pain points and relevant metrics.

   • If Defect Leakage Rate is high post-release, I propose enhanced peer reviews of manual test cases or structured exploratory testing for critical user flows to catch issues earlier.
   • If Defect Reopen Rate is problematic, I suggest improving defect reporting clarity (steps to reproduce, environment, expected vs. actual) and validation protocols during retesting.
   • If UAT Pass Rate is low due to misunderstood requirements, I advocate for early QA involvement in requirement grooming, using techniques like BDD-style acceptance criteria for manual test case design, directly impacting Requirement Coverage.

3. Pilot & Prove Small Wins: I don't mandate large-scale changes. Instead, I propose a small-scale pilot on a less critical feature with a receptive sub-team or individual. We track its impact on Test Execution Progress and quality metrics for that specific area. For instance, piloting a focused regression suite update based on risk analysis for a module often reduces last-minute bug finds and builds trust.

4. Collaborate & Co-create: Once small successes are visible, I involve Developers, Product Managers, and Business Analysts in co-creating the refined process. For manual testing, this means collaborating on:

   • Test Design: How to integrate clearer acceptance criteria earlier.
   • Execution Strategy: Optimizing the balance between deep functional, exploratory, and regression testing.
   • Risk Mitigation: Identifying areas where manual testing provides unique value in uncovering subtle user experience issues or edge cases without relying on code. This shared ownership helps them internalize the benefits, such as reduced rework or clearer handoffs.

5. Communicate & Iterate: I maintain transparent communication on progress and metrics. Celebrate successes. Be open to feedback on the new process itself, iterating as needed. This approach addresses delivery pressure by ensuring improvements are practical, integrated, and clearly contribute to release readiness and overall product quality.

Speaking Blueprint (3-Minute Verbal Response):

[The Hook] "Delivery Managers, addressing resistance to process improvements is absolutely critical for maintaining our release quality and predictability. Often, this resistance isn't malice; it's a fear of disruption or a misunderstanding of the 'why.' However, ignoring it leads directly to higher Defect Leakage, unpredictable Test Execution Progress, and ultimately, a compromised UAT Pass Rate. My primary goal is to shift that perception and build consensus around shared quality objectives."

[The Core Execution] "My strategy for influencing teams resisting change is fundamentally human-centric and data-driven. First, I focus on empathetic diagnosis. I initiate candid 1:1 conversations and team discussions to truly understand the underlying concerns – whether it's perceived workload increase, past negative experiences, or a lack of clarity on benefits. For example, if a team is hesitant about a more structured exploratory testing approach, I'd first listen to their fears about time constraints or creativity stifling.

Second, I leverage data to make a compelling case. If our Defect Reopen Rate is consistently high, I'll propose improvements in defect reporting clarity and retesting protocols, demonstrating how this reduces future effort for both QA and Development. If Requirement Coverage is poor leading to scope creep, I advocate for early QA involvement in acceptance criteria refinement, showing how this prevents last-minute churn. We then pilot these changes on a small scale, tracking tangible metrics like improved Test Execution Progress or reduced Defect Leakage for that specific feature.

Third, I emphasize collaboration and co-creation. Once we see early wins, I involve all stakeholders – Developers, Product Managers, Business Analysts – in tailoring the process. This ensures any new manual testing strategy, whether it's enhanced regression analysis or deep functional validation, is practical and aligned with their workflow. We coordinate test activities to manage risks effectively and clarify expectations around release readiness, ensuring everyone feels invested."

[The Punchline] "Ultimately, it's about building trust and demonstrating how these improvements empower the entire team, not just QA. By focusing on shared goals of reduced Defect Leakage and higher UAT Pass Rates, we cultivate a culture of continuous improvement that ensures high-quality, predictable delivery and robust Requirement Coverage without sacrificing velocity. It's about making our collective journey towards a shippable product smoother and more efficient for everyone."