Lessons learned as a QA Lead in a startup
This article is the final part of a series about joining a startup as a QA Lead. You can also read the previous part about the first month as a QA Lead in a startup.
I’ve spent my first 30 days as a QA Lead in a startup and I want to share with you 5 important lessons that I’ve learned so far.
Let’s start.
Lesson #1: Start over
This is the first lesson and, in my opinion, the most important one.
When I joined the startup I’m currently working for, I was biased. I thought that whatever worked in my previous workplace, would work well in this one, too. Consciously or not, I started suggesting improvements to processes and tools without having the full context of why they had been implemented that way in the first place. My intention was good, but my approach was wrong.
And you know what? I wasn’t alone. Whenever I talked to people joining the company after me, I heard similar suggestions.
It turns out that when we come to a new place, we see things working differently. And we start to wonder. It’s our curiosity kicking in — and there’s nothing wrong with that. Not until we start making suggestions, which most of the time turn out to be irrelevant.
The thing is, there are no two the same workplaces in terms of product, technology, engineering, people or culture. Given that, there are no two identical processes for any of these. When you change your job, you change the environment. Along with that, you should change your perception, too. You literally start over, so there’s no point to drag the old baggage with you.
Now, going back to my story. What have I learned?
I understood there’s no point to stubbornly convince myself and others that we should do things the same way as in the previous companies I worked for. Simply because it doesn’t apply here.
I made this mistake twice. But since I’m writing this, I hope I’ve finally learned.
Dropping the notion of the best practices taken from any previous work is the best practice I have now.
So if there’s something that I want you to remember from this lesson, it’s this:
- Forget the way things worked before — it’s different now.
- Drop your beliefs — they may not apply now.
- Reinvent your approach — by observing and adapting your knowledge to the current environment.
Lesson #2: Take ownership
At the beginning of my software testing career, I worked for a big corporation. My job was to execute semi-automated tests and manually verify their results. It was a fairly independent role, but I was a part of a bigger QA team, where my manager would take care of any work allocation. I was still a junior and little did I know about the importance of taking ownership.
Then I joined the first startup in my career. During the first month, I learned how crucial it is.
At first, I was quiet and reserved. I tried not to stand out, because that’s how it worked well in the previous job, so why change it? (As you can guess, I didn’t know yet that I needed to start over). But something was different there. I’ve noticed that everyone was coming up with ideas and taking up tasks proactively, without anyone’s suggestion or delegation. It was more about being proactive and responsible. It was taking ownership.
Once I noticed how it worked, I started doing the same. The result? Respect from the team and recognition from the team leader. That was the moment I realised that taking ownership instead of waiting for being assigned a task was the right thing to do. In fact, that was the foundation of my future growth.
Since then, not only I could work on things that I was interested in, but I could also add real value to the team. They could trust me.
How did it relate to my current QA Lead role? It was exactly the same. With the difference, that this time I knew exactly what I had to do. I realised that joining a new company is the biggest opportunity to show my approach, introduce my way of thinking and start doing things my way — before anyone even asked.
So remember, the first thing to take is to take ownership — and do it proactively.
Lesson #3: Ask for help
This is the lesson I can’t learn enough. I’ve been reminded of this in all workplaces — every time I postponed or refused to ask for help.
I can tell you exactly how many times asking a question or two speeded up solving my problem by hours or even days. And not asking — slowed it down and caused delays. Every single time.
I thought I had to build a testing framework alone. I thought I had to automate all tests by myself. I thought that only I could perform acceptance testing on a feature. Wrong. Wrong. Wrong! With this mindset, I wasn’t accelerating the progress — I was holding it back.
It’s strange — we prefer to close ourselves in an invisible box and fight with our problems alone instead of doing a little effort to ask someone for help.
We think that asking for help is humiliating. Wrong. Asking for help is liberating. It’s unlocking your work. It’s exposing more possibilities of coming to a great solution. It’s saving time of execution. It’s opening the path for delegation. Asking for help enhances all qualities of leadership.
If you’re in a leadership role and you don’t ask for help — you’re not really a leader. You’re a bottleneck — you think you know it all and you can do better than everyone else but in fact, you just slow everything down.
Don’t be this kind of leader. Ask for help.
Lesson #4: Use data
One of the lessons that I’ve learned early in my career but I’m still reminded of it today.
Blame me, but I used to base some of my decisions solely on my own opinion and gut feeling instead of backing them with proper research. I was lucky enough not to mess things up too much, so I’ve learned this lesson the soft way.
So I surely remembered it now when becoming a QA Lead. This time I’ve done it properly. Let me tell you how.
When I started at my current job, one of the first tasks I recognised I had to do was automating UI tests for buying a subscription on the website. Remember, it was days after I joined and had little context of what’s going on — but I knew I had to act.
Did I use the tools I used before? No. Did I only test on Chrome because everyone uses it? No. First thing I did was taking a look at usage data. I looked up for the most used browsers among our website users.
What did turn out? Over 50% of visitors used mobile Safari. Could the framework that I was already familiar with test Safari? No, it couldn’t.
So I’ve chosen another testing framework that was unknown to me at the time. I based this decision purely on real usage — not on any of the best practices in my previous workplace. Hadn’t I looked at data first, I’d end up wasting a lot of time doing the wrong thing –— and probably putting the business at risk.
You might have seen many of the bullet-pointed lists of “the best testing tools you should use” that say you to always use Selenium because everyone does it. They’re wrong. Don’t test according to someone’s else best practices — use your data. Do you remember lesson #1? Whatever worked for them, may not work for you at all. Forget it and start over. There is only one valid approach:
Test basing on data collected from users of your product.
Regarding the bullet-points, here are the only ones you need:
- Don’t guesstimate — ask the users.
- Don’t make decisions based on opinions — use data.
Lesson #5: Mind your well-being
This lesson is about not getting ill. And I’m not kidding!
There’s a short story behind it. A colleague of mine had become a team leader 6 months before I did. It was his first leadership position and no wonder he was stressed about it.
After a few weeks, he told me this: “Listen, I haven’t been ill for ages but 2 weeks in this role and I caught a proper cold. I don’t know what happened, but all of a sudden I couldn’t get up from bed for the whole week. Can you imagine?”.
I couldn’t. At least until the third week into my QA Lead role when I caught a cold, too.
So I came back to him and we discussed this further. The only sane conclusion we could come up with was the correlation of taking over a more responsible position and the stress that it brings.
The lesson learned here is to be more mindful of your well-being, especially during the first month. Listen to the signals coming from your body and your mind. If you feel like you have enough — just say “It’s enough for today.” and go home. Try to find ways to relax, more than you usually do. Find more time to take care of yourself, even though you think you have to focus on some more important things. You won’t be able to do any of them once you get ill.
Apply what that my friends repeatedly tell me: “Work hard. Rest hard. But never too hard.”.
Last but not least, if you’re looking for medical supplementation, forget carrots and vitamin C. It turns out that zinc is more effective if taken as soon as you feel the first symptoms of a cold. Since I’ve started practising this, I feel that zinc saved me several times.
So here we are with 5 lessons learned as a QA Lead in a startup:
- The best way to start is to start over.
- The first thing to take is to take ownership.
- The good way to ask is to ask for help.
- The wise thing to use is to use data.
- The important thing to mind is to mind your well-being.
With this article, the series of joining a startup as a QA Lead comes to an end.
If you enjoyed reading it so far, please spread the word and share it with your friends or on social media. I appreciate every share.
Additionally, if you want to be notified when a new article comes out, subscribe to the newsletter below and follow the blog on Twitter.
Until next time!
Dawid Dylowicz
