What I actually do when I walk into a team with no QA at all

Source: Dev.to

Why a QA Lead is hired

When a company hires a QA Lead, it often means the team has outgrown how they handle quality. Releases need to be more predictable, and they are ready to make that happen.

Common expectations

In many places, QA has meant “the person who checks things at the end.” So when someone new joins with “Lead” in their title, engineers quietly wait to see if more process is about to land on their desk. Most QA leads respond by producing something visible—a strategy document, a new framework, a test template—something you can point to in week one.

A better starting point

I’ve learned there’s a better starting point. I start by talking to people. I ask how work really moves from idea to release, where and how testing happens, where things tend to slip, and what they wish was clearer.

If you introduce a framework before understanding that, it might solve your need to show impact, but it rarely addresses the real issue. It doesn’t take long before the same concerns from onboarding and early conversations start resurfacing: work that keeps taking longer than expected, releases that are hard to predict. By then I’m not surprised. I’ve already seen the pattern. I just connect the dots.

Listening first

The first practice I introduce is usually something the team already talked about but never turned into a habit.

Turning ideas into habits

That’s what I actually do. I listen for what the team already knows has to change, and help turn it into something we can build together.

What’s next

The next post looks at the other side: what happens when a team already has processes in place, and they still are not working.