Can you recall a situation when you had to transition between managing two teams of different sizes? How did you adjust your management style to accommodate the changes?

Question

Anonymous · Accepted Answer

SITUATION

At Spotify, I led two ML infrastructure squads of ~12–16 engineers total.
Ownership was crisp: we focused on feature engineering pipelines, distributed
training infra, observability hooks, and serving infrastructure. The boundaries
between squads were clear, and support systems like Staff ICs and TPMs created
strong role separation. When I transitioned to Mailchimp (within Intuit), the
scope grew significantly. I suddenly had 25–30 engineers across four squads,
including contractors, spanning reinforcement learning, inference platforms,
feature engineering, distributed training, and large-scale data processing. In
addition, I was expected to partner deeply with product engineering
teams—nudging them toward a platform-first mindset and guiding adoption of
unified ML SDKs, while also consulting on modernizing core Mailchimp infra
(databases, workflow orchestration). This was a much broader, more ambiguous,
and cross-functional leadership challenge.

--------------------------------------------------------------------------------

TASK

My task was to adapt my leadership style to this larger, more complex
environment. At Spotify, being hands-on with technical details and engaging
deeply in design was feasible with 12–16 engineers. At Mailchimp, with nearly
double the size and far broader scope, I had to:

1. Scale myself through delegation while still providing clarity on outcomes.

2. Create alignment across four distinct squads with different technical
    charters.

3. Drive cross-org influence, not just execution, since platform adoption
    required buy-in from product engineering orgs outside my direct line.

--------------------------------------------------------------------------------

ACTION

I shifted my approach along three key dimensions:

1. Delegation with clear frameworks: Instead of being directly embedded in
    every design or decision, I delegated ownership to leads and Staff ICs. I
    used a framework of “outcomes + guardrails + support.” For example, in the
    reinforcement learning squad, the outcome was “deliver an inference loop
    that achieves p95 <150ms at 2k RPS,” the guardrails were “must align with
    SDK unification effort,” and the support was regular checkpoints and
    escalation paths. This allowed autonomy while ensuring alignment.

2. Cross-squad alignment rituals: I instituted monthly “Platform Council”
    meetings where leads from each squad shared progress, blockers, and design
    considerations. This reduced silos and made dependencies explicit. I also
    rotated ICs across squads for short-term projects (e.g., feature engineering
    ICs helped with inference SDK prototyping), which built empathy and shared
    ownership.

3. Influence outside my org: With product engineering, I moved into a teaching
    and evangelism role. I reviewed their PRDs and design docs, not to dictate,
    but to highlight where a platform-first approach could reduce duplication or
    accelerate delivery. For example, I worked with the Credit Karma team to
    pilot the unified SDK, positioning them as early adopters and advocates. I
    also invested in storytelling—framing infra improvements in terms of faster
    iteration and customer experience rather than “infra refactors.”

4. Balance of depth and scale: While I couldn’t be in every design detail, I
    picked 1–2 critical initiatives per quarter (e.g., database modernization
    and SDK rollout) to go deep on, so I could model technical rigor without
    spreading myself thin.

--------------------------------------------------------------------------------

RESULT

* At Spotify, I was able to operate as a hands-on EM with crisp boundaries. At
   Mailchimp, I successfully scaled my leadership to four squads by leaning on
   structured delegation and cross-squad rituals.

* Platform adoption accelerated: three product teams became guinea pigs for our
   SDK within two quarters.

* Cost and reliability goals were met: inference latency reduced by ~40%, and
   database load dropped by 25% after workflow orchestration improvements.

* Team engagement remained high—pulse survey “I understand priorities” improved
   by +14 points despite the broader scope.

--------------------------------------------------------------------------------

TAKEAWAY

The transition taught me that leading 12–16 engineers vs. 25–30 across multiple
squads requires a fundamental shift: from being a detail-oriented anchor to
being a context setter, delegator, and cross-org influencer. It reinforced that
scaling leadership isn’t about doing more myself, but about building systems and
empowering others to execute while I drive clarity and alignment.

Can you recall a situation when you had to transition between managing two teams of different sizes? How did you adjust your management style to accommodate the changes?

Practice this question with AI

Go Premium

Practice More Questions

Community Answers

Unlock Community Insights