Managing a QA Team for the First Time
28 April, 2021

Engineering Manager at Postman
Problem
For quite some time, we were using an offshore QA team based in India. A year ago, we decided to terminate the contract and bring all our QA efforts in-house. Though QA and Development were kept separate in the past, it was decided that an in-house QA effort will report to Development. The rationale behind the new organizational structure was that since QA worked closely with Development, it should report to the same manager.
However, as a manager, I had scarce knowledge of QA; I had never been a QA engineer and had no knowledge of tools and processes they were using. Furthermore, since we were not working anymore with contractors, I had to start hiring for QA roles. I had no idea what to look for in candidates and, once hired, how to onboard them.
Actions taken
First off, I deep-dived into the code and explored the existing automation. I was not happy with what I found. A lot of failed test cases were not cleaned up, many irrelevant features were still being tested, the whole process was very inefficient, difficult to maintain, and unscalable. Since that was the only automation framework we had, I had to fix it first before advocating for building an improved framework.
I started by removing some tests that were no longer relevant and fixing those that were meaningful. Upon deep-diving into the code, I encountered an unfamiliar QA framework and programming languages I never worked with before. Surprisingly I felt confident because I am a natural hacker. I am not the most skillful person when it comes to building things from scratch, but I am an outstanding hacker.
It didn’t take me long to familiarize myself with QA in general and be able to interview incoming candidates and assess their skills. In the end, we hired three senior QA engineers, and I relied on their expertise to further improve my knowledge of QA.
With their feedback, I felt confident that we should get rid of the low-quality QA framework developed by the contractors. I wanted us to build a new scalable and reusable framework. I encouraged our recently hired senior engineers to architect the new framework, and I was overseeing and managing the process from a high-level perspective. Finally, we managed to migrate from the old framework to the new one successfully.
Lessons learned
- When you are switching from one domain to the other, don’t be hesitant to deep-dive into a new subject matter. Try to familiarize yourself as much as you can with the new domain through reading, talking to experts, and of course, rolling up your sleeves.
- Building a team from scratch is particularly taxing when unfamiliar with tools or technology. You need to acquire at least some basic understanding of tools and technology to be able to hire people who will later bear the brunt of executing the work.
Discover Plato
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
Related stories
20 January
As a Lead or Manager, one could naturally incline more towards being either people oriented or task oriented. Which is better? Do you know which side you lean more towards?

Kamal Raj Guptha R
Engineering Manager at Jeavio
10 December
Supporting principles on why being data led (not driven) helps with the story telling.
Vikash Chhaganlal
Head of Engineering at Xero
29 November
Why DevSecOps matter and what's really in it for you, the team and the organisation?
Vikash Chhaganlal
Head of Engineering at Xero
28 November
The impact you can have with a Growth Mindset' and the factors involved in driving orchestrated change.
Vikash Chhaganlal
Head of Engineering at Xero
14 October
There are nine specific building blocks and functional areas every org/company need to work to launch the product and provide services to customers. How effectively founders tackle them determine the destiny of the company.

Praveen Cheruvu
Senior Software Engineering Manager at Anaplan