Building a QA Team — Part 1

8 min readJan 29, 2024

“Building a team that communicates freely and openly towards a common goal in the pursuit of a quality deliverable will always outperform a collection of disparate individuals with their own agendas.”

Introduction

A team is the beating heart of any software development process. People develop software. Those people have differing roles. Those people have differing skill-sets, values, inherent biases, approaches and communication styles. The list is endless. As this is aimed at QA I’ll concentrate on building a team to support the QA function. The role of a QA function is context driven. It is dependent on the wants and needs of the organisation. No two QA functions will be the same. Creating a diverse QA team with shared values will make it easier to promote that mindset and those values to the cross-functional teams that the QA’s are a part of.

I’ve worked within functions that have contained some of this approach. I’ve formed teams based on this approach. There is no downside to implementing this approach unless you view people as ‘resources’. That has never worked for me. I like to treat people as people with their own ideas, strengths and weaknesses.

In this 3-part series I’ll explain what I’ve experienced in the creation of a great team, I’ll also explain the methods I’ve used in building a team. I don’t dive too deeply into the technical aspects of team members. Tool-sets, languages and basic technical concepts can be taught relatively quickly. They can also change dependent on the organisational expectations. Communication skills and attitudes can be coached over a period of time. I look for those qualities that are transferable regardless of the tech stack. I want to build teams that last, even when team members leave (as they will). There’s a certain satisfaction in knowing that the attitudes and skills you’ve helped to embed will be replicated within other teams, at other organisations.

Part 1:

The problem I’m trying to solve.
What is a team?
The qualities I look for in team members.
The qualities I aspire to live up to as a manager / lead.
A conclusion on what I’ve discussed and a primer for the next post.

Part 2:

The process of building the team.
The values I would want to embed.
Inclusivity, Diversity, Openness and Accountability.
A conclusion on what I’ve discussed and a primer for the next post.

Part 3:

The ongoing development of the team.
Learning, Business as usual and Socialisation.
A conclusion on what I’ve discussed.
An overview of the process as a whole.

“A QA function advocates for the implementation of a quality mindset at each stage of the development lifecycle via coaching, mentoring, pairing, debate and hands-on effort”

The Problem

Without identifying the problem to be solved how can you possibly start to derive a solution?

How do you build and lead a QA team that, by the very nature of the agile development approach, don’t work side-by-side with their fellow QAs through the working day?

The specific problem to be overcome is ensuring that the QA can work within the constraints of their cross-functional team and as part of a wider QA function.

These two may have different priorities and different approaches.

This series of posts doesn’t attempt to solve the specific cross-functional team working paradigm but will focus on the creation of a shared values structure for a specific QA function.

This shared values structure naturally leads to the evolution of a team.

The added benefit of this approach is that the same characteristics can be applied within the cross-functional team in the pursuit of the whole team ownership of quality.

What is a team?

We can all point to successful teams.
Football has Manchester United
Rugby has the All Blacks.
The Red Arrows would be classed as an exceptional team.

Identifying what makes them successful?
That’s way more difficult.
There are thousands of articles and studies that attempt to answer this.
The majority of them contain valid points, the majority of them appear to address repeating themes.
Context is everything.
It will depend on what the expectations of the organisation are. It will depend on you and your approach.

“I had way too much information and interaction” is a statement repeated by no competent team lead ever.

My approach is “Building a team that communicates freely and openly towards a common goal in the pursuit of a quality deliverable will always outperform a collection of disparate individuals with their own agendas”

There are numerous definitions of the word “team”.

team — noun

A number of people who act together as a group, either in a sport or in order to achieve something

team — verb

To act together, to achieve something

In this case, both the noun and the verb are relevant.

I’ve been responsible for these two scenarios:

There is an existing team you have to lead
You have to create a team from scratch

I concentrate on the people with the right characteristics first.
I look for people who are eager to learn.
I like people who are aware of their own, existing, limitations and are unafraid of improving these limitations.
Knowledge of tool-sets isn’t a factor and isn’t something I prioritise.

Qualities I look for in a competent QE

These are what I’ve looked for when considering team members, your experience and expectations will be different:

Independence of thought and action.
An empathetic outlook.
A challenging mindset.
A diplomatic approach to conflict resolution.
A collaborative nature.
An innate curiosity.
A supportive disposition.
A willingness to be wrong.
Technical aptitude.
Personable.
Bravery in the face of adversity.

The presence of these qualities can be derived during the interview process or from an initial informal chat with existing team members. Structure either interaction so that the conversation flow covers these points via examples or scenarios.

The skill here is to not converse in bullet points but in a relaxed exchange of ideas.
The onus is on you, as the leader, to steer the discussion to obtain the information you need.
I’ve seen, and faced, the interviewer offloading responsibility onto the interviewee.
You know what you want, don’t make the person jump through artificial hoops to make your job easier.
Information obtained at these stages can then be used when formulating hiring decisions or personal plans.

You may have people that are very diplomatic but aren’t as strong when faced with push-back.
That’s okay.
You may have people that are technically adept but are dogmatic in their approach.
That’s okay as well.

No-one is perfectly formed from the outset.

Qualities I aspire to obtain as a QE team lead

“Be the change you want to see”

When I’ve built a team, these are what I’ve aspired to:

Respectful of different opinions.
An ability to actively listen.
The willingness to the do the right thing, not the most expedient thing.
An inclusive mindset.
A servant / leader philosophy.
A mentor / coach.
Adept at communication, both written and verbal.
An understanding of the necessity of standards.
An in-depth knowledge of the QE role and the challenges that can be encountered.
An ability to communicate information at the appropriate level dependent on the level and person you’re communicating to.
Exercise the mental fortitude to challenge existing wisdom.

Sound like any leader profile you’ve ever read?
These characteristics have stood the test of time.
It is vitally important that you are aware of your own limitations in these areas as without this awareness you run the risk of becoming the very thing you dislike.
Awareness means that you can develop an internal strategy to mitigate these limitations.

These limitations don’t disqualify you from being a leader for your team, they will ultimately drive you in becoming a better lead.

There’s a difference between team conversations and team decisions.

Part of your job, just like the day-to-day work as a QE, is to evaluate logical arguments and make decisions based on them.
These decisions may not always be popular.
That’s okay.
It is also useful to be aware of team discussions devolving into talking shops.
Part of your job is to facilitate these discussions and that means ensuring the ‘thing’ being discussed is the ‘thing’ being discussed.

Every organisation has someone who will ultimately make decisions.
You may be expected to make decisions that affect the team.
It’s okay to gather information to help you make these decisions.
Don’t be pressured into making a snap decision based on incomplete information.
Unless you control the relevant factors, the decision you make will be part of a bigger decision that you help inform.
This isn’t the military, you aren’t building a bridge for refugees who are under fire.

It is possible to disassociate team building from knowledge of the domain.
It’s very much harder to make a meaningful impact without an in-depth knowledge of the function you’re representing.

A large factor in the decisions you take are predicated on an ability to understand the implicit nuances that a QE faces on a daily basis.

It’s also important to understand that experience (of different types) is no indicator of expertise.

I have my own, internal, issues with personnel being considered fit for a role because of time served in post or time in a particular role or time spent gaining domain knowledge.

If someone has spent 10 years in a particular role there’s no logical conclusion that leads to them being a good leader.

It also doesn’t apply that because they have an in-depth knowledge of their function they can automatically transition into someone who can make sound decisions on behalf of, and for, the team.

It means that just because they have an encyclopaedic understanding of the domain that they have the temperament or critical thinking faculties to facilitate the growth and maturity of the team.

Conclusion

I defined the problem to be solved, clarified what I mean by a team and identified the characteristics of individuals I like in forming a QA team.

I also identified the characteristics of what I consider to be a good QA team lead.

Here’s two experiments you can try, they’ll require introspection and honesty.
If you’re a QE:

How many of those qualities do you currently possess?
Which do you possess but need to improve on?
Which of those qualities does your lead currently exhibit?
If they are missing qualities (in your opinion), be nice, provide constructive feedback.

If you’re a QE manager/lead:

Which of those qualities do you exhibit?
Which of those qualities do you need to improve on?
Which of these qualities do you practice in the team and organisation?
Any of your engineers are potential leads, which qualities do you currently coach?
How could you coach those qualities in your day-to-day work?

In Part 2 I’ll cover the process of forming the team, outlining the core values you would want to embed.

I’ll cover Inclusivity, Diversity, Openness and Accountability.

You can follow me on twitter (sort-of) where I tweeted (or x’ed) pre-space-karen where I shared presumed nuggets of learned QA wisdom and upset a few echo-chamber individuals in the process.