This is a guest post by Rachel Kibler.
I had been the test lead on two products at a company for a few months. I had positive relationships with both teams and excellent relationships with my product owners. I had taken some time to adjust, figuring out how the teams worked and making mental notes of things to try.
We did massive rounds of regression testing on our mobile app before its monthly release. Our releases were large and thus quite risky. Almost every time, we would have code freeze, then immediately find issues when the richness of production data hit the app. It was common to have two or three fixes to go into our beta before release.
One release got to code freeze and then had another seven commits to the release branch before we went live, including some pretty large fixes. It seemed like our quality had become steadily worse over the prior few months, and this was a confirmation that we had lost our way.
As test lead, I wanted to do something to get us back on track. I called a meeting with the testers. The meeting was rough. I brought up the issues that I saw, talked about how we seemed to be slowly slipping, and then I went silent to let the discomfort sink in. I asked what we could do differently to avoid this situation again.
I threw out a few suggestions of things I thought we could improve, and I tried to get the testers to talk. They halfheartedly agreed with a few things I said, but for the most part, they didn’t say much. I came away with a sense that I had failed, both to empower them and to find a way to move forward.
A few days later, one of the testers pulled me aside to talk about how uncomfortable that meeting was. They said it had seemed like I was unwilling to listen to anyone because of how I handled the situation. I had come off as approaching the meeting looking for people to feel ashamed rather than wanting a way to make things better. My suggestions about things to improve didn’t have buy-in from the others.
It was hard to hear that I had stifled conversation instead of creating a space where it could flourish. And I realized my leadership style needed to change.
I needed to consider that I may not be right all the time. I needed to talk less and not move through things so quickly, taking time to listen and make sure everyone was understanding and contributing.
Instead of making my own opinions and thoughts “win,” I needed to be better about having strong opinions, loosely held. I needed to be more open to listening to people, to getting more information, and to possibly changing my mind. I needed to consider that I may not be right all the time. I needed to talk less and not move through things so quickly, taking time to listen and make sure everyone was understanding and contributing.
In retrospectives, I changed how I approached problems. I started laying out my concerns or frustrations and suggesting experiments to try for a sprint or two in hopes that things would improve. But then, I would back off and do a lot more listening than talking. The team seemed to respond better to that.
My leadership style is still developing, but a healthy dose of humility that came with being told that I don’t always know best was necessary for me to get started.
I know there will be more moments when I will be pulled aside, and I welcome them. The lesson about not always being right extends to more than just testing. I also need to be open to feedback about how my actions and behavior affect others.
Rachel Kibler is a tester at 1-800 Contacts in Draper, Utah. She can be found on Twitter @racheljoi.
- TestRail Leads in the Spring 2020 G2 Grid for Test Management
- Announcing TestRail 6.3 with Enhanced Jira Integration