Someone once told me that the hardest transition a team or organization of any kind goes through is the growth from around 30 people to 60 people.

At the time, I remember thinking, “Well, that’s pretty arbitrary. Surely every organization is different.” And in some ways, every organization is different. Yet, I’ve seen teams of all kinds go through growth periods like this and face the same challenges over and over. With the plethora of new companies forming every year, one would expect us collectively to have gotten better at navigating these growing pains. Yet they still occur.

It’s a classic conundrum that as any team grows, its processes and systems begin to break down, and the team is often forced to reorganize or see diminishing returns. Why does that happen every single time? Why isn’t there a perfect model that actually scales every single time? Why haven’t we found that yet?

The primary goal of any organization is to operate efficiently and productively. And to do so, it needs three things:

First, it needs to ensure that no two team members have inconsistent information at any given time, be it the roadmap, the strategy, or any other input that might affect execution. In other words, it needs consistency amongst the team.

Second, it needs to ensure that, particularly as teams become more specialized (an inevitability in a growing team), everyone can get the information they need from everyone else relatively quickly. In other words, it needs availability of everyone to everyone else.

And third, it needs to ensure that the overall organization can continue operating efficiently even if a particular piece of it becomes unavailable. It needs partition tolerance.

And yet, from my experience, and in looking at the many teams I’ve been in, invested in, or advised, achieving all three of these at the same time is virtually impossible. When one analyzes why, it becomes clear why a perfect organization model can never exist.

A classic concept in theoretical computer science is the CAP Theorem, discovered by Eric Brewer of Berkeley, which states that there are three primary benefits one would want in a distributed data store. However, one can at most simultaneously only ever have two of them.

The three benefits are the same as those mentioned above: consistency, which means that each part of the system has accurate up-to-date information; availability, which essentially means that every question gets a quick answer; and partition tolerance, which means that even if part of the system is offline, the rest continues to function as before.

Although this principle is typically applied to computer science, I’ve recently been thinking about how it’s just as relevant and true for organizations of people. In fact, as companies grows larger—particularly in a post-COVID world where many companies are bringing on employees that are not co-located—the CAP Theorem of Organizations is even more relevant than ever. Nonetheless, growing teams often think they can find structures that overcome this law, and in doing so, doom themselves to a less-than-optimal team dynamic. They’d be better served to embrace CAP and maximize their possible productivity.

Let’s say you want different parts of your team to never be out of sync with one another (i.e. for someone to be the “source of truth” of the latest information), and you want all parts of your team to be available to provide information to each other. There is only one way to achieve this: division of a team into different domains.

This is what many growing organizations do, especially when they transition out of that early stage (say, arbitrarily, 30 people) where everyone can wear many hats and be aware of all of the moving parts of the system. After a certain point, that becomes untenable, because it proves to be harder to keep all of the generalists aligned than to simply separate them into specialized roles.

In a divided, highly specialized team, the leaders are optimizing for consistency and availability (i.e. every function is up-to-speed on the latest strategy, no one is out of sync, and everyone is able to unblock and inform everyone else).

However, what suffers as a result is partition tolerance. If any one part of the organization “goes down” (be it someone goes on vacation, someone quits, someone is an under-performer, or means of communication like Gmail or Slack become unavailable), productivity grinds to a halt. There is no way to simultaneously get the consistency and availability the team wants and also ensure that it continues operating smoothly when there is a hiccup.

For fear of relying too much on any one individual or sub-team, some organizations opt instead to maximize availability (any question gets a quick response) and partition tolerance (the organization continues to function as a whole even if particular components fail). But that can only be done in one way: redundancy. Rather than specializing each individual, the team focuses on spreading out knowledge so that different people can operate in parallel. In my own startup journey, I’ve transitioned from Path 1 to Path 2 because of the realization that too much of a reliance on any one person is dangerous.

But what happens as a result of this redundancy? No consistency. The more people are able to run independently and in parallel, the less any one person is able to be the “source of truth”. That can manifest as people executing on slightly different strategies because of a lack of alignment or up-to-date information. And as a result, resources are often wasted on performing the wrong work.

The third path—least commonly used from my experience—prioritizes partition tolerance (the organization will always keep running) and consistency (meaning answers are always correct and up-to-date). But in this model of organization, the most important thing is ensuring that the system is always able to keep running and that everyone is aligned with everyone else. Imagine the documentation process in this organization: no one is allowed to read anything without a guarantee that what they’re reading is up-to-date (i.e. there’s no availability).

This model is always short-lived. In my experience, an organization that reduces the quick dissemination of information in favor of the quality and scalability of information is bound to get bogged down in heavy processes that slow productivity too much. At larger scales, this becomes entirely unsustainable.

The takeaway is a world where any time two puzzle pieces fit together, the third will never fit. I’ve seen many growing teams try to tackle these challenges head on, only to learn, as their forebears did many times before them, that they can never be fully solved. This leads to idealized solutions that break down in reality, resulting in wasted time, confusion, and reduced productivity.

Instead, as teams grow and evolve their ways of working, they’d be better suited to embrace CAP, to recognize that there is a limit to productivity in a scaling organization, and to decide which of the two-out-of-three path is best for them.