Sometimes you are wrong

I quite often get asked the same type of question in the Q&A sessions at the end of my talks:

"How can I convince my manager that we should be doing test automation?"

"My developer used to be a tester, how can I convince them that my test approach is right?"

"How can I convince my team to allow more time for testing?"

What each of these boils down to is persuasion. How can I persuade someone else to adopt my viewpoint? How can I turn them from a hindrance to a helper? How can I make them see the light?

I think there's value in learning how to construct a persuasive argument. A tool like SPIN selling can help you structure what you're saying, to stop you from jumping straight into solutions or getting mired in explaining problems repetitively.

I think there's value in learning to be mindful of how you're presenting yourself. Being conscious of your tone, body language, eye contact etc. can help you improve how you convey your message. I occasionally make use of a self-assessment worksheet to reflect on conversations that haven't been successful and identify opportunities to improve my delivery:

I think there's value in learning some basic influence techniques: the rule of reciprocation, reject and retreat, social proof, commitment and consistency, etc. [ref] These strategies can help you to position your argument in the best possible environment for success.

But there's another side to persuasion that I think testers don't talk about enough.

Sometimes you are wrong.

If you continually focus on how you can convince another person of your viewpoint, then you might have become blind to that possibility. I'm sure you'll agree that obstinate people are frustrating to work with. Have you become one of them?

Before you ask for help on how to convince someone, consider how long you have been trying to persuade them without success. Is it starting to feel like a never-ending battle? Do you feel like you've presented your position in depth, but it has fallen on deaf ears?

Perhaps its time to stop asking questions about being persuasive. Instead, start asking how you can understand their viewpoint and accept their opinions. Turn the conversation around.

What might this person know that you don't? Are they active in a different layer of the organisation hierarchy that might give them visibility of information that you don't have? Do they come from a different background that might give them skills or perspective that you lack? What questions can you ask to help discover these differences?

Who else is part of making this decision? Perhaps the person who you are trying to persuade isn't the sole decision maker? If they are deciding individually, do you know who else is influencing them? Can you talk with a wider group of people to understand a broader range of perspectives on the matter?

Why is their solution the best? Step into their shoes and look just for the positive outcomes in what they are proposing. How does it address the current problems? What constructive implications does it have, both for your personally and in a wider scope? If you've been stuck in a persuasive argument, you've probably formed a habit of seeking out the holes in what they propose. Switch your mindset to focus on the benefits.

What have you got to lose? We can get bogged down in arguments that, in the greater scheme of things, are not that important. Ask yourself, if you were to accept the other person's position what would you lose? It may not be as great a loss as you imagine, particularly if they're offering to compromise.

Sometimes you are wrong.

Don't forget to question whether now is that time.

Writing a book

For a while now, I've thought about writing a book.

I've seen it as an intimidating endeavour. A blog post might take an hour or two, but a book is a long term commitment. I didn't think it would be impossible, but I wondered whether I had enough to say or whether it would be of value to others.

For a while now, I've really wished there was a book about testing in a DevOps environment.

My current organisation is starting this culture shift and the material available for testers is limited. I have formed opinions on how to approach testing in DevOps, based on my own experience and heavily influenced by following the experiences of others in the industry. I thought that I could coach my team toward my thinking, but I wished for a book. Something that looked official and had weight. Something that aligned to my views and expanded on them. Something written by an authoritative source.

The New Year rolled around and a friend of mine, Lisa, posted about New Year's Resolutions. Her resolutions were brave, humorous and shared openly on social media. "What about you?" she asked, which made me realise that I hadn't made any.

Lisa got me thinking, and as I thought I remembered how a former manager, Noel, used to challenge me to dream in bold goals. I thought that it was time for a bold New Years Resolution: "the thing that you don't really want to voice because there's a risk you won't achieve it".

I decided to write a book. I decided that if I wanted a book on testing in DevOps, then I should write it. I decided to make myself accountable by telling people that I was going to do this:

I'm writing a book: "A Practical Guide to #Testing in #DevOps". Of interest to you? Details at https://t.co/RIcJ2HaYOp #NewYearsResolution

— Katrina Clokie (@katrina_tester) January 3, 2017

And now it's happening.

I am still in the honeymoon phase of deciding to write a book, but so far it has been unexpectedly positive. People have been very supportive, both in my personal and professional life. I've worked out how to navigate LeanPub. My brain is cooperatively serving up plenty of material that I want to include, although occasionally at unhelpful hours of the day:

Deciding to write a book has opened a floodgate in my brain. Woke up at 6am thinking about Conway's Law. It's Saturday.

— Katrina Clokie (@katrina_tester) January 6, 2017

I'm less nervous about failure too. Will I have enough to say? As I start to write, I've realised that I'll stop once it is enough for me. Will it be valuable to others? If no one else, I hope it will be useful to my team, which is why I wanted a book.

I've also remembered that "if you want something to exist, you should create it". This is a mantra I've used in the past. I wished there was an a discussion-based testing community, so we made WeTest. I wished there was a quality testing magazine for New Zealand and Australia, so we made Testing Trapeze. I wished there was a book about testing in DevOps, so I'm writing one.

It's scary to make a bold goal, but its also rewarding. I've already learned a lot, in just a few days, and I'm excited to see what the rest of this adventure will be like.

Writing a book. That's my New Year's Resolution. What about you?