When it comes time to restructure an engineering team — and for any scaling company, that time will come — it’s best to lead with a people-first approach, VillageMD Director of Engineering Mario Urquizo said.
“The right structure aligns with both our company’s goals and the team’s career goals,” Urquizo said.
When reevaluating team structure at VillageMD, leadership took time to learn which engineers wanted to try a hand at leadership roles and which wanted to continue being high-performing individual contributors.
“In a growing company, it’s easy to give people those opportunities while staying true to our overall objectives,” Urquizo said. But change management only works if two key ingredients are present: communication and autonomy.
To avoid a handoff-heavy process during Discover Financial Services’ restructuring, Business Technology Director George Leedle said he composed pods of engineers who had expertise in complementary core competencies so that teams could own the full software development process.
“The sense of team ownership versus individual ownership was essential to the model’s success,” Leedle said.
Recently, Discover Financial Services shifted the way its engineering team was structured in an attempt to eliminate the number of handoffs necessary between colleagues. By removing the legacy developer and tester stereotypes, Discover was able to create an integrated team model that provided engineers access to key resources.
When did you know it was time to reevaluate the structure of your engineering team?
Over the course of a year, our software development organization had doubled in size and we expected more growth on the horizon. We didn’t feel like we were getting the delivery volume or speed we needed to satisfy growing business demands. So we decided to take a step back to look at our overall software delivery methodology.
Our Agile software delivery teams were structured with technical leads, developers and quality assurance testers. After completing development, they then handed work off to a team of integration testers, who handed work off to a team of performance testers, who finally handed work off to another team for production installs.
The model was fragmented and required coordination to move simple changes from inception to production. Even when teams did their best, we still fell short of business expectations.
The key concept was to form more autonomous, high-performing teams.’’
How did you determine the right structure for your team, knowing that team would see rapid growth in the coming months?
In order to prepare for future growth, we decided to redefine our software delivery model. The key concept was to form more autonomous, high-performing teams. We needed to create an integrated team model that provided engineers access to key resources. Even more critically, we needed a cultural shift with a focus on empowerment and accountability for the full software development process.
We removed the legacy developer and tester stereotypes, hiring and training full-stack developers to cover both areas. We composed teams of engineers who had expertise in other core competencies needed, including quality engineers, DevOps engineers, integration and site reliability. The restructuring positioned the teams to have all of the critical skills “shift left” in order to gain earlier access to the work and to plan and execute versus waiting for a handoff later in the process.
What steps did you take to try to ensure a smooth transition to the new team structure?
We obtained feedback on the new team operating model from key partners. We also decided to start small, piloting the changes with a group of teams to learn from those experiences before a larger rollout. This allowed us to refine the model and gave me greater confidence in its effectiveness before broadening.
We set the expectation that this model was a starting point in the spirit of continuous improvement. We planned to adjust the operating model as needed, which we have done over the past several months. Early socialization with leaders helped instill the key principles of the culture we wanted to develop, grounded in attributes like empowerment, autonomy and accountability.
Urquizo knew VillageMD engineering teams were overpopulated as soon as stand-ups didn’t require everyone in the room. Keeping business goals in mind, leadership split the department into squads that worked on data ingestion, platform reliability and interoperability, respectively.
When did you know it was time to reevaluate the structure of your engineering team?
At VillageMD, I have learned to never tie yourself into one way of doing things. We should always innovate. We recently split into squads within our interoperability team. I knew it was time to reevaluate the structure of the team when I noticed process bottlenecks, lack of clear ownership, unproductive meetings and our stand-up meetings became too big.
At VillageMD, I have learned to never tie yourself into one way of doing things.’’
How did you determine the right structure for your team, knowing that team would see rapid growth in the coming months?
The right structure aligns with both our company’s goals and the team’s career goals. Some engineers want to try a hand at leadership roles and some want to continue being high-performing individual contributors. In a growing company, it’s easy to give people those opportunities while staying true to our overall objectives.
In the end, we split into three squads working on common goals: data ingestion, platform reliability and interoperability.
What steps did you take to try to ensure a smooth transition to the new team structure?
Change management of software, processes, and more importantly, people is one of the most challenging things any company can face. Consistent and frequent communication is necessary for a smooth transition. We had time to think about the split and allowed our engineers to have a say in the vision of the reorganization before we shared the new team structure with others.
