Structuring a Scaling Team to Optimize for Growth

Problem

As the Engineering Manager, I led teams developing the Amazon Delivery mobile App in my prior role at Amazon. The entire network of Amazon drivers used it to deliver 2.5+ Billion packages across 15 countries. I needed to articulate a strategy to scale and right-size the team in order to speed up customer delivery times and provide innovations to our customers. Starting from delivering to homes, businesses, lockers, cars, and even garages worldwide, the team grew in numbers.

In tune with that, the cost of coordinating, communicating, and relating with each other snowballed to such a degree that it lowered individual and team productivity. As a result of being a large team, we were often asked to loan developers to complete other projects, especially the high visibility projects that required cross-functional collaboration across several teams.

Actions taken

I proposed to split my organization by establishing some core tenets. Each manager was responsible for motivating their team to drive tangible and measurable results for the business. At the same time, managers were responsible for raising the bar on operational excellence, obsess over our customers, and think big to ship the best possible product features in working closely with their product managers.

Next, I switched gears to thinking about a tactical and execution strategy for the managers on the team focused on the first principles of scaling teams and leading with autonomy. Jointly, we established the engineering teams. We also ensured that the teams would remain flexible enough to align with the changing business requirements and build capabilities to execute business initiatives without heavy coordination across different groups. I kept our teams independent, engaged, quick to deliver on business needs. We aligned with the organization's ultimate goal to provide an experience that enabled drivers of all tenures and skill sets to deliver efficiently while improving delivery quality. Breaking into smaller teams as the organization scaled encouraged greater autonomy and creativity.

I encouraged my peer managers to think critically about splitting the existing Delivery Experience team into two separate feature teams. Each contained Android and iOS developers centered around their own specific goals in the delivery space. I explained that a feature team is typically a long-lived team that stays together to ‘jell’ for higher performance; they take on new features over time.

I realized that applying modern engineering practices, especially continuous integration, is essential when adopting feature teams. I presented a paper that outlined the benefit of constant integration around shared code ownership, which is necessary when multiple teams work simultaneously on the same components. While this split does solve having too large of a group, it introduced quite a lot of ambiguity in team identity and goals.

As business priorities and goals changed, each feature team would struggle to have a clear set of goals on what they are meant to solve as part of the overall Delivery experience for our customers. I ultimately decided to split the feature teams by experience types that our drivers experience throughout their travel. For instance, getting on the road to start delivery, viewing their itinerary, making a vehicle stop, or arriving at the customer’s door were all a part of it.

Lessons learned

• Obsessing over customers can actually help in right-sizing teams for optimal business growth.
• If you need to quantify growth, you should start collecting data earlier on. It would be more cohesive to have data on hands for prospects.