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