Knowing When To Let Go... And Who To Let Go Of

In my last post I talked about knowing when it was time for me to let go of my old job and old company in search of better things for myself and my career. This time I'm going to change it around a little bit, how do you know when you need to let go of someone from your team, for the good of your team? 

Recently I saw our QA team be cut in half due to layoffs. Although I wasn't directly involved with the decisions that were made at that point in time I did need to mentally come to terms with what had happened and come to terms with the fact that I played a part in a small way. 

When I started at my new company I had been told that the team had some growing to do and that there would be challenges that I would be asked to help find solutions for. Fortunately, a week before I started someone else also started, a Senior Test Strategist who is one of the most incredible testers I've ever had the pleasure of knowing. So the good news was that I wasn't going to be going into this alone. The VP had identified some slow downs and there were strategic hires made to try and improve the team. Over the course of about 6 weeks our Test Strategist (with me providing input and feedback) identified a few key areas of concern and some ways we could start to work on those. I'll talk more about what changed in a future post about how we managed to move to a highly functional test team. 

We implemented those changes in process. We started to see some really positive changes. But we also started to see some people slip behind. We started to see some gaps that we hadn't before, gaps not in the process but in the actions of individuals. These people were really skilled, but not everyone is always cut out for, or will enjoy, being part of an exploratory test team. It's an entirely different world that traditional waterfall QA where things are thrown over the wall, you execute on predetermined test cases and rely on regression. That in and of itself was a lesson for me. 

My brain works well with exploratory testing. It's what I love to do and where my greatest skill set lies. In my mind, because I am so young and just starting out my career, it was eye opening for me to see how people responded to the changes from a waterfall model of QA, and really of team process, into an exploratory test strategy. It was also a reminder that not everyone is, wants to be, or can be an exploratory tester. And that is ok.

However, with where our company was at exploratory testing is what we needed. It was a step we needed to take in order to be releasing and deploying software as much as we were. We were releasing bi-weekly at this point and having 3 days worth of manual regression be done every 2 weeks was not an effective use of our time. We also needed to speed up the development process and that means getting testing involved early and often (it means everyone should be but that's another point). 

I was away for the month of December taking a long planned vacation. Before I had left I had been asked to and had been helping to coach some of the members of the QA team on best practices for the exploratory test strategy that had been laid out. I won't lie and say that it was going wonderfully. Obviously I could see that some people were struggling with it. I still had hope that they would catch the hang of it and we would be moving in the right direction soon. I came back in the beginning of January and even I was slightly shocked the day layoffs occurred and half of the test team was among them. 

I wasn't shocked because I thought it was unfair. I was simply shocked that it was that many people at once. We lost half of our QA team that day. It was not an easy decision on the part of anyone involved in that decision to make it. But in the end, it was the right call. 

So why am I so sure it was the right call? To be blunt, there is one pretty easy heuristic to measure that by: our quality is up. And that isn't just me saying that; we've been told so by customers, by our product team, by our designers. People are noticing a higher quality product lately even with a significantly reduced team. But that in no way means it was easy to do, or easy to accept.

In the days after the layoffs I found myself wondering a lot if there was more I could have done to help those people. But I've had to accept that there truly was not. I did the best I could to bring them up to speed on the new strategy. Could we have not changed the strategy and played more to their skill sets? Sure, but at what cost? Our team is significantly more efficient now, we have quality advocacy from the very beginning of projects, we have a higher quality product being produced. All of these factors play into our assuredness that this was the right decision. 

Which brings me to the main point: there may come a time when it is better for the company, and the individual, to let them go. I've already discussed why it was the right move for the company, but how can I say it was the right move for the people? Because the bottom line is that we were going to keep going down this path one way or another. We could see that the strategy was working. For people to have stayed in that environment when it wasn't playing to their skills, or wasn't the job that they wanted to be doing then we would have ended up with employees who were miserable. Who didn't enjoy coming into work every day. And I know that is easy to say from the standpoint of someone who stayed. But from being on the other side, from being miserable every day, I can say that in the end it is better to find somewhere that your skill set is utilized to it's full potential and where you're doing the work you enjoy. 

It is never easy to let someone go, but if it's what is best for the company and the individual then it is the right decision.