The startup had just closed a $40M Series B. The plan was aggressive: grow engineering from 25 to 100 in 18 months, build out the platform, and capture the market window. The VP of Engineering had successfully hired the first 25 engineers. He figured scaling to 100 was just more of the same.
Twelve months later, the team was at 75 engineers—and velocity had dropped.
New hires took forever to become productive. Engineers spent more time in meetings than building. Coordination overhead exploded. The original team members, the people who'd built the product from scratch, were frustrated and disengaged. Several had already left.
"I don't understand," the VP said. "We hired strong people. But we're shipping less now than when we were half this size."
The problem wasn't the people. The problem was that everything about how the organization worked—structure, processes, communication patterns, decision-making—had been designed for 25 engineers and was breaking catastrophically at 75. The VP had scaled headcount without scaling the organization, and now he was drowning.
Series B is the scaling crucible. You have product-market fit, you have capital, and now you have the expectation to grow rapidly. But the organizational systems that worked when everyone knew everyone fail spectacularly as you add people. The transition from 20 to 100 engineers requires fundamentally rethinking how engineering works.
At SmithSpektrum, I've advised over 45 companies through Series B scaling[^1]. The successful ones understand that scaling engineering isn't about adding people—it's about scaling the systems that make people productive. The unsuccessful ones learn this lesson expensively.
Why Things Break at Scale
The organizational characteristics that make early-stage startups effective become liabilities as you grow.
At 15 engineers, everyone knows everything. You don't need coordination mechanisms because coordination happens naturally. You don't need documentation because you can ask anyone. You don't need process because the informal system works. Information flows freely, decisions get made quickly, and everyone feels connected.
At 30 engineers, cracks appear. You can't fit everyone in one meeting anymore. Not everyone knows what other teams are doing. Some decisions require coordination that doesn't happen naturally. But the systems mostly work—you can push through with informal processes and individual heroics.
At 50 engineers, the informal systems collapse. The all-hands meetings become one-way broadcasts. Communication becomes fragmented. Decisions get made in isolation and conflict with each other. Coordination overhead skyrockets. New hires flounder because there's no structured onboarding and the ad hoc approach doesn't scale.
At 75 engineers, you're dealing with the consequences. Velocity has dropped despite more people. The original engineers are frustrated with bureaucracy and meetings. Consistency has broken down—different teams do things different ways. The culture that made the early team special feels diluted or lost.
The transitions at each stage require different interventions. What worked at 15 becomes a bottleneck at 30. What worked at 30 becomes chaos at 50. What worked at 50 becomes dysfunction at 75. Scaling successfully means anticipating these transitions and building ahead of them.
Structure Evolution
Organizational structure must evolve as you scale, but the timing and nature of changes matter.
At 10-20 engineers, flat structure works. Everyone reports to the VP of Engineering or a technical founder. The span of control is manageable. The absence of hierarchy keeps decision-making fast.
| Team Size | Typical Structure | Manager:IC Ratio | Key Challenge |
|---|---|---|---|
| 20-30 | 2-3 teams, 1-2 managers | 1:8-10 | Defining team boundaries |
| 30-50 | 4-6 teams, engineering manager layer | 1:6-8 | Process without bureaucracy |
| 50-75 | Multiple groups, senior EM or director | 1:5-7 | Cross-team coordination |
| 75-100 | Full org structure, VP + directors | 1:5-6 | Maintaining culture |
At 20-40 engineers, you need a management layer. The VP can't have 30 direct reports. Engineering managers emerge—ideally from your senior engineers who show aptitude for people leadership. Player-coach models work at this stage; managers still contribute technically while managing small teams.
At 40-60 engineers, management becomes more specialized. Managers have fewer direct reports but more management responsibilities. You might need a second layer—directors who manage managers. The VP's role shifts from managing everyone to managing the organization.
At 60-100 engineers, you have a full organizational structure. Directors, managers, tech leads with different responsibilities. The VP is an executive managing executives, not a manager managing engineers. The organizational design becomes a strategic concern.
Team topology decisions become important by 40+ engineers. Feature teams (cross-functional teams that own product areas) maximize product velocity. Platform teams (teams that build shared infrastructure) maximize efficiency at scale. Most organizations end up with hybrids—feature teams for product development consuming platform services for efficiency.
Hiring at Scale
Hiring for a 25-person team is different from hiring for a 100-person team.
At small scale, hiring is founder-led and network-based. You know the candidates personally, or someone who knows them does. Quality control is easy because every hiring decision goes through the same few people.
At scale, you need hiring infrastructure. Recruiters who can run pipelines. Structured interview processes that produce consistent results across different interviewers. Hiring manager training so new managers make good decisions. Scorecards and calibration sessions to maintain quality.
The common mistake is hiring too fast. When the board says "get to 100 engineers," the temptation is to maximize hiring velocity. But absorption capacity is limited. If you hire faster than you can integrate, new hires don't onboard effectively, velocity drops despite more people, and you develop a cohort of underperformers who were set up to fail.
A sustainable hiring pace is typically three to four engineers per month at this stage—enough to grow meaningfully, slow enough to maintain integration quality. Build your hiring infrastructure before ramping volume. Train interviewers before they interview. Create onboarding before new hires arrive.
Quality erosion is the other common mistake. Under pressure to fill roles, companies lower standards—"this candidate is okay, we really need someone." Each compromise creates problems: performance issues later, cultural drift, management burden. Maintain your bar even when it's painful.
Process Evolution
Process is a dirty word in startups, but at scale, no process is worse than too much process. The question is finding minimum viable process—enough structure to coordinate effectively, not so much that it strangles.
What needs process varies by function. Code review should be required from day one—it's the cheapest quality investment you can make. On-call rotation should be formalized as soon as you have production systems worth protecting. Sprint planning becomes necessary around 15 engineers when coordination starts mattering. Technical design review becomes important around 25 engineers when multiple people are making architectural decisions. Formalized career ladders become important around 50 engineers when consistency across managers matters.
The right amount of process depends on the cost of coordination failures. If uncoordinated work wastes weeks of effort, add process. If the process adds more overhead than it saves, remove it. This calibration requires ongoing attention—the right amount of process at 30 engineers is wrong at 60.
Process adoption fails when imposed without buy-in. Engineers resist process they perceive as bureaucratic overhead. Explain why the process exists, involve people in designing it, iterate based on feedback. Process that people understand and helped create gets followed; process that appears by fiat gets circumvented.
Communication Scaling
Communication is the function that breaks most dramatically at scale.
At 15 engineers, you can rely on osmosis. Information spreads naturally through proximity and conversation. Everyone hears about important things without deliberate distribution.
At 50+ engineers, osmosis fails completely. If you don't deliberately distribute information, people don't know things. The engineer on team A has no idea what team B is working on. Important decisions get made without affected parties knowing.
Communication systems that scale include written updates distributed to broad audiences (team updates, engineering all-hands notes), documentation that persists and can be found later, forums for cross-team discussion and decision-making, and deliberate information sharing in team and manager meetings.
Meeting culture evolves out of necessity. All-hands meetings shift from weekly discussions to biweekly or monthly broadcasts. Team meetings become the unit of substantive discussion. Skip-level meetings help information flow vertically. Cross-team syncs help with horizontal coordination.
Documentation becomes more important, not less. In a small team, documentation is nice to have. At scale, undocumented decisions, architectures, and processes create constant confusion. The investment in documentation compounds as more people need to consume it.
Technical Scaling
The codebase and systems face scaling challenges parallel to the organizational ones.
Monolith versus services becomes a real decision. A monolith that worked fine at 15 engineers creates coordination problems at 50. Too many people working on the same codebase creates merge conflicts, test suite slowness, and deployment complexity. But prematurely moving to microservices creates its own complexity. The right answer depends on where the pain is.
Developer experience investment becomes critical. Build times that were tolerable at 15 engineers become intolerable at 50—the aggregate cost of waiting is enormous. Development environment setup that was fine with high-context early employees fails for new hires. Platform engineering (tooling, CI/CD, development environments) becomes a strategic investment.
Technical debt accumulates faster with more people. Code that was "good enough" gets modified by engineers who don't understand the original context. Shortcuts multiply. Without deliberate investment in debt reduction, the codebase becomes progressively harder to work with. Budget 20-30% of capacity for ongoing technical improvement.
Architecture review processes prevent costly mistakes. At scale, individual engineers making architectural decisions without broader input can create expensive problems. Some review process—RFCs, architecture review boards, design docs with required reviewers—catches issues before they're built.
Culture at Scale
Culture doesn't scale automatically. What was implicit in a small team becomes invisible or lost in a large one.
Values that were lived through daily interaction must become explicit. Document them. Hire for them. Recognize people who exemplify them. Discuss what they mean in practice.
Subcultures will form. Different teams will develop different norms. Some variation is healthy; excessive divergence creates problems. Find the right balance between team autonomy and organizational consistency.
New hire integration requires more attention. Early employees absorbed culture through immersion with founders. New hires joining at scale need structured introduction—onboarding programs, culture sessions, deliberate mentorship. If you're not actively transmitting culture, it's not being transmitted.
Original team members need care. They joined a scrappy startup; they're now in a growth-stage company. Some will thrive with the change; others will be frustrated. Acknowledge that things are different. Create paths for those who want to continue leading at scale. Accept that some will leave, and that's okay.
VP Engineering Evolution
The VP's role changes dramatically through scaling.
At 20 engineers, the VP is often still an individual contributor—writing code, making technical decisions, deeply involved in details. This works because the span is manageable and the leverage from direct contribution is high.
At 40 engineers, the VP must step back from IC work. Their leverage comes from making the organization work, not from personal contribution. The transition is hard—giving up the craft you love for the management work you were less prepared for.
At 60+ engineers, the VP is an executive. Their job is organizational design, strategic alignment, executive team participation, and managing managers. The technical contribution is setting direction, not writing code. The people management is developing leaders, not managing engineers directly.
VPs who can't make these transitions create bottlenecks. The VP who insists on reviewing every design becomes a chokepoint. The VP who won't delegate authority creates learned helplessness. The VP who keeps doing IC work neglects organizational building. Recognizing and making these transitions is one of the hardest parts of scaling.
The startup whose velocity dropped at 75 engineers? They paused hiring for three months. They restructured into smaller autonomous teams. They added a management layer that had been missing. They invested in developer experience and documentation.
When they resumed hiring, they did it more slowly, with better integration. By 100 engineers, velocity per engineer had recovered to where it was at 30—and total velocity was much higher because of scale.
"I learned that growing engineering isn't about adding people," the VP told me afterward. "It's about scaling the system that makes people productive. You can't skip that work."
References
[^1]: SmithSpektrum Series B advisory, 45+ companies, 2019-2026. [^2]: Larson, Will. "An Elegant Puzzle: Systems of Engineering Management," 2019. [^3]: Skelton & Pais, "Team Topologies," 2019. [^4]: Fournier, Camille. "The Manager's Path," O'Reilly Media, 2017.
Scaling through Series B? Contact SmithSpektrum for organizational design and hiring strategy.
Author: Irvan Smith, Founder & Managing Director at SmithSpektrum