There’s a thread on Hacker News asking what breaks first when an engineering team grows from 10 to 50 people. The answers are predictable: documentation, communication overhead, tribal knowledge, early hires having identity crises. All true. All missing the point.
The thing that actually breaks first is you.
The invisible routing layer
At 10 people, a good engineering leader is the connective tissue of the entire org. Not because they’re a control freak (well, some are), but because it’s just efficient. Someone asks you about a product decision from six months ago: you remember it. Two engineers are building on conflicting assumptions: you catch it in a one-on-one and fix it before it becomes a PR conflict. A new hire doesn’t know who owns the auth service: they ask you, and you tell them in thirty seconds.
You are the context routing layer. Every ambiguous question eventually reaches you, gets resolved, and you carry the resolution forward in your head. This works extraordinarily well at a small scale. It requires almost no process overhead, it’s fast, and it produces consistent decisions because one brain is making most of them.
The problem is that the team has no idea this is happening. To them, things just… work. Decisions get made. Context flows. Problems resolve.
They think the org is functional. It’s not. It’s you.
When the routing layer saturates
I remember the moment I understood this clearly back in 2010. We had grown from a single team I could hold in one meeting room to three teams with their own leads. I was excited - this was the goal. More people, more scope, more output.
What I hadn’t prepared for: suddenly there was an entire team whose daily context I no longer carried. Their lead was solid. But the questions that used to reach me invisibly - the ones I’d answer while walking to get coffee - now either got escalated through a whole chain, sat unanswered, or got answered wrong by someone filling the gap with their best guess.
The org felt slow. Decisions felt inconsistent. I kept getting pulled into things I thought I’d delegated. I blamed the leads at first. (I was wrong. And yes, I’ve done that too.)
What had actually happened: the team had grown beyond my cognitive bandwidth, and nobody - including me - had built anything to replace what I was doing unconsciously.
What you were doing unconsciously
It’s worth being specific, because the fix depends on naming it accurately.
Tanya Reilly’s “Being Glue” is the closest thing I know to a map of this territory. She wrote it for individual contributors - engineers who spend most of their time in meetings, unblocking people, noticing what got dropped - but the description fits small-team EMs almost exactly. The work is real. It’s high-impact. And it’s almost entirely invisible on a good day.
When you were the routing layer, you were doing at least four things that now need explicit structure:
Decision logging. You remembered why things were decided the way they were. Now that history lives in your head and nowhere else. The minute a decision maker is out of the loop - on vacation, in back-to-back meetings, running a different team - that institutional memory is inaccessible.
Synchronizing assumptions. You knew what each team believed about the system, the product, and the customer. When two beliefs diverged, you corrected it. Nobody else was doing this work. It was invisible because you did it continuously and informally.
Absorbing ambiguity. Every organization produces ambiguous situations constantly. At 10 people, you resolved most of them fast, in conversation, before they turned into real problems. At 30, ambiguity piles up in corners you no longer visit.
Social cohesion. You knew everyone. You knew who was frustrated, who was thriving, who needed more challenge. You maintained the team’s social fabric without anyone calling it that. (This one is the last to break, and the hardest to rebuild once it does.)
The wrong fix and the right one
The standard advice at this point is: document everything. Write it down. Build a Notion wiki. That advice isn’t wrong, but it’s treating a symptom while the disease progresses.
Documentation without ownership decays into archaeology within months. I’ve seen teams build enormous wikis that new hires learn to ignore within their first week, because they quickly discover the pages are stale and the real answers still live in someone’s head. You haven’t solved the routing problem - you’ve just created a fake routing system that gives everyone false confidence.
The real fix is to externalize the four functions above into lightweight, maintained systems - and then get out of the way enough that those systems actually get used.
Will Larson has a useful frame for this he calls “Model, Document and Share”: start doing the thing yourself, document what you learned, then share it so others can adopt it without a mandate. It was written for influencing without authority, but it applies here just as well. The goal is the same: take something that lives in one person’s head and make it reproducible.
Some of what that looks like in practice:
- Decision logs that live in the work artifacts themselves, not a separate document: in the PR, the ticket, the RFC. The closer the context is to the change, the more likely it gets read and updated.
- Team leads who are explicitly responsible for assumption synchronization between their team and adjacent teams - not because it’s on a job description, but because you’ve talked about why it matters and they’ve internalized it.
- A lightweight escalation habit: when something is ambiguous, the right move is to write down the ambiguity and make it visible, not resolve it silently and move on.
None of this is novel. What’s novel is understanding why you’re doing it: not because scale requires process, but because you were doing all of this yourself and it needs a new home.
The thing worth naming to your team
Here’s what I’ve started doing that I wish I’d done earlier: telling teams explicitly what used to happen and what needs to happen now.
Not as a lecture, just as a fact. Something like: “When we were smaller, I held a lot of context that let us move fast without much coordination overhead. We’re past the point where that scales. Here’s what I need from each of you to replace it.”
Most engineers find this clarifying rather than alarming. They suspected something was off. They just didn’t have the frame.
What they didn’t know - and what most managers never say out loud - is that the org’s apparent smoothness was load-bearing on one person. Once you name it, you can share the weight.
The HN thread will keep producing answers about documentation and communication bandwidth and Dunbar’s number. Those aren’t wrong.
But if you’re an EM watching things crack as your team grows, start by asking a harder question: what was I doing that nobody else knew I was doing?
The answer is usually longer than you expect.