Three lessons after three months of quality engineering

Three months ago I started a new job as a quality engineer, supporting two teams. So far it’s been an interesting challenge. The two teams were formed only a few months before I joined, although some team members had been working for the company before that. Each team has their own product manager. We also have an engineering manager, but he joined only two weeks before I did. And then I was added to the mix, with a job description that didn’t give a lot more guidance than: support the team in things related to testing and quality.

So my first task in my new job was figuring out what my job was. Or rather, figure out what concrete things I could do that fit that job description. This was not made easier by the fact that we’re a fully remote company. Not being in the same space throughout the day does make things harder when you’re trying to find your place. Reflecting on the past three months made me realize there are three things that are really important: visibility, connections, and patience.

Visibility

The first lesson is visibility. When your work does not come down to “perform these steps in the process”, it’s easy to become a bit invisible. Not that your colleagues forget about you, but you’re not top of mind either as they go about their jobs. Especially if you’re working remotely, because it’s not as if people see you sitting behind your desk as a reminder that you joined.

Showing that you’re there

So the first part of visibility is literally that: showing that you’re there. Join all the meetings. Have your camera on. Say something or ask a question. Ask someone for more information or resources after the meeting. Similarly, be active on Slack (or Teams or …), even if it’s just an emoji reaction to what someone said.

I’ve also started an experiment: writing a weekly internal blog. The inspiration came from Giles Turnbull‘s “The agile comms handbook” and its idea of “working in the open”. Every Friday I take 30 minutes to write three paragraphs about my past week. It’s still an experiment-in-progress, but it’s been successful enough after six posts that I decided to stick with it. At some point I should probably dedicate a full post to this experiment.

(edit 3 September 2023) I’ve now written that blog post: “My seven-month experiment of sharing weekly notes at work”.

Showing what you can do

The second part of visibility is showing what it is that you can do. Quality engineering is a very broad discipline. It’s also a young discipline. Few people have experience working with quality engineers.

So I was faced with two questions:

1. What is it that quality engineers do?
2. What is it that you can do?

The best way to show what you can do, is by doing things. That’s easier said than done, though, when you have to answer the two big questions above. Doing lots of small things is key here. One place to start is in meetings and conversations. Actively participating in those not only confirms you are there, it also lets you demonstrate your expertise through what you say or ask.

For example, in a conversation about API design I brought up the differences between RESTful APIs and RPC APIs. Hopefully that made my colleagues realize I know a thing or two about API design. Similarly, when investigating a support ticket, I asked a developer if I could talk them through what I had found so far, because I was completely stuck. At some point in my story I said “So I looked through the code, and …”, which made the developer go “Oh, You looked at the code?” Hopefully that was enough for this developer to discover that’s something I can do.

And if not, that’s fine. The point is not to make a great display of one of your skills that people will remember forever. The point is to consistently show in small ways where and how you can provide value.

Connections

The second lesson is connections. Working remotely means that all communication gets that little extra friction. You can clearly notice it during meetings, for example when two people start talking at the same time and they have to figure out who goes first. It’s less noticeable, but a bigger issue, when it comes to small and casual interactions. There are a lot fewer opportunities to have those than if you’re sharing an office. So you need to be more intentional about them, which can feel awkward.

It’s definitely something I personally struggle with, because even at an office I’m not the greatest at those casual conversations. Sometimes it comes naturally, often enough it takes me active effort. What I find a lot easier is to connect with colleagues through doing work together or through having conversations about the work we’re doing. Unfortunately, if you’re still figuring out how you can contribute to the work, it’s not that easy.

There are two things I’ve been doing to build connections. The first thing is to schedule some coffee chats. When I started, I had an introduction chat with everyone in the two teams. Since then, it’s the work that has been determining who I speak with and when. So I realized it was time to change that.

A second thing is that I’ve been actively making conversation as we are waiting for a standup or other meeting to start¹. Even though it takes me some energy because it doesn’t come that naturally to me, I feel it’s a lot better than what would happen otherwise: people waiting in silence and/or doing something else.

Finally, I should not forget to mention connecting with my fellow quality engineers. In a sense that’s been easier because of the “one of us”-effect. What also helps is that we have a Slack channel and an informal catch-up every other week.

Patience

The third lesson is patience. I have very high expectations of myself. With less than two months in, I was asking myself: am I doing enough? Shouldn’t I be having a bigger impact already? Part of me knew those expectations were unrealistic. And luckily some colleagues said I was doing fine. Yet that doesn’t make these feelings go away completely.

So I have to remind myself to be patient. That my main focus might be on figuring out what my job is, but that in the meantime lots of other things are happening in the company as well. That yes, I need to be moving forward, but also that these things take time. I need to be patient with myself and with others.

Reflection

What I find interesting about these three lessons is that none of them are directly related to quality engineering or software development as such. Rather, they’re about entering a situation and figuring out how you, with your specific skills and knowledge, can add value.

You could say that’s a problem, typical of roles that lack very clear expectations. I’d like to turn that around, though. I think that things get a lot better, when people can let their job description fade into the background and instead focus on where they can bring value.

This post was also published in the January ‘23 issue of Tea-time with Testers.