Building a QA team - Part 3
Updated: Jul 13, 2020
This is part 3 of the 'Building a QA team' series. In this series, I've explained what I’ve learnt in the creation of a great team, I've also explained the methods I’ve used to create the initial team using a set of shared values. In this final part, I expand on the methods I use to help ensure that the team continuously improves: 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 lead
A conclusion of what I've discussed and a primer for the next post
The process of building the team
The values I would want to embed
Inclusivity, Diversity, Openness and Accountability
A conclusion of 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 of what I've discussed
An overview of the process as a whole
Build on the foundation that the team has established, not change for change's sake
This final part will address the methods I've used to achieve the continuous, incremental improvements that identify a growing team. I also discuss motivation as a key factor. This includes do's and don'ts. Ones where I've been responsible and ones where I've been on the receiving end. One mistake I frequently encounter is that continuous improvement is mistaken for root-and-branch change. I look for subtle changes that build on the foundation that the team has established, not change for change's sake.
Ongoing Development
The team has formed, they appear to work well together and in their own team. Specialists in their respective cross-functional teams are making the right noises. You’ve created this diverse set of individuals who encapsulate what you look for in a performing team. The organisation is aware of what you're trying to accomplish. At this point it’s very easy to sit back and bask in the reflected glory. This is a bad idea. The hard part begins now. As individuals become comfortable, it’s very easy to fall back into norms that can disrupt the hard-won team ethos.
Learning
It is never just about learning a new framework or how to implement a pipeline
Secure a training budget
People like to feel valued. If budget permits, secure an amount to allow people to attend training to learn a new skill. Create a process to make this as easy as possible and communicate this process to the team. If the budget is not available, make use of the multitude of free courses available online.
It does not have to be technical training. A QA is a multi-faceted role that relies as much (if not more) on learning about the human experience, critical thinking, negotiating skills, conflict resolution, human-centered design. It is never just about learning a new framework or how to implement a pipeline. There is no downside to this approach. As long as the course can show a tangible benefit to the function of the team and the individuals role within it then everyone wins.
Learning sessions
Enable the team to spend 10-15 minutes a day researching a technique or reading a blog. It can be in their specialisation or a specialisation they are unfamiliar with. It can be design / UX / development / architecture. Anything that stimulates thinking. It has the added benefit of increasing their knowledge base which can then be filtered through to the rest of the team.
There may be concerns (usually from stakeholders) that 10-15 minutes a day will have negative impacts on productivity. Address these issues diplomatically by pointing out the benefits. The team are not battery hens. If individuals feel that it impacts their productivity, it might be useful to dig a little deeper as this may mask time-management issues.
Promote learning and experimentation in the QA space
It's important that teams are populated by diverse skill-sets and experience. The QA function is ever evolving. New ideas, new tools, new patterns, new methodologies are a constant. Allow the team to collaborate with those inside and outside of their skill-set to ingest new ideas and approaches. Promote lunch and learns / brown bag sessions / lightning talks as a means to communicate the output of these sessions. Allow the team to experiment based on the output of these sessions.
Promote learning in the domain
Being experienced in a domain is a double-edged sword. On the plus side, the combined knowledge and experience can result in a near instantaneous idea of how the 'thing' can be tested. On the negative side, this combined knowledge and experience means that in the process of accumulation, bad habits would have been picked up that are repeated time after time. This is known as front-loading. It can be very useful to pair up less experienced team members. Those less experienced can bring a fresh insight into the domain under test.
Business as usual
Gain support from stakeholders
None of these methods outlined have ever worked without support from stakeholders. It is up to you, as the lead, to articulate and promote the benefits of these methods. Some employers will feel unease at allowing off-site meetings. Anything away from the console is not 'real' work. This is true in organisations that have little to no trust in their employees, usually identified by the use of antiquated, outmoded time-tracking processes. If numbers are all that matters, then you and your team will be well on the way to becoming a number. There are options available. You can stay and attempt to persuade and educate or you can leave and find an organisation that understands the business benefits of trusting employees.
Don't micro-manage
Micro-management is a management style that attempts to excessively control the work of people in the team. No team member has ever said 'I'm such a better team member for having Jim scrutinise each and every decision I make in my day-to-day work'
Don't do it. You are building a team that you trust to make decisions given the information they have at the time. It is a guaranteed way to destroy trust. Don't do it. You are building a team that can think independently. It is a guaranteed way to introduce paralysis by process. Don't do it. You absolutely have to allow the team to breathe.
If the working day is spent peering over the shoulders of the team, it will leave you room for nothing else. It is a guaranteed way to burnout. Don't do it. You are building a team that thrives on ownership. It is a guaranteed way to stifle that ownership. Don't do it.
Be aware of how much time is spent controlling members of the team. You should be constantly evaluating your approach. If in doubt, ask the team. They are best placed to tell you if they are feeling micromanaged. Act on their comments.
Consistent overwork is not a virtue
Don't confuse commitment and ambition with overwork. There will be times when a degree of stretch may be expected. Don't allow it to become the norm. Allow the team to self-police.
Take breaks
Don't become a slave to the console. Encourage them to vote with their feet if they are press-ganged into pointless meetings. If they feel fatigued, take a break. Get some air. Go for a walk. Take their lunch. Encourage other team members to do the same.
Take leave
Regular leave is essential to take stock and recharge. Institute a no-email, no phone-call policy outside of work. Promote the use of a 'marching-order' email sent ahead of leave that contains just enough information to allow colleagues to understand the what and when of their current workload.
Don't use email or messaging as a substitute for active communication
Where possible, leave your desk and talk to the person. However, be respectful of interrupting that person if they have their head down on a problem. Make a mental note or create a sticky-note if required. Don't just type out a fire-and-forget message or email. That message will still display on the recipient's machine as a notification and distract from their task at hand.
Look out for each other
The team should help each other. They should learn to recognise the normal behaviour of their peers. Stress the need to be proactive. They should take time out to talk about their day and actively listen in turn. If team members are concerned about a colleague they should attempt to discuss this with them and if necessary, escalate.
Buddy up
Create a buddy system. The aim is to involve the new starters in the team culture. As per the team make-up, you will have a mixture of personalities. Allow the team to define their buddies but be aware that 'like' will often gravitate to 'like'. In the case of strong personalities this usually leads to dynamic, but potentially, explosive conversations. In the case of the shy, retiring types this could lead to very little in the way of useful output. A more useful approach is to match opposites. It is also useful to mix up the pairings over time. Mixing up the pairings will expose team members to different styles, opinions and knowledge. The final benefit is that it enhances the individual growth as each type has to adapt their style to effectively communicate with their peers.
Walk the walk
Be a role model to your team members and practice what you preach. Team members will appreciate the effort.
Socialisation
Encourage social gatherings
The team socialising outside the confines of a work environment has the benefit of lowering barriers that exist in the workplace. This allows for a more relaxed environment in which issues can be discussed without fear of misinterpretation by non-team members who may not be privy to the underlying background.
Attend social gatherings
You may find that reticent individuals will open up due to a change in environment during off-site get-togethers. As a lead you must attempt to approach these conversations with an open-mind, more often than not you will acquire information about individuals that may help in your interactions with them in the workplace. Conversely, team members will also gain information about you. However, don't force work based conversation, if you are alert, you will gain knowledge regardless of the topic of discussion.
Get to know the team
A good team lead will understand the meaning in being able to 'read the room'. Make time to get to know your team on a personal level. This approach will vary between individuals. Understanding the team on an individual level allows a lead to sense when tensions arise / interactions are fraught in a group setting. They can read the room. It also has the advantage of being able to step in early to head off potential misunderstandings or conflict. The ability to read the emotions of others is linked to 'social intelligence' which, in turn, is linked to performance on team-based problem solving tasks.
Allow the team to get to know each other
Relationships are established via regular interaction, both positive and negative. Healthy disagreement is a sign of a maturing team. Foster break-out sessions. Don't feel slighted if the team decides to run a session without you. This is never about you.
“If in doubt, just be kind”
Create a career path
The aim is to retain personnel. A structured path for career advancement is an invaluable tool in making people want to stay with the organisation. Replacing personnel is very expensive. A clear and achievable career path should be articulated to the team. There will be occasions where individuals fall short of a particular milestone. This is to be expected. How it is addressed is key. As individuals reach a particular milestone they should be rewarded. It’s worth bearing in mind that not everyone has aspirations to be a leader, different people have different motivations.
Continuously motivate
Once an initial team has been formed the goal is to ensure that the team continuously improves.
An awareness of what motivates people will help:
Some people are motivated by achievement
Some people are motivated by feeling valued
Some people are motivated by ambition
Some people are motivated by mastery
Some people are motivated by empowerment
Some people are motivated by incentives
Some people are motivated by salary
Some people are motivated by helping others
There is no ‘one size fits all’. Nurturing a safe, supportive and inclusive environment is key.
All too often I’ve experienced the ‘Continuous improvement’ mantra that, on closer inspection, amounts to nothing more than empty words, unfulfilled promises and box-ticking. Don’t become part of that particular problem.
Finding out what motivates people is the first step, their goals can then be tailored towards this motivation. This information is very useful when discussions with the team occur as you will have an overview of individual expectations which will inform the overall team outlook.
People naturally grow in person and their career. Don’t be an obstacle to this growth.
Be Kind
Building a team is not an all-or-nothing exercise. Gathering the people is relatively simple. Creating the conditions that engender teamwork and trust is more complex and takes time. The methods outlined above will work but they have to be applied within the context of the organisation you are building the team within. If in doubt, just be kind.
Conclusion
In this post I've looked at the methods I've used to achieve the continuous, incremental improvements that assist a maturing team. I also discussed motivation as a key factor in both individuals and the team as a whole. This includes do's and don'ts. Ones where I've been responsible and ones where I've been on the receiving end.
Teams don’t just ‘happen’. They are a result of a structured approach that mainly consists of creating a diverse team make-up, engendering mutual respect, inclusivity, actively listening and reacting to what is in front of you.
It takes time and real effort. There will be highs and lows. People are, on the whole, intelligent and caring. Treat them as such. They are subconsciously aware of face-value efforts and will react accordingly. Be true to yourself and understand that not everything will go to plan. Be prepared to back your team.
Some may question the value of these methods versus 'real work' . If you quantify 'real work' as sitting at a console for hours on end churning out slabs of code or writing tedious test scripts then this post isn't for you. I would posit that forming well-rounded relationships amongst peers will return far more value in developing quality software than any amount of solo effort.
I haven't discussed timescales for implementing these methods. Everyone's experience will be different. If some control is needed, usually in response to a request from stakeholders, a simple short-term, medium-term, long-term outline can be provided. I've also seen metrics used as a measurement tool. I've not yet figured out how to qualitatively measure contentment or happiness. Inspect and adapt continues to work for me.
The benefits to an organisation in high-performing teams cannot be understated, yet somehow they frequently are.
You can follow me on twitter where I post presumed nuggets of learned QA wisdom.