The Problem Nobody Warns You About

When our Series B closed, the champagne hadn't gone flat before the board asked: "How fast can you scale the team?"

The answer was 14 months. From 15 engineers to 80.

Everyone warned me about infrastructure scaling, database bottlenecks, and architectural complexity. Nobody warned me about what actually broke first: the invisible systems that held everything together.

This is the story of what broke, when it broke, and how we fixed it. Not because we were smart, but because we were desperate.

Month 3: The Communication Apocalypse

What Broke

At 15 people, everyone knew everything. Stand-ups took 10 minutes. Decisions happened over lunch. Architecture discussions were hallway conversations.

At 35 people, chaos.

The symptoms were obvious:

• Critical decisions happening in Slack DMs between two people
• Engineers asking "who owns authentication?" and getting three different answers
• "Quick syncs" that somehow required 12 people and still resolved nothing
• New engineers spending their first week just trying to figure out who to ask

But the real problem was invisible: We were running a 35-person organization with 15-person communication patterns.

The "Just Talk to Them" Fallacy

In small teams, "just talk to them" is great advice. At scale, it's organizational poison.

Here's why: If every decision requires synchronous communication, and you have 35 engineers, the number of potential communication paths is 595 (n*(n-1)/2).

You can't "just talk" to 595 potential connections. You create shortcuts. Those shortcuts become silos. Silos become fiefdoms. Fiefdoms become dysfunction.

What Actually Fixed It

1. We made writing the default

Not because we loved documentation (we didn't). But because writing forces clarity and scales infinitely.

New rule: If a decision affects more than one team, it gets written down before it gets made. No exceptions.

This felt slow at first. Engineers complained. "We're moving too slow!"

They were wrong. We weren't moving slower—we were finally seeing how slow our actual decision-making was. All those hours in meetings? Now compressed into async RFC reviews.

2. We created explicit ownership

We built a RACI-style ownership matrix. Not because we loved bureaucracy, but because "collaborative ownership" at scale means "nobody owns it."

Every service, every system, every decision domain got an owner. Not a committee. Not a team. A human being with a name and a Slack handle.

Controversial at first. "But we're a collaborative culture!"

Yes. And collaboration requires knowing who to collaborate with.

3. We abolished certain meetings

The hardest thing I did was kill our all-hands engineering standup.

It had been sacred. Fifteen people, ten minutes, everyone knew everything.

At 35 people, it was 45 minutes of people half-listening while waiting for their turn.

We replaced it with:

• Team-level standups (8 people max)
• Weekly written updates (async, threaded discussions)
• Monthly all-hands for strategy only (not tactics)

People mourned it. Then they realized they got 45 minutes back every day.

Month 6: The Architecture Reckoning

What Broke

We thought we were ready. We'd split the monolith. We had microservices. We'd read all the Medium articles.

Turns out, microservices don't save you from organizational dysfunction—they amplify it.

The new bottlenecks:

• Team A blocked on a feature from Team B's service (wait time: 2 sprints)
• Teams built overlapping services because "we didn't know theirs existed"
• Microservices calling microservices calling microservices (distributed monolith achieved)
• Service dependencies looked like a plate of spaghetti thrown at a whiteboard

The Shared Services Trap

Here's the pattern we fell into:

1. Team builds a service everyone needs (auth, notifications, whatever)
2. Other teams start depending on it
3. Original team becomes a bottleneck
4. Other teams fork it or build their own
5. Now you have 4 authentication systems

Sound familiar?

The problem wasn't technical. It was organizational.

We were treating infrastructure like product work. Every request was a "feature" that went into a backlog. Every dependency was a cross-team negotiation.

What Actually Fixed It

1. We created a Platform Team

Best hire we made all year: A VP of Platform Engineering.

Their job wasn't to build infrastructure. It was to make other teams self-sufficient.

This team built:

• Self-service deployment pipelines
• Internal developer portals (literally "AWS for our engineers")
• Paved paths for common problems (auth, caching, logging)
• Escape hatches for teams that needed something custom

The rule: If more than one team needs it, Platform builds it. And it has to be self-service.

2. Service Contracts with SLAs

We made every service owner write:

• What the service does (one sentence)
• What it doesn't do (three sentences—this was harder)
• SLAs (response time, uptime, support response time)
• How to use it (runbook, not just API docs)
• Who to contact (a human, not a mailing list)

If you couldn't write those five things, you didn't have a service. You had a code repo.

3. Architectural Decision Records (ADRs)

Every architectural decision got documented:

• Context (what problem were we solving?)
• Decision (what did we choose?)
• Consequences (what are we accepting?)
• Alternatives considered (what did we reject and why?)

This did two things:

1. Made us think before we built
2. Let future engineers understand why things are the way they are

Six months later, new engineers stopped asking "why is this so weird?" and started saying "oh, ADR-47 explains this."

4. We Stopped Pretending Microservices Were Free

Hard truth: Microservices are a team scaling strategy, not a technical scaling strategy.

We drew a line: You can build a new service if:

• Your team can support it 24/7
• It has genuine domain boundaries
• The communication overhead is worth the independence
• You've exhausted "can this just be a module?"

This cut service sprawl by 60%. Turns out, most "microservices" were just functions with API calls.

Month 9: The Culture Crisis

What Broke

This one snuck up on us.

The codebase was humming. Architecture was clean. Teams were shipping.

But something felt... off.

The early engineers were miserable:

• "We've lost what made us special"
• "It doesn't feel like a startup anymore"
• "Too much process, not enough building"

The new engineers were confused:

• "Why do the old-timers seem resentful?"
• "Are we not supposed to follow the process?"
• "Did I join the wrong company?"

We were losing people. Good people. And the reasons were always vague: "cultural fit" or "not feeling it anymore."

The Nostalgia Trap

Here's what was really happening: The early engineers missed the chaos.

Not consciously. But at 15 people, they were in every decision. They knew every line of code. They felt the pulse of the entire company.

At 80 people, they were... team leads. Senior engineers. Still important, but no longer omniscient.

They mourned the loss of intimacy and called it "culture dying."

And they weren't wrong to mourn. Something had died.

But something else had been born: A company that could actually scale.

What Actually Fixed It

This was the hardest part, and I'm not sure we fully "fixed" it. But here's what helped:

1. We Named It

In an all-hands, I said it out loud: "The startup feel is gone. That's not a bug, it's a feature."

Then I asked: "What do you miss? And what do you not miss?"

What they missed:

• Everyone knowing everything
• Fast decisions
• Feeling essential

What they didn't miss:

• Being on-call for everything
• Firefighting at midnight
• Not being able to take vacation
• Every decision being a negotiation

The conversation shifted. We weren't losing culture. We were evolving it.

2. We Defined What's Sacred

I asked the early team: "What's non-negotiable? What would make this feel like a different company?"

Their answers:

• Code quality bar (peer review, testing, no shortcuts)
• Incident response process (blameless, learn from everything)
• Technical excellence over shipping fast
• No assholes policy (zero tolerance)
• Ownership mindset (you build it, you run it)

Everything else? Negotiable.

This gave us permission to change meetings, reorg teams, shift strategies—as long as we protected these core values.

3. We Created New Rituals

The old rituals (daily standups, Friday demos, pizza lunches) didn't scale. So we built new ones:

• Monthly engineering deep-dives: One engineer presents a gnarly technical problem they solved. No slides. Just code and war stories.
• Quarterly architecture reviews: Teams present their domain. Other teams ask hard questions. Recorded for new hires.
• Biannual "State of Engineering": I share the strategy, the wins, the losses, and where we're going. Radically transparent.

These weren't replacements for intimacy. They were scaffolding for a different kind of connection.

4. We Made Space for Early Engineers to Evolve

Some early engineers became people managers. Some became Staff+ individual contributors. Some left (and we celebrated them).

The trap is expecting everyone to scale the same way the company scales.

We created paths:

• Technical track: Staff → Senior Staff → Principal (deep expertise, architectural ownership)
• Leadership track: TL → EM → Director (people, process, strategy)
• Specialist track: Stay a senior engineer forever if that's what you love

Not everyone scaled. That's okay. Scaling isn't virtuous. It's just different.

The Meta-Lesson: Systems Thinking for Humans

Here's what I learned about scaling engineering teams:

You're not scaling a codebase. You're scaling a system of humans.

And humans are weird:

• They need context, but too much context overwhelms them
• They crave autonomy, but too much autonomy paralyzes them
• They want to be heard, but too many voices create noise
• They resist process, but too little process creates chaos

The patterns that emerged:

1. Explicit > Implicit

At 15 people, implicit norms work. "We just know how things work here."

At 80 people, implicit norms become insider knowledge. New people are outsiders forever.

Write it down. Make it explicit. Make it accessible.

2. Boundaries > Flexibility

Early-stage companies pride themselves on flexibility. "We all do everything!"

That's beautiful. It's also unsustainable.

At scale, flexibility becomes diffusion. Clear boundaries create clarity.

Paradoxically, clear boundaries enable more autonomy, not less.

3. Async > Sync

Every synchronous meeting is a tax on time.

At 15 people, the tax rate is 10%. At 80 people, the tax rate is 60%.

Async isn't cold or impersonal. It's respectful of people's time and inclusive of different communication styles.

4. Pull > Push

At 15 people, you can push information to everyone. Daily standups, Slack announcements, etc.

At 80 people, push is spam. You can't read it all. Nobody can.

Build systems where people can pull information when they need it.

• Wikis, not Slack threads
• Searchable ADRs, not tribal knowledge
• Self-service portals, not tickets

5. Decisions > Consensus

Consensus scales to about 7 people. After that, it's theater.

At scale, you need decision-making frameworks:

• Who has input? (consult these people)
• Who decides? (one person, not a committee)
• How do we disagree? (disagree and commit)

The hard part: Teaching engineers that "we decided differently than you wanted" doesn't mean "we didn't listen."

The Uncomfortable Truth

Scaling isn't glorious. It's messy and painful and full of tradeoffs.

You trade intimacy for clarity. You trade speed for sustainability. You trade everyone-knows-everything for everyone-knows-their-part.

And it feels like loss.

The early engineers grieve. The founders grieve. Hell, I grieved.

But here's what we gained:

• Engineers who can take vacations without the company catching fire
• New people who can onboard in days, not months
• Systems that work when people leave (and people always leave)
• The ability to tackle problems that 15 people can't solve

We went from a team that could build fast to a team that could build big.

Different game. Different skills. Same mission.

The Playbook (TL;DR)

If you're scaling your engineering team, here's the checklist:

Communication (Months 1-3)

• [ ] Make writing the default for decisions
• [ ] Create explicit ownership (RACI for systems)
• [ ] Kill meetings that don't scale
• [ ] Build async-first communication norms

Architecture (Months 3-6)

• [ ] Create a Platform team (make teams self-sufficient)
• [ ] Service contracts with SLAs for shared services
• [ ] Implement ADRs for architectural decisions
• [ ] Set clear criteria for new services (resist microservice sprawl)

Culture (Months 6-12)

• [ ] Name what's changing (and that's okay)
• [ ] Define non-negotiable values
• [ ] Create new rituals that scale
• [ ] Build multiple career paths

Ongoing

• [ ] Explicit > Implicit (write it down)
• [ ] Boundaries > Flexibility (clarity enables autonomy)
• [ ] Async > Sync (respect people's time)
• [ ] Pull > Push (make information discoverable)
• [ ] Decisions > Consensus (one decider, many advisors)

The Question I Asked Myself

Late one night, nine months into this journey, I asked myself: "Are we still a good place to work?"

The answer wasn't simple anymore.

For early engineers who loved chaos? Maybe not. For people who wanted clarity and impact at scale? Absolutely.

We didn't preserve the old culture. We evolved into something different.

And that's not failure. That's growth.

Your Turn

If you're scaling your team right now, you're probably in pain. That's normal.

The question isn't "how do I avoid the pain?"

The question is: "What pain is worth it?"

For us, the pain of structure was worth it to avoid the pain of chaos. The pain of process was worth it to avoid the pain of firefighting. The pain of change was worth it to avoid the pain of stagnation.

What broke first when your team scaled?

I'd love to hear your stories—the messy ones, the real ones, the ones that didn't make the Medium articles.

Because that's where the real learning happens.

Written by someone who's still figuring it out, one broken system at a time.