Engineers have spent decades getting good at scaling code. We have horizontal scaling, distributed consensus, sharding, caching, autoscaling — a whole toolkit for making systems handle more load by adding more capacity. Then we apply the same intuition to teams, add more people, and watch productivity decrease. In this InfoQ presentation, Charlotte de Jong Schouwenburg — co-founder of Bravely, business psychologist, and longtime coach to high-growth tech companies — explains why human teams don't scale the way software does, and what leaders can actually do about it.
Human Scalability vs. System Scalability
The opening framing is sharp: adding capacity is how you scale software, but it is rarely how you scale humans. Where a software system gains throughput by adding nodes, an organization tends to lose throughput when it adds people, at least temporarily — and sometimes permanently if the scaling is mishandled.
The reason is that humans aren't stateless workers. They depend on:
- Shared context. What's being built, who's responsible, what was decided last quarter.
- Trust. Whether colleagues will catch the ball you drop or use it against you.
- Communication channels. The actual paths information has to travel between people who need it.
All three of these degrade non-linearly as headcount grows. Double the team, and the number of relationships to maintain quadruples. Context that used to live in a single Slack channel now has to be deliberately propagated. Trust that was built across a kitchen table now has to be engineered.
Human Bottlenecks in Hyper-Growth
Charlotte coins a useful term: "human latency." It's the lag introduced by scaling people without scaling the surrounding social infrastructure. Symptoms include:
- Decisions taking weeks because nobody's sure who owns them.
- The same questions getting asked in five different rooms.
- Cross-team work blocked on coordination meetings that exist mostly to share context.
- Increasing distance between leaders and engineers, with information distorted at every layer.
Hyper-growth amplifies all of these. Onboarding speed plateaus, then regresses. Trust thins. Subcultures fragment into "us vs. them." None of this shows up cleanly in a productivity dashboard, but every leader has felt it.
Why More Process Isn't the Answer
The natural reflex is to add process — RFCs, status meetings, OKR cascades, escalation paths. Some of this helps. Most of it just adds friction without addressing the underlying issue.
Charlotte's argument, drawn from organizational psychology, is that human scalability is constrained by three things process alone can't fix:
- Communication structure — who actually talks to whom, and how information flows across silos.
- Distributed trust — whether people who've never worked together are willing to extend goodwill.
- Collaboration habits — the small rituals and norms that make working together fast and low-friction.
Tools and processes can support these, but they cannot substitute for them. A perfectly designed RFC template doesn't help if engineers don't trust each other enough to comment honestly.
Engineering Trust at Scale
The strongest part of the talk is the practical playbook for engineering trust into a growing organization rather than hoping it emerges. Key strategies:
- Communication architecture. Explicitly design how information flows. Which forums exist, what they're for, who's expected in them, and what gets escalated where. Treat it with the same rigor you'd treat system architecture.
- Cross-silo relationships. Invest in deliberate connection across teams — rotations, embedded engineers, shared rituals — to reduce "us vs. them" dynamics before they harden.
- Rituals for alignment and retrospection. Weekly or monthly cadences specifically aimed at sharing context and surfacing friction. Without ritual, drift accumulates silently.
- Transparency and empathy as norms. Hard conversations, public decisions, and explicit acknowledgment that other teams have constraints you don't see.
- Psychological safety as a delivery mechanism. Not as a soft, optional culture goal — but as the precondition for honest reporting, fast learning, and risk-taking.
Early Warning Signs
Charlotte highlights signs to watch for before things visibly break:
- Rising misalignment. Teams making consistent decisions that contradict each other.
- Fragmented behaviors. Different teams optimizing for different things without anyone reconciling them.
- Antagonistic subgroups. "Engineering vs. product," "infra vs. apps," "EU vs. US." When language hardens into camps, the culture is already fragmenting.
- Burnout in the connectors. The people who informally hold things together — the senior ICs and managers translating across silos — often burn out first. When they leave, hidden coordination collapses.
The framing is important: these are not interpersonal problems to be solved one HR conversation at a time. They're organizational signals to be addressed structurally.
Examples from the Field
Charlotte draws on her work with tech scale-ups like Bynder, DataSnipper, and WeTransfer. Recurring themes:
- Structured cross-team check-ins as a default rather than an exception.
- Explicit conflict resolution guidelines so disagreement is normal and recoverable.
- Transparent feedback systems that let leaders surface drift before it escalates.
- Pairing rapid hiring with equally rapid investment in onboarding context-sharing rituals — not just process documents.
Final Takeaways
The single most important reframing in this talk is that you cannot scale people the way you scale software. Adding capacity doesn't add throughput — at least not without proportional investment in trust, communication, and ritual.
The leadership implications:
- Treat human scaling as a design problem, not a recruiting problem. Communication architecture deserves the same care as system architecture.
- Build psychological safety before you need it. It's load-bearing during hyper-growth, and it can't be bolted on after fragmentation begins.
- Watch the connectors. The informal bridges between teams are your most fragile and most valuable assets.
- Adapt continuously. Team structures, communication flows, and culture all need to evolve as the organization grows; what worked at 30 people will silently break at 150.
The real competitive advantage in scaling engineering organizations isn't a clever org chart or a slicker process. It's the daily practice of building a place where humans can keep working together effectively as the system grows around them.
Reference: The Human Scalability Problem: Why Your Teams Don't Scale Like Your Code