The VP of Engineering looked exhausted. "At 30 engineers, everything worked. Now we're at 65, and it's chaos. Decisions take forever. Nobody knows who owns what. We're hiring but somehow getting less done."

This is the 50-100 engineering team transition—arguably the hardest scaling phase in a company's growth. The informal patterns that worked at 30 collapse. The formal structures you'll need at 150 don't exist yet. You're too big to be small and too small to be big.

After advising over 30 companies through this specific transition at SmithSpektrum, I've seen consistent patterns in what breaks and what works[^1].

Why 50-100 Is Different

The physics of engineering organizations change around 50 people.

Team Size Communication Style Management Approach
10-25 Everyone knows everyone Direct founder involvement
25-50 Mostly connected Department heads, some structure
50-100 Strangers emerge Must have formal systems
100+ Formalized Organization design is critical

Below 50, you can survive on informal communication. Someone always knows what's happening elsewhere. Above 50, this breaks down. Engineers work on projects with people they've never met. Information stops flowing automatically.

The specific challenges at this phase:

Coordination costs explode. Meeting load increases. Decisions require more stakeholders. Work gets duplicated.

Leadership gaps emerge. You need more managers than you have. The managers you have may not scale.

Process resistance peaks. Engineers who joined for startup culture resist formalization. But without process, chaos reigns.

Culture dilutes. New hires outnumber old-timers. Original values fade.

Technical debt compounds. Early shortcuts become systemic problems. Ownership is unclear.

Organizational Design

At 50-100 engineers, organizational structure stops being optional.

Team Topologies

Model Description Best For
Feature teams Cross-functional, own end-to-end features Product velocity
Platform + Product Platform team serves product teams Clear infrastructure needs
Domain teams Organized by business domain Clear domain boundaries
Matrix Functional + project reporting Complex dependencies

Feature teams are the default recommendation. They reduce coordination costs, enable ownership, and scale well. But they require clear boundaries and some platform/shared services support.

Typical Structure at 75 Engineers

VP Engineering
├── Director, Product Engineering (35 engineers)
│   ├── EM, Team A (8)
│   ├── EM, Team B (8)
│   ├── EM, Team C (7)
│   ├── EM, Team D (7)
│   └── Tech Lead (5, shared services)
├── Director, Platform (20 engineers)
│   ├── EM, Infrastructure (8)
│   ├── EM, Developer Experience (6)
│   └── EM, Data Platform (6)
├── Director, Quality & Security (10 engineers)
│   ├── Manager, QA (5)
│   └── Manager, Security (5)
└── Staff+ Engineers (10, distributed across teams)

Team Sizing

Guideline Reasoning
5-8 engineers per EM Sustainable management span
3-4 teams per Director Reasonable oversight
2-3 staff engineers per 25 engineers Technical leadership ratio
Max 2 levels between VP and IC Information flow

The biggest mistake: under-investing in management. At 50 engineers, you might have 4-5 managers. At 100, you need 12-15. That's 8-10 new managers in a relatively short period—either promoted internally or hired externally.

Leadership Development

The 50-100 transition is a leadership scaling problem as much as an organizational one.

The EM Gap

You'll need more engineering managers than your current pipeline provides. Options:

Option Pros Cons
Promote internal ICs Know culture, trusted May lack management skill
Hire external EMs Immediate expertise Cultural adaptation time
Contract leadership coaches Accelerate development Cost, external dependency
Fractional/interim managers Bridge gaps Not permanent

The typical mix: 60% internal promotion, 40% external hire. This maintains cultural continuity while bringing in necessary expertise.

Manager Development Program

New managers need support, especially promoted ICs.

Month Focus Activities
Month 1 Fundamentals 1:1s, feedback, basic management
Month 2 Team health Team dynamics, meeting facilitation
Month 3 Performance Goal setting, evaluation, difficult conversations
Ongoing Growth Leadership cohort, external coaching

Don't throw new managers into the deep end. Budget for management training, coaching, and reduced individual contributor expectations during the transition.

Technical Leadership

At 50-100, you need staff engineers who:

  • Set technical direction without positional authority
  • Mentor across multiple teams
  • Tackle cross-cutting technical problems
  • Maintain architectural coherence

Staff engineers are not just senior engineers with a different title. They operate differently—more influence, less direct output, broader scope.

Role Scope Key Activities
Staff Engineer 2-3 teams Technical direction, mentoring, complex projects
Principal Engineer Org-wide Architecture, technical strategy, external representation
Distinguished Engineer Company-wide Company technical direction, industry presence

At 75 engineers, you probably need 6-10 staff-level engineers distributed across your organization.

Process Evolution

Process at 50-100 must be "just enough"—sufficient to coordinate but not so heavy that it stifles speed.

What Needs to Formalize

Area Why How
Planning Coordination across teams Quarterly planning, roadmap alignment
Communication Information doesn't flow naturally Regular all-hands, written updates
Decision-making Unclear ownership RACIs, documented decision processes
Code review Quality at scale Review requirements, SLAs
Incident response Reliability matters more Formal on-call, incident process
Hiring Volume requires consistency Structured interviews, calibration

What Should Stay Flexible

Area Why
Daily team work Teams should optimize locally
Technical choices within guardrails Autonomy drives ownership
Meeting cadences Teams have different needs
Personal work styles Respect individual differences

The principle: standardize the interfaces between teams; let teams manage their internal processes.

The Planning Rhythm

Cadence Activity Participants
Annual Strategic planning, headcount VPE, Directors, Execs
Quarterly OKR setting, roadmap alignment All teams
Monthly Progress check, adjustment Teams + stakeholders
Bi-weekly Sprint planning (if applicable) Individual teams
Weekly Status updates, blockers Teams, cross-team where needed

At 50-100, quarterly planning becomes essential. Without it, teams drift in incompatible directions. The planning process should be lightweight but real—not a paperwork exercise.

Technical Systems

The codebase and infrastructure that worked at 30 engineers often breaks at 70.

Common Technical Scaling Issues

Issue Symptom Solution
Monolith bottleneck Everyone stepping on each other Modularization, service extraction
Slow CI/CD 30+ minute builds Pipeline optimization, parallelization
No code ownership Everything is "shared" CODEOWNERS, clear module ownership
Testing gaps Prod bugs increasing Test coverage requirements
Deployment fear Releases less frequent Better testing, feature flags, rollback
Poor observability Can't diagnose issues Investment in monitoring, logging

You don't need to solve all of these at once. Identify your biggest bottleneck and address it. Then the next. Incremental improvement beats big-bang transformation.

Platform Investment

At 50-100, platform/infra investment pays off. Developer experience tools that save each engineer 30 minutes per day save thousands of hours across the organization.

Investment Payoff
Internal developer portal Reduced onboarding time, self-service
CI/CD optimization Faster iteration
Local dev environment Less "it works on my machine"
Standardized tooling Reduced cognitive load
Self-service infrastructure Less waiting on ops

A dedicated platform team typically makes sense once you pass 40-50 engineers. Before that, platform work can be distributed.

Culture Maintenance

Culture at 50-100 is no longer automatic—it requires deliberate maintenance.

The Dilution Problem

At 30 engineers At 80 engineers
Everyone knows founders personally Many haven't met them
Values are implicit Values must be explicit
Culture is absorbed Culture must be taught
Stories spread naturally Stories must be actively shared

Culture Reinforcement Tactics

Tactic How
Document values Write them down, with specific examples
Value-based hiring Screen for cultural values explicitly
Onboarding immersion Deep culture component in onboarding
Recognition tied to values Celebrate behaviors that embody values
Leadership modeling Leaders must live the values visibly
Stories and rituals Share origin stories, maintain traditions

The most common failure: assuming culture will maintain itself. It won't. Without active reinforcement, culture defaults to "generic large company" within 18-24 months.

Common Failure Modes

Failure Mode How It Manifests Prevention
Process explosion Everything requires approval Start minimal, add only when pain demands
Leadership vacuum Not enough managers/leads Plan leadership pipeline 6-12 months ahead
Communication breakdown Teams don't know what others are doing Regular cross-team updates, slack channels
Lost speed Everything takes longer Protect team autonomy, limit dependencies
Culture collapse "It's not the same here anymore" Active culture reinforcement
Technical chaos Conflicting architectures Technical leadership, architecture review

The 90-Day Transition Plan

If you're at 50 engineers and heading toward 100, here's a 90-day plan:

Days 1-30: Assessment

  • Map current org structure and pain points
  • Identify leadership gaps
  • Audit process (too much? too little?)
  • Survey team health and engagement
  • Identify top 3 organizational problems

Days 31-60: Design

  • Design target org structure for 100 engineers
  • Identify promotion candidates for management
  • Begin external recruiting for leadership gaps
  • Define minimal process additions needed
  • Create manager development plan

Days 61-90: Implementation

  • Announce organizational changes
  • Begin new planning cadences
  • Launch manager development program
  • Implement first process improvements
  • Establish regular org health checks

The VP who was drowning at 65 engineers? We redesigned their organization around clear teams, promoted two strong ICs into management, hired a Director externally, and implemented quarterly planning. Within six months, their velocity had recovered. Within a year, they'd scaled to 95 engineers without losing speed.

The 50-100 transition is hard. But it's not mysterious. The same patterns break, and the same solutions work.


References

[^1]: SmithSpektrum organizational scaling advisory, 30+ companies, 2019-2026. [^2]: Larson, Will. "An Elegant Puzzle: Systems of Engineering Management," 2019. [^3]: Skelton, Matthew and Pais, Manuel. "Team Topologies," 2019. [^4]: Reforge, "Engineering Management at Scale," 2024.


Scaling your engineering organization? Contact SmithSpektrum for organizational design and leadership development support.


Author: Irvan Smith, Founder & Managing Director at SmithSpektrum