Back to resources

Structuring a Scaling Team to Optimize for Growth

Scaling Team
Convincing
Coaching / Training / Mentorship

6 July, 2021

Srivatsa Radhakrishna
Srivatsa Radhakrishna

Sr. Engineering Manager at Apple

Srivatsa Radhakrishna, Sr. Engineering Manager at Apple iCloud Services, takes us on his journey as a Senior Manager executing a strategy to structure a scaling team amid unprecedented hockey stick 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.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

Assessing the Performance of Your Team

20 August

Parallels between Work and Sport.

Goal Setting
Different Skillsets
Coaching / Training / Mentorship
Performance
Ron Pragides

Ron Pragides

SVP Engineering at Trustly Group AB

Leaving Room to Say Things Suck — Leadership Lessons from “Ted Lasso”

17 August

A major sign of trust, comfortability, and vulnerability is for someone you lead to be able to say something sucks.

Building A Team
Company Culture
Leadership
Coaching / Training / Mentorship
John Hartley

John Hartley

Senior Engineering Manager at Curology

Scaling a Team in Two Parts: The Product and Manager

2 August

Viswa Mani Kiran Peddinti, Sr Engineering Manager at Instacart, walks through his experience scaling a team, product and his skills as a leader.

Managing Expectations
Product
Scaling Team
Leadership
Meetings
Viswa Mani Kiran Peddinti

Viswa Mani Kiran Peddinti

Sr Engineering Manager at Instacart

How to Enter QA With a Non-Technical Degree

2 August

Lewis Prescott, QA Lead at Cera Care, explains his journey from a degree in psychology to learning test automation and computer programming.

Handling Promotion
Personal Growth
Coaching / Training / Mentorship
Career Path
Lewis Prescott

Lewis Prescott

QA Lead at CeraCare

(Re)Organizing Your Teams Using Domain-Driven Design

12 July

A proposal for how to create an org structure that will deliver software systems that you want, not ones you get stuck with.

Alignment
Architecture
Scaling Team
Building A Team
Internal Communication
Reorganization
Ram Singh

Ram Singh

CTO at REAL Engagement & Loyalty