Scaling engineering teams isn’t a process built on smooth sailing — but it is a necessary one.
Technological demands, new product rollouts and growing user bases all impact a team’s structure and workflow, and it can be easy for engineers to become overwhelmed as they wear yet another hat within their role. But with proper preparation, the expansion of a small, tight-knit group into a tiered engineering team can become a company’s blessing of success rather than a kiss of demise.
For instance, when Daria Mehra first accepted her role as senior director of quality engineering at Domino Data Lab, she recalls that their quality engineering (QE) function only had one dedicated engineer. In order to properly support the organization’s developers, she realized that increasing the QE headcount was essential to hitting future performance targets, despite any growing pains that could arise.
“Establishing a close relationship with our talent team was key to successful team growth,” she said. “With their support, we scaled from the initial one engineer to a group of 30 — including four managers.”
Mehra isn’t alone in her strategy. Forging collaborative bonds with recruitment teams has also been an essential component for leaders at healthtech organization GRAIL and synthetic data company Tonic.ai to not only match potential candidates to value-driven mission statements, but also establish more cohesive methods of internal communication.
Built In San Francisco sat down with Mehra, Senior Director of Software Engineering Milan Karangutkar and Engineering Manager Emily Ritter to discover how their teams overcame scaling challenges with ease and the ambitious projects they’ve been able to tackle as teams have developed.
Tell us about your engineering team and your role on it. Why did it need to be expanded so quickly?
When I joined Domino Data Lab nearly two years ago, our quality engineering function had a single dedicated quality engineer (QE). While we believe that quality is a shared goal and each engineering team owns the quality of its services, it was clear that the function needed to scale up to properly support developers with testing processes and tools.
Our model is to embed a quality engineer in each feature development “pod,” therefore requiring that QE headcount grows proportionately to developers. In addition, our test automation goals called for a centralized automation QE team to maintain and improve testing frameworks — and growing scalability and performance targets of Domino’s customers brought about a need for a focused scale QE team.
As the organization leader heading up QE teams as well as release management and documentation — which we find to have great alignment with quality — I faced the task of growing the organization very rapidly. With the support of our stellar recruiting team, we scaled from the initial one engineer to a group of 30, including four managers.
What was the process of scaling like and how long did it take? Were there any hiccups or “aha moments” to share?
Scaling the QE organization for me had the added challenge of defining process and structure along the way, since this was effectively a new function for the company. The initial steps included establishing team values, communication habits, roadmapping exercises, headcount planning, defining role requirements and setting up our interview process. Establishing a close relationship with our talent team was key to successful team growth, and we spent multiple iterations to calibrate the engineering profiles we were looking for since hiring QEs was a new adventure for the company.
In the first year, I was very hands-on in a player and coach role with a small team of individual contributors reporting to me. Upon realization that business needs had us looking at a step-function growth soon, I set about grooming future managers on the team — fortunately, there were two leads who were capable and willing to step on the manager path. These new managers then drove the hiring efforts for their teams.
In the second year of rapid growth, the talent team was really stretched, so I took advantage of the self-serve options they provided and did a fair share of sourcing through recruiting platforms.
While we believe that quality is a shared goal, it was clear that the QE function needed to scale up to properly support developers.”
What’s the most exciting project your engineering team will be taking on in the next few months?
We aim to radically shorten the feedback cycle on code quality for our developers through test automation, and are rolling out a new end-to-end automation framework developed in-house. This framework — we call it “cucu” — will unify our test cases, ensure reliable signal from the tests, and will natively fit into a developer workflow and CI/CD.
The QE team is excited to bring testing closer to our devs, and shorten our release qualification cycles through automation. As part of this effort, we are taking on the biggest unsolved problem in quality engineering: how to track test coverage of product requirements across different levels of automated and manual testing. Our team thinks that we have an idea for how to get this right, so come join us in solving this puzzle and help us test the Domino MLOps platform.
Tell us about your engineering team and your role on it. Why did it need to be expanded so quickly?
Our team focuses on all software development activities related to commercial initiatives of GRAIL’s Galleri® test. The team focuses on enabling Galleri® test requests and ordering via different channels such as EHR/EMR, Provider Portal, Patient Portal and more. I lead the software engineering team for all commercial activities.
GRAIL launched the Galleri® test commercially in Q2 of 2021, and it has grown with customers as well as channel enablement. As part of the growth, we had to scale as well as build new features to meet customer demands.
What was the process of scaling like and how long did it take? Were there any hiccups or “aha moments” to share?
The team worked very closely with the GRAIL recruitment team as well as the team’s network to scale from the resources point of view. As part of the hiring process, we focused on team members who were aligned with GRAIL’s mission and our product development to meet market demands, customer-centric, and interested in articulating growth opportunities for candidates in the short and long term. We grew at a fast pace and had to reorganize the team structure to meet the scaling demands, help in the decision making process, and reduce or minimize duplication of work.
In regards to the process, we defined the development process including peer reviews, testing strategies and more. This allowed individual contributors to better self-manage in these areas. We also encouraged healthy peer feedback through monthly meetings with all team members as a group and on an individual basis. We invested in over-communication within and between teams.
We defined the development process including peer reviews, testing strategies and more — this allowed individual contributors to better self-manage.”
What’s the most exciting project your engineering team will be taking on in the next few months?
This year is all about growth and expansion.
Tell us about your engineering team and your role on it. Why did it need to be expanded so quickly?
I think our engineering team includes some of the best the industry has to offer. In my role, I’m currently focusing on how to integrate NoSQL databases into our larger product offering.
Expanding our team was critical. When I first joined Tonic, we focused on scaling our tools through our own vision. As we gained more and more customers, our product needed specific features built out to meet their needs.
This is why we focus competitively on recruiting. We want our engineers to have the bandwidth to both support customer needs and also work on more experiential projects. We are taking our tools that are good and making them great. We’re continuing to grow, expanding our engineering team, and working on exciting projects every day.
What was the process of scaling like and how long did it take? Were there any hiccups or “aha moments” to share?
Scaling is one of the key philosophies and goals we have. I don’t see us slowing down anytime soon.
My favorite “aha moment” came with the expansion of our design and product management teams. We developed better designs and frameworks, and we were better able to understand our customers through our teams. It made me realize how important it is to get non-developers in a startup as early as possible.
We want our engineers to have the bandwidth to both support customer needs and also work on more experiential projects.”
What’s the most exciting project your engineering team will be taking on in the next few months?
We have a lot of really interesting things we’re taking on. The most exciting project for me is a new deployment strategy we are launching soon. I’m really excited because there are new technical challenges I have to face, which always creates new learning opportunities. Through this new launch, we will reach even more customers, allowing us to scale exponentially.
