Back to resources

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

Leadership
Impact
Team Processes

7 September, 2021

Versha Pradhan
Versha Pradhan

Quality Assurance Director at Veeva Systems

Versha Pradhan, Quality Assurance Director at Veeva Systems, describes several instances when she was given a team and what she did as a leader who knew what the great looks like.

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.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

People Oriented vs Task Oriented

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?

Leadership
Kamal Raj Guptha R

Kamal Raj Guptha R

Engineering Manager at Jeavio

Myth Busting

10 December

Supporting principles on why being data led (not driven) helps with the story telling.

Alignment
Managing Expectations
Building A Team
Leadership
Collaboration
Productivity
Feedback
Psychological Safety
Stakeholders
Vikash Chhaganlal

Vikash Chhaganlal

Head of Engineering at Xero

The Not-So-Easy Guide on How to grow and develop an Amazing A-Team

5 December

Your Org Team may as well be a Sports team. Let's explore how this cohesive, multi-skilled team can be optimized for Great Group Playoff.

Alignment
Building A Team
Company Culture
Sharing The Vision
Embracing Failures
Team Processes
Jaroslav Pantsjoha

Jaroslav Pantsjoha

Google Cloud Practice lead at Contino

DevSecOps: Why, Benefits and Culture Shift

29 November

Why DevSecOps matter and what's really in it for you, the team and the organisation?

Innovation / Experiment
Building A Team
Leadership
Ownership
Stakeholders
Cross-Functional Collaboration
Vikash Chhaganlal

Vikash Chhaganlal

Head of Engineering at Xero

The Growth Mindset in Modern Product Engineering

28 November

The impact you can have with a Growth Mindset' and the factors involved in driving orchestrated change.

Building A Team
Leadership
Collaboration
Feedback
Ownership
Stakeholders
Vikash Chhaganlal

Vikash Chhaganlal

Head of Engineering at Xero