Wednesday, December 7, 2016

Tester as a Catalyst

Back in my school days, I was a chemistry geek. And if life had not shown me another path through being allergic to too many things, I would probably be a chemical engineer these days.

It seems very befitting that my past team helped me see that a big value I provide for the team could be best described in terms of chemistry - of me being a catalyst in my teams.

Catalysts don't make things happen that wouldn't happen otherwise. Catalysts speed up the reaction. Catalysts remain when the reaction is done with.  Potential for reaction exits, but sometimes you need a catalyst to get to a speed of noticing visible changes.

I love to look at my contribution with that perspective. The things that happen with a tester like me around are things that could happen otherwise but I speed up the reaction with information that is timely and targeted, and delivered in a way that is consumable. For many of the things, without a tester like me, the reaction doesn't start or is so slow it appears not to happen. A catalyst can be of any color, including completely invisible. I would like to think of myself as more colorful addition.

I'm working through my techniques of being a good catalyst in my teams. Here's some that I start with.

Introduce ideas and see if they stick

I have had the chance of hearing (through reading and conferences) to be introduced to many people's ideas of how the world of software could be better. The ideas build up a model in my head, intertwined with my personal experienced of delightful work conditions with great results that I want to generate again and again. The model is a vision into which I include my perceptions of what could make us better.

Out of all the things I know of, I choose something to drive forward. And I accept that changing is slow. I speak to different people and through different people. I work on persistence. And my secret sauce for finding the patience I'm lacking is externalizing my emotions on counting how many times it takes, writing notes for future me about my "predictions" to hide out of sight and venting to people who are outside the direct influence of the change.

I believe that while I can force people into doing things, them volunteering is a bigger win, leaving us working on the change together. I can do this, as I'm "just a tester" - as much as anyone is just anything.

Positive reinforcement

People are used to getting very little feedback, and I find myself often in a position of seeing a lot of things I could give feedback on. And I do, we talk about bugs, risks and mitigation strategies all the time. But another thing I recognize myself doing is positive reinforcement.

I found words for what I do from Jurgen Appelo. He talks about managers shaping organizations with the best behaviors leaders are willing to amplify. I try to remember to note exceptional, concrete contributions. I try to balance towards the good.

And recently, I've worked more and more on visualizing and openly sharing gratitudes with kudo cards. Not telling just the developer that his piece of code positively surprised me on some specific aspect, but also sharing the same with her manager who has less visibility on the day-to-day work than any of us colleagues in teams.

If I want to see more of something, instead of talking about how it is missing in one, I prefer talking  how it is strong in another.

Volunteering while vulnerable

I find myself often in middle of work I have no clue on how to do. I used to hate being dependent on others, until I realized there are things that wouldn't happen without a "conscience" present.

In mobbing, I could see how the developers look at me and clean up the code, or just test one more thing before calling it done.

It's not what I do. It's what gets done when I'm around. And in particular, it's not about what I can do now, it's about what I can do with people now and what I can grow into.

Amplifying people's voices

A lot of people, not just testers, feel they are not heard. Just like my messages get through best with other people, I can return the favor and amplify their voices.

I can talk to the managers about how it feels to a developer with a great idea to be dismissed, until I repeat the message. Through the feelings discussion, I've had managers pay special attention to people with less power in their communication that I seem to find.

We're stronger together, I find. We have great ideas together. It's not a competition. It's a collaboration to find the diverse experiments to give chances to perspectives that make only sense in retrospect. Emergence is the key. Not everything can be rationalized before.