What’s the most important factor when structuring an engineering team for rapid growth? Many tech companies would say communication.
Fostering open and transparent lines of communication ensures that when teams are stretched too thin, engineering leaders know why, where and when the problem is occurring. Johnnie Thurston, director of engineering at Arrive Logistics, said team feedback serves as the catalyst for reevaluating the effectiveness of existing structures.
“I can speak for all of the engineering leadership at Arrive in saying that our biggest indicator that it is time for a change is always our people,” Thurston said. “As leaders, we rarely have all the answers, and it is vital that we listen more than we speak.”
Communication is also key for successfully executing a restructuring. Employees are much more likely to accept change if they are given an opportunity to shape it through feedback. Roy Shamir, VP of engineering at LeanDNA, sought insight from his team when implementing a restructuring and credits it for helping create a smooth transition.
“One of the most critical steps in this process was to involve everyone when making the plans for these new teams,” Shamir said. “We started with collecting feedback and discussing career goals with each engineer and having substantial discussions with our product team.”
Thurston, Shamir, and Care.com CTO Ryan Safarian have all restructured engineering teams for growth and know how valuable communication is in pulling such a major move off. They recently sat down with us to share their experience and advice.
Care.com At a Glance
When did you know it was time to reevaluate the structure of your engineering team? What were the biggest indicators?
There is a constant evaluation of teams, process and efficiency, but in early 2020, shortly after the IAC acquisition of Care.com, we had one of the larger remodels of our company’s approach and technology. From a brand perspective, we wanted to reorganize our engineering team structure to better align with a more holistic and unified product focus. From an efficiency standpoint, we aimed toward a more fungible composition with a strict focus on building redundancy of domain expertise at every point in the stack.
Finally, from a technical standpoint, we needed an arrangement that could support the heavy tax of our re-platforming from legacy monolithic systems to macro and micro services. Shifts of this magnitude are only possible with the full consensus and support of business stakeholders.
The smaller team structures also help nurture our cultural imperatives of vulnerability, trust and debate.”
How did you determine the right structure for your team, knowing that team would see rapid growth in the coming months? And ultimately, how did you decide to structure your team?
Through application and study, we decided that a hub-and-spoke model with smaller delivery team distributions would work best for our business. This paradigm lends to the care and feeding of our legacy applications while limiting distractions to help accelerate our roadmaps and provides a hardened infrastructure for rapid growth.
By breaking out into smaller delivery teams — or spokes — consisting of four to seven developers, we allow ourselves to fail fast and mature faster. Smaller teams equate to shorter lines of communication, which results in less confusion and increased engagement. The smaller team structures also help nurture our cultural imperatives of vulnerability, trust and debate. It is much less intimidating to be vulnerable and transparent in front of four or five peers versus the weight of the entire engineering organization.
By developing our center of excellence, which serves as our hub, we can apply governance around code quality and standards to our systems, deploy the rich tooling and reusable design patterns necessary for a best-in-class platform, and empower established architects to positively influence and mold the next generation of brilliant engineers through practical real-world examples.
What steps did you take to ensure a smooth transition to the new team structure? How did your engineers influence the process?
In all honesty, we were right in the clutches of the pandemic when we rolled out the new team structure and it did not go as smoothly as I would have liked — at least in the beginning. Understanding the “why” along with proper change management are paramount in situations like these. Given the early rigors of the newly remote world, we were still defaulting to our “normal” level of communication. It was only weeks later that we recalibrated to an overly verbose and repetitive communication strategy.
We made sure to get the message, accurately, out to the tips anchored around the business value and opportunity unlocks of the new structure. We relied heavily on engineering leadership to reinforce the message and celebrate the effectiveness as early and as often as possible. We also encourage an open feedback loop to adjust and optimize for better results. As with anything in software development, iteration is fundamental to long-term success.
Arrive Logistics At a Glance
When did you know it was time to reevaluate the structure of your engineering team? What were the biggest indicators?
Steering a big ship is an adventure in patience, and every engineering organization has lofty goals counterbalanced by legacy software. At Arrive, we are fixated on building the next generation of our products, as well as the teams who will own them. That kind of massive growth requires that we carefully consider our goals and which team structures support those goals.
Steering a big ship is an adventure in patience, and every engineering organization has lofty goals counterbalanced by legacy software.”
How did you determine the right structure for your team, knowing that team would see rapid growth in the coming months? And ultimately, how did you decide to structure your team?
At Arrive, we have adopted the textbook agile pod mantra: Gather a group of talented engineers, designers and product managers and give them full ownership over a slice of our larger software goals. Our engineers are domain experts and we celebrate specialization and encourage our people to dive deep into their careers.
Anticipating organizational growth is challenging at the best of times, and as the pandemic continues to shift engineering best practices and organizational strategies around the globe, we are all relearning how to responsibly lead software teams, mentor engineers and maintain a culture that encourages innovation.
What steps did you take to ensure a smooth transition to the new team structure? How did your engineers influence the process?
Most leaders in software follow a similar North Star: “How do I build an engineering culture that becomes the envy of every engineer in town?” Our approach at Arrive is an exceedingly flat org chart. Give everyone a seat at the decision table, then be quiet and listen.
Our teams are the core unit of decision-making. All our values are centered around the team. That trust inspires our biases toward responsibility, independence and diversity. Our engineers don’t influence the process — they are the process.
LeanDNA At a Glance
When did you know it was time to reevaluate the structure of your engineering team? What were the biggest indicators?
Our business is steadily growing, and about a year ago our engineering leadership started to feel stretched. The key indicator for a restructure was the team workload and the need for delegation. Folks were overseeing too many things at the expense of individual accountability and progress, and we knew the growth we were experiencing wasn’t stalling anytime soon. It was the perfect opportunity to refocus and allocate resources across the engineering and product teams.
We needed clarity on how to continue scaling the team — including our engineering, product management, product design and quality assurance departments — to continue to build a world-class product for our customers.
Folks were overseeing too many things at the expense of individual accountability and progress, and we knew the growth we were experiencing wasn’t stalling anytime soon.”
How did you determine the right structure for your team, knowing that team would see rapid growth in the coming months? And ultimately, how did you decide to structure your team?
To add specialized focus to our team’s daily work, we created two high-level product teams: one for data analytics focused on our automated analytics engine and another for workflows focused on the front-end user experience. However, each team member operates as a full-stack engineer, and everyone is ready to jump in the back or front-end of the platform when needed. This means our teams are accountable and independent, but still fully collaborative and aligned across functions. It works well for us because teams can operate with limited dependencies and this structure is ready to grow with the organization.
What steps did you take to ensure a smooth transition to the new team structure? How did your engineers influence the process?
The most critical step was to get the new leaders of our two groups ready. We wanted to reward and recognize our teams by promoting two of our engineers to team leads. These leaders act as the combination of a tech lead, scrum master and manager. One of the most critical steps in this process was to involve everyone when making the plans for these new teams, something that’s built into our “#OneTeam” collaborative culture at LeanDNA.
The transition overall was smooth thanks to our company’s collaborative and transparent culture, along with some help from the book “The First 90 Days” to guide a seamless transition and a 360-degree feedback process for our new leaders. Now, each and every team member can make meaningful contributions to the company’s growth, and we have a clear path forward.
