Head of QA: Year One
Recipe for dealing with crises as a team leader.
Hi, Gleb here.
During 7 years in QA I worked as:
– a QA engineer in a startup
– a test lead in an agency and in a corporation
– and just recently a year passed since I started working as Head of QA at Mayflower.
The difference is not just in the title itself but also in the number of people I am responsible for. Just a few years ago, I managed a team of 2 QA engineers; now, there are almost 30 engineers in my department. I want to share my experience working as Head of QA in this article. It might be helpful for those interested in growing as a head of the department but still have some doubts about it.
Let’s talk fears
A tiny disclaimer on what I call “a fear” in the article: it’s not a panic attack, or trying to run away from a problem, but rather a doubt about my own expertise, my imposter syndrome — many people in IT live with this.
A year ago I was offered a Head of QA position. On the one hand, I was very happy about the new challenge, on the other hand, I was really anxious. At first it was hard to understand exactly what I am worried about and why. Later I realized that this is a set of fears and I know what it is constructed of.
1. People
In my previous company, I was a test lead for 7 engineers in separate teams. Seven is a great number. That is exactly how many elements one can hold in his head. Now, when I started out in Mayflower, I was given 15 engineers (a year passed, and now we are at around 30). I was worried about how I could find common ground with that amount of people, whether I should try doing this or not, what kind of issues I might face, and how I could deal with them.
2. Transition to a new role
At Mayflower Head of QA role is a minus one from C-level. Previously I haven’t really worked with these serious guys. So yeah, I was regularly having jitters at first. How to work with C-level? Are there any rules I am not aware of? Will I manage this?
3. Expertise
Another important point is making proper decisions for modifying QA processes. Will I be able to build a system to analyze issues, find solutions, integrate changes, and overview the results? Will I be suggesting valid things — if not, how will I know I am wrong?
This is what I started with in this new position. In the past year, many things have become more manageable, some fears vanished, but something turned out to be way harder than I thought. I will try to share these feelings with you, what I did to deal with them and what I understood. I hope everything I am going to share will help and support you on your way to being a manager of a department.
People
I never managed such a big team, of course, I was afraid of becoming a bad leader for these people. Unfortunately, there is no definition for “a bad leader” in Wikipedia, so I will show you exactly what I would not want to be for my team.
A bad leader
– cannot find a balance between his own responsibility for everything and trust for people: for example, he can think of making all decisions, not discussing, not delegating them to his engineers — or the other way around, he might hand over dealing with issues to his employees;
– cannot give support where this is important — or always overpraises his employees;
– can hardly be called a role model in decision-making and achieving goals;
– cannot deal with his own temper;
– cannot see the whole picture, cannot define what is good and bad, and is not a great visionary.
I had 1–1 meetings with each engineer to get to know each other and understand the work process from their point of view. An important detail: all 27 engineers work in groups of 2–3 in different product teams (where there is also a project manager, product manager, BA, developer, etc.). I needed to have a different approach for all these people, and I understood that our way to build proper relationships is through overcoming various crises:
– some specific person-related cases;
– resolving issues within QA department processes.
These crises do exist, and they never go away by themselves. Instead, it is me and my QAs taking responsibility, trying to understand the reasons for the problems through communication, open discussion with QA tech leads, through retrospective meetings within teams.
“Captain Obvious” recipe for dealing with crisis
- Analyze the issue and list the exact reasons for the issue.
- Make it transparent to everyone who did wrong — ideally, everybody understands his role, responsibility, and the outcome of the problem/situation/process.
- Talk through expectations (expected result in the expected timeframe) and write them down as a goal/action point after the team’s retrospective for a person/team.
- Agree on how you are going to sync on the issue status with a person/team.
- Monitor how the issue is handled.
- Once the deadline comes, ensure everything is done.
Many things happened: one person was able to apply a new awesome approach in testing, and we were really happy with the results. Another person was worried too much about things on the project, and I was trying to help him. That is how we got introduced to each other and built good relationships within the team.
At some point, I heard that the head of the department (QA or any other) could not make conclusions based on just dashboards, metrics, notifications system, and his leads’ feelings. Instead, he has to build a connection with each employee, listen to their issues, and never rely on consolidated feedback to be given to on a silver platter.
The more people in your team, the harder it is to overview everything — your 1–1 communication with an employee will most likely happen once in 4–5 months. You might want to see each other occasionally when it is really necessary.
Do not be afraid of your department size: you can always find a suitable approach to get enough communication in your team. It is important to have it: thus, you will be able to know what issues they are experiencing, how valuable their achievements are, and how the changes you introduce modify the product delivery process.
Back on the leadership topic: I am still in search of the perfect balance. Sometimes it is tough to draw the line between my relationship with an employee and the need to be demanding as a manager. It seems to get better with every case I get into, though emotionally, this is still not easy for me (nobody promised me this is going to be easy lol).
Transition to a new role
Besides the soft skills part of working with people, I was quite worried about working with C-level.
Here are a few examples of questions in my head:
- Maybe I know nothing, and they know everything, so their solutions will be smarter and way better?
- Will I be given the proper degree of freedom in decision making or will I need to work as I am told to?
- Can we build mutual understanding and trust in whatever I am planning to do? Can I sell my point of view on different issues?
During the past year, these questions come and go in my head — and they still do — but this is the reality of working with C-level.
Summing up the observations on this topic:
- Your management might happen to have better expertise in management decisions. Instead of self-doubts, it is way more useful to adopt that global mindset, the ability to see the whole picture based on recommendations, advice, and questions.
- The biggest challenge from the start is to understand it is your duty to define QA department plans for the future — where you are going and why.
- The reason you are hired is the company needs a good manager taking responsibility for the department, willing to find better solutions for existing problems. It is important to agree on the level of your freedom in decision-making. That is exactly why you need to be transparent with CTO, COO, etc. — even though this might be complicated at first. As soon as there are the first results of your work, the dialog between you and C-level gets easier and more comfortable.
Expertise
The third element I was worried about was my own professional expertise. I would like to split that topic into 2 things: optimizing processes and QA tools management.
Processes optimization
I was afraid that
- it will be hard to get a good overview of what is going on from my position — since I am not a part of any product team;
- I will not understand how to control the development of QA tools — what to suggest for which problems.
In the end, what have I done, and was I able to fix this? I built communication with all holders of the product delivery process. Got synced with the project manager lead and my QA tech leads (more on that role later), prepared a set of metrics and started its analysis (read my other article on Defect Density with a twist). I introduced the postmortem process for every critical bug — for now, this is handled by backend, frontend, and QA tech leads, but I am planning to move that process inside the product teams. Through critical issues analysis, we agree on what to fix right now and how to prevent us from similar issues in the future.
Any decision to change the delivery process goes through discussion with the project management team and QA team, taking into consideration their suggestions and thoughts. In order to understand the output of the introduced changes, you will track the metrics, subjective feelings of the teams, their team leads, and conversations on retrospective meetings. At some point, unnecessary processes vanish, and important ones become natural.
Managing QA tools
For me, everything related to writing autotests, automation framework development, checklists preparation, and so on is a topic of managing QA tools.
In my department structure, besides QA engineers, there are QA tech leads who are responsible for testing frameworks and infrastructure. My interest in automation is in the field of processes and numbers:
- Do we have enough time for writing tests? What is the quality of our tests? If anyone’s skill in writing tests is not sufficient, how can we mentor and help?
- Is our framework good enough for our purposes?
- What tasks from our QA backlog should we do first? While working with the backlog, what are our expectations for the next 6–12 months?
- How time-consuming are our test runs? How many flaky tests do we have? How many can we have?
I collect a subset of metrics, our expectations from infrastructure and frameworks, and our limitations. The decision-making on what exactly to be changed in frameworks, monitoring of the quality of written tests, and help and development of the engineers are in the QA tech leads’ responsibility.
Everything else, from test devices, test applications, and testing artifacts, is discussed with QA tech leads and the department.
The way you are going to grow your department is connected to its structure and goal-setting approach. For example, if there is someone who has some experience in load testing — he might do MVP to get the proof of concept — that person can become an expert on it. There is the person responsible for driving a new technical direction instead of everyone in the department. Later that engineer can look for other padawans, mentor and guide them, sharing his goals with them.
As a head of the department, you will be making license requests — if there is any budget monitoring in your company, you will have to provide explanations for exactly that number of users, that license type, and that license term. That basically means the responsibility for acquiring new software/hardware is solely yours.
Conclusion
While writing this article, I am also trying to summarize everything that happened during the past year and see how I managed that new role.
The head of the department role is not an easy one, and you are never going to be prepared for it. Some interesting observations: it might be pretty hard for you to explain your duties to your own engineers since your responsibilities area is so wide, and you cannot list the exact tasks you do on a day-to-day basis. You need to accept some level of uncertainty. You have to become sort of a lighthouse for your department, showing why we are here, why we have that testing approach, and where we should come in the next few years.
If you are thinking about becoming lead/head at some point in your career, I strongly recommend you look for a mentor — especially at the start. This will help you focus on the problems, find solutions quicker, and get good support.
Good luck!
P.S. As usual, kudos to Rita Kind-Envy for editing!
