9 Ways to Lead as a QA Manager
9 Ways to Lead as a QA Manager
Technical skills are essential for a good QA team, but once you have those skills, the way forward could be upping your leadership skills instead.
Join the DZone community and get the full member experience.Join For Free
DevOps involves integrating development, testing, deployment and release cycles into a collaborative process. Learn more about the 4 steps to an effective DevSecOps infrastructure.
In software development and testing, a lot of strain is put on improving technical skills. Getting the latest and greatest certifications, staying current with IoT testing and TDD/BDD, or learning a new programming language- all of these are likely to come to mind for ways to develop new skills, stand out in your department, and have a bigger impact.
But what if you felt like you already had all the skills you needed?
What if your whole team felt this way?
When QA managers empower their teams to come to the realization of “I have all the skills I need and now it’s time to apply them,” it’s not for purpose of egomaniacal overconfidence, but for choosing to uplevel the softer skills.
In addition to technical professional development, QA managers and test leads must work on their ability to create a valuable, creative team. That happens through a mix of understanding one’s own role, knowing when to step back and when to step in, and spreading the responsibilities and benefits of leadership.
Here’s how QA managers can up level those critical leadership skills.
Don’t Require Testers to Wait for Permission
Even though being a self-starter is such a valuable trait in the workforce, someone who waits for permission is still more common than someone who gives themselves permission.
What a QA engineer wishes he could change might be procedural, or something to do with how collaboration occurs with development. Within reason, he should feel able to simply make the change. It’s better to encourage testers to try new things and risk that they fail, rather than require that they come to you with every single new suggestion. This is especially important in an agile development environment, where roles and responsibilities are more fluid.
Understand the Value of Your Role
There’s no place for micromanaging people in agile and DevOps. Micromanaging is equivalent to moving too slow, and it represents a role-based rather than a project-based mindset. Most importantly, it doesn’t allow people to come together creatively.
So, time to let go of all the minute details and trust your team. Just because managers aren’t in charge of overseeing minute details, doesn’t mean they don’t have a valuable role. This feeling is something that managers switching from waterfall to agile struggle with often. In agile teams, managers are less like directors and more like mentors in charge of guiding others and clearing any blocks to progress.
Recognize That in Agile, Everyone Is a Leader
Daily standup meetings are a great example of the collaborative nature of agile. Everyone shares the things that are blocking their progress forward, and everyone present has a chance to clear those blocks for one another.
This can and should occur outside of standups too. Testers should feel comfortable reaching out to anyone else on the team (of any role) for help. Similarly, they should also be able to provide clarity and assistance to anyone on the team.
When everyone is clearing blocks, then everyone is a leader. Every day, everyone on the team has the opportunity to lead the way forward, so long as trust and collaboration are already in place.
Balance Technical Skill Development With Soft Skill Development
We’re not saying to give up on new technical skills for yourself or your team. Just don’t expect those skills to get anyone ahead without a deeper purpose in place.
In this TechWell interview, agile leadership coach Selena Delesie says it best: "I went to school for computer programming and mathematics. I did the certification training early on and I gained more technical skills. I took more classes to learn more things but it wasn’t helping me get a whole lot further ahead. I made smaller strides but in terms of my impact in the organization, it wasn’t as impactful as I wanted it to be. I realized that I had to really work on the soft skills, the personal skills sides and also fostering within myself, my own ability to recognize my own value, my own worth to gain more confidence, clarity, and how to communicate that message, how to connect with people. That’s really led to a larger shift in my ability to influence and impact in any place."
That balance may come by developing two skills at once, or by going back and forth every few months. You might make a personal commitment to being a clearer, more upfront communicator while also taking a Ruby class online.
Bring this mentality to your team by suggesting the hard skills and the soft skills they can work on during reviews, in informal office chats, or when they come to you for help.
Free Yourself Up to Tackle Bigger Problems
The best thing about not micromanaging testers (and instead trusting their ability to make decisions) is that you make more room in your schedule to provide even more value to your organization. You can identify bigger problems like resource waste or inefficiencies, issues in tightening the feedback loop to developers, or a gap in knowledge transfer between customer support and QA.
Tackle Any “Us Versus Them” Beliefs
An awesome company culture is invaluable. You can choose to contribute to an environment that’s igniting and inspiring or foster one that’s stale and pessimistic.
The “us versus them” mentality between testers and developers is a product of waterfall methods that separated the roles, processes, and timelines surrounding development and testing. Even with collaborative development methodologies in place, this mentality can still persist.
Fostering this mentality naturally puts up walls between testers and developers. Conversation barriers can impact product quality, so discourage this mentality whenever it’s spotted, and try to get to the bottom of why the notion still persists in your team.
Take a Situational Approach to “Stepping In”
High-performing teams don’t have anything in their way. Not people, not processes, not tools. These teams are self-directed and take initiative. That means that managers have to step out of the way.
In this interview, agile methodology coach Bob Galen notes, "Stepping aside does not mean that you’re not leading. To the contrary, I’ve always felt that this style of leadership requires more of you. It’s situational and subtle."
If you step in too much, you’ll send the message to testers that they need to come to you and ask permission more often. But if you don’t step in where needed, product quality will obviously suffer. Taking a situational approach requires that you use your intuition and judgment in the moment, rather than relying on existing rules and procedures.
Choose Passion and Purpose
It’s okay to get geeky. To get excited. To be visibly passionate. QA managers and directors recognize passion as the chief indicator of a tester’s future success at their job and their ability to positively impact product quality. Passion paves the way for every other skill to be developed. It helps testers to truly care about the entire lifecycle of a product.
Put simply: #lovetesting. For you and your team, this should come naturally. If not, figure out why.
Measure Your Success
Ultimately, how do you know if your management style as a QAM or test lead is working?
If your team is improving, then it’s working.
If you’re contributing to greater cross-departmental collaboration, if you’re helping testers to increase their hard and soft skills, if you’re removing blocks to development and deployment and innovating QA processes…Ultimately, if your management style allows testers to best do their jobs while freeing up your own capacity for organizational change, then you’re successfully managing your team.
Published at DZone with permission of Dayana Stockdale , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.