EM: Scaling a Team from 3 to 12

Interviewer

You're hired as the first engineering manager for a product area with 3 engineers. The company plans to triple headcount in that area within a year. Walk me through your approach.

Candidate

The first 30 days: I'd focus on understanding the current system, team dynamics, and stakeholder expectations. I'd have 1:1s with each engineer to learn their goals and pain points. I'd also map the technical landscape - what's the architecture, deployment process, on-call situation. Days 30-60: Start hiring. Write detailed job descriptions with input from the existing engineers. Design the interview loop. I'd prioritize hiring a senior engineer first - they can take ownership of a subsystem and help onboard juniors. Days 60-90: Start splitting into sub-teams. With 6+ people, a single team becomes unwieldy. I'd organize around bounded contexts: team A owns the API layer, team B owns the data pipeline. Each team gets a tech lead (either promoted from within or hired). Ongoing: Invest in documentation, on-call rotation, and deployment automation. A 3-person team can operate on tribal knowledge. A 12-person team needs runbooks and a clear on-call schedule.

Interviewer

How do you ensure you're not becoming a bottleneck as the team grows?

Candidate

I delegate aggressively. By month 3, I should not be the primary reviewer on any code. I invest in tech leads who can make technical decisions autonomously. I also create decision-making frameworks. Instead of me deciding every architecture question, teams have clear guidelines: "If it affects a single service, the team decides. If it affects the API contract between teams, escalate to a cross-team RFC." And I block time for strategic work - 50% of my week should be future-looking (hiring, planning, org design) rather than firefighting.