Documentation Process Before 100 Engineers: The Dunbar Threshold

At ~50 engineers, informal knowledge transfer breaks. Here’s what to put in place before you cross the cliff - and why the Dunbar number explains the timing.

The meeting that shouldn’t have happened

Fourteen people on a call. Two engineering managers, four tech leads, a VP, and seven engineers who all built parts of the same platform over the past two years. The agenda: figure out why the payments team just rebuilt a fraud detection module that the risk team had already shipped eight months ago.

Nobody was incompetent. Nobody was negligent. The two teams simply didn’t know what the other had built. Their documentation lived in separate Confluence spaces, their Slack channels didn’t overlap, and the one person who had context on both - a staff engineer who’d rotated between teams - left the company in November.

Fourteen people, two hours, to discover a problem that cost the company roughly four months of duplicated engineering effort. And the root cause wasn’t a process failure. It was a scale failure. What worked at 30 engineers had silently stopped working at 70.

Why 50 engineers is the cliff

The number isn’t arbitrary. It comes from the work of British anthropologist Robin Dunbar, who studied the relationship between primate brain size and social group size. His research, now validated across dozens of human social contexts, suggests a layered structure to human relationships: about 5 intimate contacts, 15 close friends, 50 meaningful relationships, and 150 stable acquaintances.

That 50-person layer is where things get interesting for engineering organizations. Below it, informal knowledge transfer works. People know who built what. They overhear relevant conversations. They can maintain a rough mental model of the entire system and the humans behind it. Asking “who knows about the billing pipeline?” returns an instant answer from memory.

Above 50, the math breaks. The number of possible communication paths in a group follows the formula n*(n-1)/2. At 30 engineers, that’s 435 paths. At 50, it’s 1,225. At 100, it’s 4,950. The informal network that carried institutional knowledge at 30 people fragments into clusters. Teams form. Silos emerge. Not because anyone decided to silo - because human cognition can’t maintain working relationships with 100 people simultaneously.

Research from Harvard Business School found that as organizations scale past this threshold, knowledge transfer efficiency drops by roughly 50% per doubling of team size. Information that used to flow freely through hallway conversations and cross-team standups now requires deliberate systems to move.

This is the Dunbar threshold for engineering teams. And most companies don’t recognize they’ve crossed it until six months after the damage starts.

What breaks first

The failure mode isn’t dramatic. It’s a slow accumulation of friction that looks like individual problems rather than a systemic one.

Discovery dies. At 30 engineers, you can find prior art by asking around. At 80, you don’t know who to ask - or that the prior art exists at all. A 2023 McKinsey report found that engineers spend roughly 20% of their work week searching for information or waiting for answers from colleagues. That percentage climbs as organizations grow, because the information surface area grows faster than any individual’s ability to navigate it.

Decisions go dark. Small teams make decisions in shared channels, in standups, over lunch. Everyone absorbs the reasoning even if they weren’t directly involved. Past 50 engineers, decisions happen in team-specific channels, in meetings that only six people attend, in DMs between two tech leads. The decisions are fine. The visibility is gone. Three months later, another team makes a contradictory decision because they never saw the first one. We wrote about this failure mode in detail - it’s one of the most common sources of documentation rot.

Onboarding becomes archaeology. When institutional knowledge lives in people, onboarding means introductions. “Talk to Sarah about the API gateway, Marcus about deployment, Priya about the data pipeline.” At 30 people, this works. At 80, Sarah is overloaded, Marcus is on paternity leave, and Priya moved to a different team. New hires spend months doing excavation work instead of shipping code - not because documentation doesn’t exist, but because nobody can tell them which documents are current, which are obsolete, and which were superseded by a Slack conversation last quarter.

Duplication compounds silently. Without visibility into what other teams have built, parallel work becomes inevitable. A 2022 survey by Stripe estimated that the average developer spends 17.3 hours per week on maintenance tasks, a significant portion of which includes rework that could have been avoided with better knowledge sharing. In a 100-person engineering org, even a 5% duplication rate represents five engineers’ worth of wasted output per year.

What to put in place before the cliff

The instinct is to write more documentation. That’s necessary but insufficient. The real challenge isn’t volume - it’s structure, discoverability, and maintenance. Here’s what actually works, ordered by impact relative to effort.

1. Decision records as a team norm

The single highest-leverage documentation practice is capturing decisions at the point they’re made. Not architecture docs. Not design specs. Decision records - short documents (two to four paragraphs) that capture what was decided, what alternatives were considered, and why this option won.

The format matters less than the habit. ADRs (Architecture Decision Records), RFCs, even a structured Slack template - pick one and make it a team norm. The critical constraint: it has to take less than ten minutes. Anything longer and adoption craters within a month.

A team of 50 engineers making five decisions per week generates 260 decisions per year. Even capturing half of those creates a searchable trail that prevents the “why is this built this way?” question from requiring a 30-minute call with someone who may or may not still work here.

2. An ownership registry

At scale, knowing who owns what matters as much as knowing how it works. Create and maintain a mapping of systems to teams to individuals. This isn’t a static org chart - it’s a living document that answers: if I have a question about service X, who do I talk to?

The best implementations are machine-readable (YAML or JSON in a repo, not a wiki page) and integrated into the developer workflow. GitHub’s CODEOWNERS file is a starting point, but ownership extends beyond code. Who owns the runbooks? The API contracts? The integration with the third-party vendor?

3. A documentation lifecycle process

Most documentation fails not at creation but at maintenance. A page written eighteen months ago might be accurate, outdated, or actively dangerous - and there’s no way to tell without reading it carefully and checking against the current codebase.

Put three things in place. First, expiration dates - every document gets a review-by date, typically 90 days for operational docs, 180 days for architectural ones. Second, ownership - every document has a named owner (a team, not a person) responsible for keeping it current. Third, deprecation signals - a clear mechanism for marking documents as superseded, with a pointer to what replaced them.

This sounds bureaucratic. It isn’t. Without it, your documentation corpus grows monotonically while its accuracy degrades, and engineers learn to distrust it entirely. That’s the path to a culture where nobody knows where the documentation is - or worse, nobody bothers to look.

4. Cross-team knowledge rituals

Documentation captures what’s known. Rituals distribute it. Two formats that work at the 50-100 engineer scale:

Weekly architecture digests. A curated summary (email or Slack post) of significant technical decisions, new services, deprecated patterns, and upcoming changes. Five minutes to read. Edited by a rotating author from a different team each week. This creates ambient awareness that hallway conversations used to provide.

Monthly tech talks with Q&A. Not conference-style presentations. Informal 20-minute sessions where one team explains something they built, a problem they solved, or a mistake they made. The value isn’t the talk itself - it’s the cross-pollination. “Oh, we had that exact problem last quarter” is how you prevent duplicated work.

5. Connected knowledge, not more pages

The deeper structural problem is that most documentation tools treat knowledge as a collection of independent pages. But engineering knowledge is a graph. A decision about API versioning connects to the team that made it, the services it affects, the incident that prompted it, and the earlier decision it replaced.

When those connections are invisible, engineers can’t navigate from what they know to what they need. They find one page but miss the three related pages that provide the context to actually use it. Building a documentation process that preserves relationships between artifacts - not just the artifacts themselves - is what separates teams that scale knowledge from teams that just accumulate documents.

The timing matters more than the execution

Here’s the uncomfortable truth: every practice listed above is straightforward. None requires exotic tooling or months of implementation. The reason most companies don’t have them isn’t complexity - it’s timing.

At 30 engineers, these practices feel like overhead. The informal network works fine. Writing decision records when you can just ask the person feels bureaucratic. Maintaining an ownership registry when everyone knows who owns what feels redundant.

At 80 engineers, these practices feel urgent but implementing them means backfilling months or years of missing documentation while simultaneously trying to keep up with current decisions. The gap between what’s documented and what’s known has grown so wide that closing it requires a dedicated effort most teams can’t afford.

The window is between 40 and 60 engineers. Before the informal network fully breaks but after the early signs appear - the repeated questions, the duplicated work, the same problems surfacing in different teams. That’s when the investment-to-impact ratio is highest.

If your engineering org is approaching that threshold, or if you’ve already crossed it and feel the friction, the first step is an honest audit. How many of your critical systems have documentation that a new hire could follow without calling someone? How many decisions from the last six months are findable by someone who wasn’t in the room?

That’s the kind of structural knowledge problem we built Nexalink to solve - turning scattered, disconnected documentation into a navigable knowledge graph where decisions, systems, and ownership are linked and searchable. But whether or not you use our tool, start with the audit. The number will tell you how much time you have left before the cliff.