Being Given a Team: What Does an Inspiring Leader Can Do

Problem

Leaders are given teams in all shapes and forms, and we are expected to turn them into successful and functioning units. I have experienced this multiple times, and I am proud to this day of how I managed to make them into a praiseworthy bunch.

When I joined my current company about three years ago, I started as a QA manager for a mobile team that was set up as a startup. This is a general rule we follow within our company: whenever we are launching a new product, we set up the team responsible for it in a startup mode. We will be given full autonomy to do a couple of releases before aligning with the rest of the company.

Now, not only was I new to the company, but the team was brand new, with developers and a PM being hired weeks before. As I was just given the team, I had to understand both company-wide processes and those specific to mobile teams as well as how I should balance autonomy and alignment. In short, I had to build the team, hire additional people, come up with processes and automation -- all that in six months since we were expected to deliver the product within that time.

Actions taken

Whenever I would be given a new team, I would spend the initial time learning. I would be meeting with different people across the company, reading the existing documentation thoroughly, and discussing processes with leaders of different teams. In the situation described above, I spent time meeting with other QA managers from different teams to familiarize myself with their processes and operations.

Then I started to draft the outline of our future processes; I laid out a plan for introducing new processes one by one, sketching the timelines of three months, six months, and a year. Once completed, I discussed the plan with the QA company-wide leader, asking for their feedback and upfront signaling potential deviations.

Next, I came up with the automation infrastructure, including writing the infrastructure for it. I was hands-on testing all the time because developers were already pushing out the code and had yet to hire someone to do it. I also had to make sure that all Scrum processes were in place because I had to make sure developers were doing their code reviews right.

The team I was given managed to complete our first product successfully. The date was slightly slipped, but it went out within the weeks of the planned date. The customer acceptance was great, which altogether established me to be someone who can take on a new team and do wonders.

As soon as we released the product, I was given another team -- the authentication team, which belonged to a separate area. When it was given to me, the team was in bad shape: the QA manager was resigning, the team mission was vague, and a developer manager was not happy with how QA was done. I walked in only to see a group of people without a clear understanding of what they should be doing and how.

It took me around four months to turn the team around. I had to understand how authentication worked and what the processes were, but what I learned from leading the mobile team helped a lot. It didn’t take me long to receive positive feedback, particularly from a development director who conveyed their commendation to my manager. That also gave my manager confidence that I was a person who could deliver. I was still new with the company, with less than a year under my belt. But it became evident that I could ramp up teams that needed some extra attention. Because of my previous success, I was given a team where a development manager was by default doubtful of what QA could do. Not surprisingly, I managed to change their mind and helped deliver a high-visibility project with great success.

What is the secret to my success? I can merge my solid technical skill set with my people skills. I can make that connection because I feel comfortable on both sides. I can understand end-to-end what a development manager and PM want, and I can communicate those nuances to my team members.

I also have a realistic approach to planning. I can do only this much given the resources and will be straightforward with expectations. I am always on a mission of providing better quality, given time constraints and limited resources. That means that I take full responsibility for adjusting the scope to fit what we have. I would change the scope by providing the best coverage that is needed by doing less, thus maximizing the outcome.

Lessons learned

• I like challenges. Given a new or ill-functional team is one of the greatest challenges for any manager. Overseeing their progress makes me fulfilled and accomplished as a leader.
• My main strength is that I can understand the technical side of a project, and I can communicate that accurately with people across different teams. I am also a people person, which is something that no one expects from such a strong hands-on engineer. Many people are approaching me, asking me to mentor them on people skills. I do genuinely care about people: where they want to be and how I can help them. This amalgam of different strong points made me not only successful but have me enjoy my job.
• If I have anything to offer, even a small piece of advice, then am I all for it. I like when I am needed and when my experience and expertise can help someone else. I also take part in the mentorship program in my company and use every opportunity to pass on my knowledge and skills.