Browse MAXWELL HEALTH

Big Learnings from our QA To Dev Transition

Posted on 03 August 2015

by James Hrisho - Information Architect

A critical challenge for engineering teams large and small is providing an environment where people can take on new roles and responsibilities. We recently faced this head on when a handful of people on our quality assurance team expressed an interest in moving to full-time development roles. While that transition wasn’t perfect, we had key learnings that will make future movement through our team more fluid and transparent.

Mentorship is critical

Once we established who was interested in moving from QA to development, we paired each person with a senior developer to act as a mentor. The mentor was tasked with finding what their QA mentee needed to learn to be a successful developer at Maxwell Health. With an advocate on their side, each QA person felt empowered and had someone to work with on their journey.

Everyone has their own baseline skill set and learns at their own pace

Our QA team has a diverse background— some have CS degrees, some come from development boot camps and a few are even self-taught. One concept may be a breeze for one mentee while another mentee may have never heard of it, while the opposite is true of another concept. The challenge was identifying where those gaps were and creating lesson plans and development tasks around them. Luckily, we had two great tools to solve these problems: pair programming and online learning. Pair programming with a more senior person gave the mentee an opportunity to see the process from ideation to the solution to released code. It provided a safe environment that could be a learning experience while also delivering features to our customers. Online learning sites like Codecademy and Pluralsight provided endless courses on development concepts. We utilized these tools for situations that didn’t fit neatly into pair programming.

It’s important to backfill your heavy hitters

Once you’ve headed down the path of the transition it becomes increasingly clear that you will need to backfill and train new QA specialists. As most engineering teams know, a great QA is a hard thing to find, so replacing several QA team members was a challenge. It meant interviewing and finding the right people. The rigor that you put into backfilling a role cannot take a backseat, no matter how quickly you want to move someone over to development. The same rigor applies to training those new QA team members you do end up hiring. In our case, the people moving to development have deep knowledge on a large set of projects and have a macro understanding of how everything interacts. They needed to document and do as much knowledge transfer as possible before they were ready to fully transition. The good news is that these people won’t be leaving the organization and chances are, they will still be in the same office space so they can help the new QA folks with questions post-transition.

Timeline and goals need to be established

A clear timeline for a transition is key. We tried to set goals and check-in points internally that we could use to get a sense of each member’s progress. Backfilling roles is the challenge here. Try to build this candidate search period and the training of that candidate into your timeline. For goals, we would suggest having a sheet of agreed upon skills that make up a junior developer at your organization. Some examples would include a working knowledge of the frameworks and libraries you’re currently working with, a set of design patterns and when to use them, and how to use source control. Having a clear finish line makes everyone involved feel like they are working towards an end goal.

Deep knowledge of the product is a great foundation for a new developer

By transitioning QA specialists to development, you are unlocking top talent. As I mentioned above, our QA team has deep knowledge of our product. In the case of Maxwell Health, that knowledge includes complex insurance strategies, how we integrate with our partners, our development and agile process, and a back catalogue of the edge cases that make administering employee benefits unique. Development concepts are far more concrete and there are established strategies to learn those techniques. By transitioning your most knowledgeable people to development, they are coming in with a head start on how your product operates – something a developer off the street simply won’t have. We benefitted from this almost immediately; our QA to development transitioners could identify where potential dependencies between components could occur. They felt confident adding even more complex insurance functionality because they know life insurance intimately and know where a new piece fits in the framework.

To see this transition firsthand is inspiring. It also shines light on other potential transitional moves your team members might be interested in making. Does that person want to move to product management? How about infrastructure? When a team is very small these moves can be easy and more fluid but, as roles are established and teams grow, the switch can be much more difficult. It is a team leader’s role to identify potential moves and to pay attention when someone’s skill set might have a big impact on another team.