Leadership Interview: Engineering Team Reorganisation

Leadership Interview: Engineering Team Reorganisation

Your company has grown from 20 to 80 engineers in 18 months. The original team structure (4 feature teams of 5, each owning a vertical slice) hasn't scaled. Deployments are slower, cross-team dependencies are causing delays, and engineer satisfaction scores have dropped. The CEO has asked you to propose a reorganisation. Walk me through your approach.

Interview Format (45 minutes)

Time Allocation:

• Clarifying questions and diagnosis: 10 minutes
• Proposed structure: 15 minutes
• Change management plan: 10 minutes
• Trade-offs and follow-ups: 10 minutes

Step 1: Diagnosis (10 min)

A strong candidate will resist jumping to a new org chart and instead diagnose the root causes first.

Good Clarifying Questions

About the symptoms:

• What's the current deployment frequency? How has it changed? (was daily, now bi-weekly)
• Where are the cross-team dependencies concentrated? (shared database, common API layer, auth service)
• What do engineers say in satisfaction surveys? (lack of autonomy, too many meetings, unclear ownership)
• How many incidents per month? Who responds? (increasing, no clear ownership)

About the business context:

• What's the product strategy for the next 12 months? (expanding into enterprise, launching mobile app)
• Are we still hiring? At what rate? (20 more engineers over next 6 months)
• What's the current management layer? (4 team leads reporting to VP Eng, no middle management)
• Is there a platform team or shared infrastructure team? (no, everything is shared informally)

About constraints:

• Budget for the reorg? (can hire 2-3 new managers)
• Timeline expectations? (need to show progress in 6 weeks)
• Any political considerations? (founding team lead is protective of their domain)
• Remote vs in-office? (hybrid, 3 offices + remote)

Red flags if candidate:

• Immediately proposes a structure without understanding the problems
• Focuses only on reporting lines, not on team missions
• Doesn't ask about business strategy
• Ignores the human/emotional aspects

Diagnostic Framework

Strong candidate uses a structured approach:

Current State Assessment:
1. Technical architecture → Does the org mirror the system? (Conway's Law)
2. Delivery metrics → Deploy frequency, lead time, failure rate
3. Team cognitive load → Are teams overloaded? Too many responsibilities?
4. Communication patterns → Where are the bottlenecks?
5. Decision-making → Who decides what? Are decisions slow?

Step 2: Proposed Structure (15 min)

Principles First

Strong candidate states principles before drawing boxes:

1. Teams aligned to value streams, not components
2. Minimise cross-team dependencies for day-to-day work
3. Clear ownership — every service, every feature has one team
4. Right-sized teams — 5-8 engineers (two-pizza rule)
5. Career growth paths — IC and management tracks
6. Platform enables, doesn't block — internal teams serve product teams

Proposed Organisation

VP Engineering
├── Product Engineering (Director)
│   ├── Team: Growth (6 eng)
│   │   Mission: User acquisition, onboarding, activation
│   │   Owns: Landing pages, signup flow, trial experience
│   │
│   ├── Team: Core Experience (7 eng)
│   │   Mission: Primary user workflows
│   │   Owns: Dashboard, main feature set, notifications
│   │
│   ├── Team: Enterprise (6 eng)
│   │   Mission: Enterprise features and sales enablement
│   │   Owns: SSO, RBAC, audit logs, admin console
│   │
│   ├── Team: Mobile (5 eng)
│   │   Mission: Native mobile experience
│   │   Owns: iOS and Android apps
│   │
│   └── Team: Integrations (5 eng)
│       Mission: Third-party ecosystem
│       Owns: APIs, webhooks, marketplace
│
├── Platform Engineering (Director)
│   ├── Team: Developer Experience (6 eng)
│   │   Mission: Make product teams faster
│   │   Owns: CI/CD, testing infra, dev tools, observability
│   │
│   ├── Team: Infrastructure (6 eng)
│   │   Mission: Reliable, scalable, cost-effective infra
│   │   Owns: Cloud infra, databases, networking, security
│   │
│   └── Team: Data Platform (5 eng)
│       Mission: Data as a product
│       Owns: Data pipeline, analytics, ML infrastructure
│
└── Staff Engineers (2-3, embedded across teams)
    Mission: Technical strategy, architecture decisions, mentoring

Total: ~80 engineers, 10 teams, 2 directors, 8 team leads

Why This Structure

Addresses root causes:

Strong candidate also discusses:

• How this maps to the technical architecture (Inverse Conway Manoeuvre)
• Which teams will need to be bootstrapped vs formed from existing teams
• How Staff Engineers bridge teams without creating a bottleneck
• Why platform is separate (different cadence, different customers)

Team Interaction Model

Product Teams ←→ Product Teams:  APIs and contracts (async)
Product Teams → Platform Teams:  Requests via backlog (prioritised)
Platform Teams → Product Teams:  Self-service tools and documentation
Staff Engineers ↔ All Teams:     Architecture reviews, RFCs, pairing

Team API concept:

Each team publishes:
1. Mission statement (why we exist)
2. Owned services and SLOs
3. Communication channels (Slack, office hours)
4. How to request work (backlog, RFC)
5. On-call rotation

Step 3: Change Management Plan (10 min)

Rollout Timeline

Strong candidate doesn't just draw boxes — they plan the transition.

Weeks 1-2: Communicate and Listen

• Share diagnosis with leadership team
• Gather input from current team leads
• 1:1s with every engineer (or skip-levels for larger orgs)
• Address the founding team lead concern directly and early

Weeks 3-4: Announce and Form

• All-hands presentation: the why, the what, the how
• Publish team missions and initial rosters
• Let engineers express preferences (no guarantees, but input matters)
• Appoint team leads (promote from within where possible)

Weeks 5-6: Execute

• Teams move to new structure
• Each team has a kickoff: mission, norms, working agreements
• Platform team triages the most painful shared services
• Start weekly cross-team sync (temporary, until stable)

Weeks 7-12: Stabilise

• Track deployment frequency, lead time, satisfaction
• Retrospective at week 8 and week 12
• Adjust team boundaries based on learnings
• Hire directors and backfill if needed

Communication Framework

Strong candidate addresses all stakeholders:

What Can Go Wrong

Strong candidate proactively identifies risks:

1. Key person leaves — Mitigate by involving people early, giving them agency
2. Productivity dip during transition — Expected, communicate this to CEO upfront (2-4 week dip)
3. Teams resist new boundaries — Clear escalation path, enforce ownership decisions
4. Platform team becomes a bottleneck — Self-service first, avoid ticket-driven model
5. Reorg doesn't fix the real problem — Measure baseline metrics before change, review at 90 days

Step 4: Trade-offs and Follow-ups (10 min)

Alternative Structures Considered

Strong candidate can articulate why they didn't choose alternatives:

Option B: Component Teams (Frontend/Backend/Mobile)

• Pros: Deep specialisation, easy to staff
• Cons: Handoffs, no end-to-end ownership, coordination overhead
• Why not: Slows delivery, creates dependencies

Option C: Spotify Model (Tribes/Squads/Chapters/Guilds)

• Pros: Well-known, supports matrix management
• Cons: Complex, Spotify themselves moved away from it
• Why not: Overhead too high for 80 engineers, adds confusion

Option D: Keep Current + Add Platform

• Pros: Less disruption
• Cons: Doesn't address team size or clear ownership
• Why not: Kicks the can down the road

Metrics to Track

Delivery:
- Deployment frequency (target: daily per team)
- Lead time for changes (target: <2 days)
- Change failure rate (target: <5%)
- Mean time to recovery (target: <1 hour)

Team Health:
- Engineer satisfaction score (quarterly survey)
- Voluntary attrition rate
- Internal transfer requests
- Cross-team dependency count

Business:
- Feature velocity (stories delivered per sprint)
- Time to market for enterprise features
- Mobile app launch timeline

Evaluation Rubric

Strong Performance (Hire)

• Diagnoses before prescribing
• Proposes principles-driven structure
• Considers Conway's Law and team cognitive load
• Plans the human side of change (communication, emotions, risks)
• Discusses metrics and feedback loops
• Considers alternative structures with reasoned trade-offs
• Addresses the political/interpersonal dynamics

Adequate Performance (Maybe)

• Proposes a reasonable structure
• Some consideration of change management
• Limited exploration of alternatives
• Misses some stakeholder concerns
• Can be guided to think more broadly

Weak Performance (No Hire)

• Immediately draws an org chart without diagnosis
• Only thinks about reporting lines, not missions
• Ignores change management ("just announce it")
• Can't articulate trade-offs between structures
• No consideration of metrics or feedback loops
• Dismisses human/emotional concerns

Follow-up Questions

For Director candidates:

• How would you handle a situation where two teams both want to own a critical service?
• A Staff Engineer disagrees with the new structure. How do you handle it?
• Six months in, the Enterprise team is struggling. What do you do?
• How do you balance standardisation (platform) with team autonomy?

For VP/CTO candidates:

• How does the engineering org structure influence your technical architecture decisions?
• How would you structure this differently if you were fully remote?
• The CEO wants to add an AI/ML team. Where does it fit?
• How do you ensure the platform team stays aligned with product priorities?

---

This question tests organisational design thinking, change management skills, and the ability to balance technical and human factors. A strong candidate demonstrates systems thinking about both the technical architecture and the social architecture of engineering teams.