Here’s another in a series about transitioning from being a QA to becoming a delivery lead. The hope is that people who are considering becoming a delivery lead use these posts to make a more informed choice – by identifying the skills required to make the transition, and highlighting the similarities in the two roles.

Today I am interviewing Karunakar Thedla​.

“I always tried not to constrain myself to my role and responsibilities. I tried to contribute beyond my role.” Karunakar Thedla​ 

What inspired you to make the move from a QA to a delivery lead?

I spent a major part of my professional life working as a QA. I wore multiple hats as QA, BA and iteration manager, always working closely with my team members and project stakeholders. Working for the betterment of the project/process/product was always at the forefront of everything I did. Despite that, I always looked for additional challenges and stepped up to help the team and business owners in any shape or form. Then I realised that there is only so much I could do on top of my day job, and the drive to have a much bigger influence made me switch to the delivery lead path. It gave me immense pleasure to use all my technical skills to contribute to every discipline in the software engineering process.

What are the key skills you have gained as a QA that have helped you as a delivery lead?

As a QA, I had a good understanding of the end-to-end development process along with a deeper technical knowledge of software engineering practices. I gained this by working closely with various disciplines e.g. architects, developers, UX/design, user research, and product/business owners. This helped me a lot as a delivery lead and the benefits are many. It helped me plan the project delivery better and achieve a shorter time to market whilst focusing on user needs and business goals.

I was also able to challenge and help development teams where necessary. I once worked with a third-party supplier development team who were building APIs for the client team. To our surprise, a simple API call was taking a few seconds to return data. They said they did everything they could but were unable to improve the performance and blamed the volume of the data. I asked them to check if the indices were added to MongoDB. This simple suggestion brought the response times down to a few milliseconds. I didn’t have to be an excellent developer but was able to understand the problem and help!

The technical knowledge also enabled me to help the business better understand the challenges faced by the development team and the complexities involved in delivering software. This is a particularly important skill to have when dealing with demanding clients who have set project targets.

What do you see as the major differences between the two roles?

I think that both roles have an overlapping wish list, i.e., customer satisfaction, quality of product, and better ways of working. However, I need to understand and respect what is expected of my role. For example, the QA in me wants an enhancement to a feature which adds a better user experience and might seem simple to build. But the delivery lead in me needs to manage expectations in terms of timelines so might have to be strict with scope. So, I try to remind myself of the role I play and make the right decisions. At the end of the day, making the client and users happy is key to whatever role I play!

Any advice for prospective delivery leads out there?

I always tried not to constrain myself to my role and responsibilities. I tried to contribute beyond my role. As a QA, I created user stories, wrote production code, set up CI pipelines, ran workshops, and held show and tells. I made a sincere effort to pair with my delivery leads, and along the way, I learned a lot. This helped me to understand the ups and downs associated with every role and gave me a greater insight into different aspects of project delivery. I would say this is a great way to transition to any role.

Do you have any regrets about making the move?

I sometimes miss being hands-on. I miss the joy of testing a complex feature and finding that impossible-to-discover bug, but I compensate by trying to be hands-on wherever possible, be it pairing with a developer to write production code, or analysing a story for a BA. However, the fact that I have a much larger influence on everything now keeps me going!