Tester’s Diary: Butting Heads

This is a guest post by Rachel Kibler.

I came to my current company nine months ago. My interview had gone really well; I liked my new boss, and the people seemed fun, smart and hard-working. Though I met most of the team during the interview, the product owner was absent.

I was right about the people — they care a lot about what they do and how they do it. My boss is also great. What I didn’t expect was how much conflict I would have with the product owner, whom we’ll call Clayton. I was faced with a colleague who disliked testers, disliked being questioned, and disliked me personally.

Clayton is an experienced product owner. He focuses on meaningful metrics, and he keeps the team focused on his priorities. He gets his way, but he listens to some people for input.

In my first retrospective, I asked that the team try to be more inclusive in their language and use a word other than “guys” when referring to the team or a group of mixed genders. No one said anything in support, and Clayton asked if I was “triggered” by the word.

In my second refinement, I asked to use some cards that had helped with refining epics and stories before. The team seemed to like them, and some good insights came out because of them. When I asked to use the cards again, Clayton emphasized how much he disliked them, as he felt the questions weren’t always relevant. The team followed his lead and abandoned them, and I found out later that he felt like I was overstepping my boundaries.

After that, I filed a bug about a typo, and, because the team stated it had a zero-defect policy, I put it at the top of the Kanban board. It was fixed immediately. Clayton had been off that day, and he was unhappy the next day when it showed up in our “done” list, wanting to know why we had bothered to fix it. It turns out the zero-defect policy meant zero defects filed unless the product owner considered them essential to fix. I ended up running every bug past Clayton after that.

I tried to get to know Clayton in a private conversation, asking him about his work background and his family. I should have picked up on the cue when he asked me no questions in return. I later found out that he felt like I was probing and getting too personal. If I had read Clayton’s body language better, I would have shut down the conversation as soon as I realized he was uncomfortable.

That was all in my first three weeks. It was rough. I knew I had damaged something, and I just hoped it wasn’t beyond repair. The people on my team who knew Clayton better suggested that I stay out of his way as much as possible for a bit, so I did. I spoke up in refinement (without the cards), I consulted Clayton about bugs, I was friendly with my colleagues. I thought things were getting better.

Modern Test Case Management Software for QA and Development Teams

They weren’t, apparently. After six months, Clayton still didn’t like me, seemingly at all. When I looked at the company’s terms and conditions and asked that a duplicate paragraph be removed, he felt like I was, once again, overstepping my boundaries.

I gave up. I felt like I couldn’t do anything more to make our relationship better without diminishing myself. I asked to move teams, and now I’m free.

I took a lot of lessons from things I did wrong, and I started off much better on this team. I’m almost to the point where I can make some waves, and no one has asked me or expected me to be less than a whole person.

Things I learned:

  1. Chill. There’s no need to make waves right at the beginning. It’s better to get a feel for the team before you try to change things.
  2. Communication is critical. Find out how people like to communicate and how much they like to communicate. If they want to be a part of every decision, and they have a right to be, you need to be respectful of that.
  3. Take people as they are. It’s important to get to know people and build trust with them, but knowing where they are to start with is just as important.

Things I wouldn’t change:

  1. Get to know people, with the caveat above.
  2. Be bold in introducing things I think will help the team — but maybe just wait a bit.
  3. I will not make myself small for anyone. I also won’t expect anyone to make themselves small for me.

All-in-one Test Automation Cross-Technology | Cross-Device | Cross-Platform

Rachel Kibler is a tester at 1-800 Contacts. She can be found on Twitter @racheljoi or on her website at racheljoi.com.

In This Article:

Sign up for our newsletter

Share this article

Other Blogs

Key Factors to Consider When Selecting the Right Test Case Management Tool
General, Software Quality, TestRail

Choosing the Right Test Case Management Tool: Key Factors

Understanding the need you have is often the first step in defining the method for managing test cases that will work for you and your team.

Understanding QA Roles and Responsibilities
Agile, General

Understanding QA Roles and Responsibilities

The software development process relies on collaboration among experts, each with defined roles. Understanding these roles is crucial for effective management and optimizing contributions throughout the software development life cycle (SDLC). QA roles, respons...
DevOps Testing Culture: Top 5 Mistakes to Avoid When Building Quality Throughout the SDLC
General, Business, Software Quality

DevOps Testing Culture: Top 5 Mistakes to Avoid When Building Quality Throughout the SDLC

Building QA into your SDLC is key to delivering quality. Here are the mistakes to avoid when building quality throughout the SDLC.