QA | Leading Also Means Deciding Without Slowing Down the Team

This is something personal, but also a common theme in agile environments: meetings to plan more meetings.

How many times have you had to make a decision without consulting the whole team — even while working under a democratic leadership style?

When collaboration becomes a roadblock

I understand that every leader organizes their team differently.
In my case, I used to believe that the best way to lead was to involve everyone: the Product Owner, Scrum Master, developers, and of course, all the QA engineers.

Especially during critical processes like production releases, it felt right to invite everyone to participate, share input, and help us reach the common goal.

Three meetings for one decision

With the excuse that “we’re all part of the team,” we ended up having meetings for everything:
One to discuss how we’d search for test cases
Another to choose which scenarios to execute
And a third to validate that the team was happy with the selection and assignment of the test cases

All this… while the sprint clock kept ticking.

But reality looked different: some people didn’t show up, others didn’t engage, and most had competing priorities.

Leading is not about imposing — but it is about acting

I value collaborative work. I truly believe that ideas improve when everyone contributes.
But I’ve also learned that leading isn’t just about listening — it’s about acting with good judgment when the team needs to move forward.

And that kind of decision-making doesn’t come from ego or control.
It comes from understanding that leadership also means protecting the team’s time, unblocking progress, and stepping in when the process isn’t enough.

Expert judgment matters

A QA lead must be able to:

• Read the context and make decisions without fear
• Know when to bring the whole team in — and when not to
• Fill in the blanks in the process
• Avoid the endless cycle of unproductive meetings

Because quality is also about efficiency, balance, and product impact.

A shift in approach made a big difference

Just like in research, there’s more than one way to reach the desired outcome.

I used to involve everyone at every step to get alignment.
Now, I follow this approach:

1. I make a context-aware, technical decision
2. I implement the best possible solution
3. I present the results afterward for feedback and validation

That shift helped reduce time, avoid friction, and increased our impact as a team.

Final thoughts

I still care deeply about including the team’s voice.
What changed is that I now understand — as a leader — that efficiency, productivity, team well-being, and customer happiness are critical metrics too.

It’s not about excluding anyone.
It’s about finding smarter ways to include — without slowing everyone down.