When James Everingham joined Instagram as its head of engineering in 2015, he knew that change was in the cards.
In just two years’ time, the team was expected to grow to more than 400 engineers, a nearly fourfold increase from their headcount at the time. What would prepare the team for this rapid scaling effort?
“It was not an easy task,” Everingham recalled in a 2017 Harvard Business Review article, “but I had a powerful weapon in mind from the start: reorganization.”
Reorganizing or restructuring the team meant that inefficiencies of the past — for example, two separate teams working on the same search function instead of one team with a concerted goal — would have to be minimized. Clear definitions of outcomes led the way to a structure that best fit the scaling organization.
“[W]e’re actually moving faster than we were when we were a team of 115. We have reorganization to thank,” Everingham said.
Instagram isn’t the only tech company that has gone through reorganization efforts. As tech companies scale, engineering teams — typically the foundation of a company’s product — are the first to add new members to help the company grow.
That was the case at NYC-based SwagUp, an API-first platform where top brands can create, automate, and distribute swag. After wanting to ensure speed and dependencies were as efficient as possible, CTO Dak Gonzalez decided to restructure his teams.
In conversation with Built In NYC, Gonzalez detailed the structure that was right for his team and the steps they took to ensure a smooth organizational transition.
When did you know it was time to reevaluate the structure of your engineering team? What were the biggest indicators?
For me, it is always about speed and dependencies. When things start getting slow because of other functional dependencies, or when too many things are being worked on by the same people, I know we need a different approach.
When you work on an extensive product with many different functions, you need speed. You can’t have everyone knowing everything.
When you work on an extensive product with many different functions, you need speed.”
How did you determine the right structure for your team/business, knowing that team would see rapid growth in the coming months? And ultimately, how did you decide to structure your team?
It was determined by experience and necessity. It was a common sense of what was needed and why.
I like the idea of cross-functional teams. Some people call them “pods” or “squads.” The concept is to have a member or a resource from each functional area. Our team's structure, right now, has at least one resource from each team: UX/UI, front end, back end, Salesforce, QA, and DevOps. Depending on the feature or epic being worked on, some functional areas might have more dedicated resources than others.
We keep architecture consistent by having functional architects across all teams. No matter what epic or feature is being worked on, the architects will always have a say to keep consistency across their stack.
This structure keeps checks and balances. Product will push the teams for feature delivery, and the architects will make sure their stack is consistent across teams and features.
What steps did you take to ensure a smooth transition to the new team structure? How did your engineers influence the process?
When I started at SwagUp I was a product and full-stack developer. That was easy. Everything was in my head, and I didn’t have to communicate much about my tech decisions.
As we grew, I brought in other developers for functional areas: front end, back end, and Salesforce. We kept everything in a single cross-functional team while adding more developers to that “squad.” We realized that we were too many people for one team, and we had to split the teams into functional areas. But, we had the same backlog of requests, and depending on the task, it required a particular team effort. It made the structure more like multiple functional teams rather than cross-functional.
The biggest challenge came when we wanted to develop features not related to one another and figuring out how to scale so that we could keep up with the feature demands. That was what triggered the breakdown into multiple “squads” and what we currently have.
It required us to hire more resources, and that’s what we keep doing. When a new hire comes in, they are assigned to a senior developer. They work in pair programming for a while until that developer is ready to get assigned to a cross-functional team.
