The River

In 1966, Bob Taylor had a plumbing problem. Not literally, but the metaphor holds. Taylor was the director of the Pentagon's computer research office — the IPTO, within ARPA — and in a small room adjacent to his office he had three terminals. One connected to MIT. Another to Berkeley. Another to Santa Monica. Each with its own operating system, its own programming language, its own access procedure. Three pipes that never met.

"It became obvious", he would say years later, "that we ought to find a way to connect all these different machines."

ARPANET was born out of that frustration. Not from a military plan to survive a nuclear attack — that's a myth Taylor chased for years without success — but from the everyday annoyance of a man who wanted information to flow and couldn't make it happen. The scene is recorded in Where Wizards Stay Up Late, Katie Hafner and Matthew Lyon's chronicle of the origins of the internet.

Twenty years later, in another office at another research center, the story repeated itself. Tim Berners-Lee worked at CERN, surrounded by systems that didn't talk to each other: VAX/NOTES, CERNDOC, ENQUIRE, IBM GroupTalk, uucp News. His March 1989 proposal, sketched in a diagram now preserved as a museum piece, proposed unifying them under a concept he called Mesh. A supervisor wrote in the margin: "Vague but exciting." Not long after, Mesh changed its name. It was called World Wide Web.

Both scenes are versions of the same gesture: someone looks at a map of separate channels and decides that there has to be a river.

Mesh, mess

The word Berners-Lee chose is interesting. Mesh — net, web, fabric — suggests connection without hierarchy. A space where things touch each other without a center to order them. Not a tree, not a pyramid: a weave.

Anyone who works today building digital products will recognize something familiar in that weave. The cyberspace Berners-Lee helped create is effectively a mesh: distributed, interconnected, without clear borders, in continuous change. But that same word — mesh — sounds suspiciously close to another: mess. Disorder. Chaos.

It isn't an etymological coincidence — they come from different roots — but it is a functional one. What begins as a designed mesh often ends up feeling like a mess. Not because someone did it wrong. But because the nature of the space produces it.

The law

In 1968, a year before the first ARPANET node was installed, a mathematician named Melvin Conway published a short article in Datamation. It was titled How Do Committees Invent? and contained an observation that has become one of the most cited laws in software engineering:

"Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization's communication structure."

Conway wasn't talking about the internet. He was talking about COBOL compilers. But his observation worked at any scale. What he was saying was that you can't separate what you build from how you organize yourselves to build it. The organization's communication structure is printed onto the product like a watermark. If you have five teams, your system will have five modules. If two teams don't talk to each other, their components won't integrate well. It isn't a tendency: it's a homomorphism. A mathematical structural correspondence.

What's most provocative about Conway isn't the diagnosis. It's what follows from it. If the organization gets copied into the product, and the product changes constantly — as any digital product does —, then the organization has to be able to change with it. Conway put it clearly in his conclusion: "flexibility of organization is important to effective design." He was saying this in 1968, before agile, Scrum or Spotify existed.

The current

But there is something deeper in Conway's law that goes unnoticed when it is treated as a curiosity of software engineering. And it has to do with the word stream.

In English, stream is both a current of water and a current of data. River and information share a name. It isn't a linguistic accident: it's a hint about the nature of the space. What flows in a digital product is information. What flows inside the organization that builds it is also information: conversations, decisions, documents, code, data. The thing you work on and the thing you work with are the same.

This marks a radical difference from any previous industry. A construction company coordinates with blueprints, meetings and contracts, but produces concrete and steel. A hospital runs on medical records, protocols and shifts, but its output is the physical health of a patient. A law firm works intensively with information, but its final product — a contract, a ruling, an executed merger — lives outside the medium in which it was organized. In all these cases, the substance of the organization and the substance of the product are distinct. They touch, they influence each other, but they don't become the same thing.

And yet, something is changing in all of them. As the construction company manages its sites with software, as the hospital digitizes its clinical processes, as the law firm automates contract review, each of these industries starts to face problems that only digital product companies used to have. Coordination becomes harder. Technical teams and business teams stop understanding each other. The organizational structure starts to imprint itself on the software they produce — exactly as Conway described. The river reaches them. Not because they've decided to become tech companies, but because software, once it enters, brings its nature with it: the nature of a medium that doesn't distinguish between what you are and what you produce.

An organization native to digital products simply lives in that reality from the start. It is made of communication — Slack, repositories, documents, tickets, calls — and it produces communication — software, APIs, interfaces, data flows. The medium of the organization and the medium of the product are indistinguishable. Conway isn't a clever analogy: it's almost a tautology. Of course the communication structure gets copied into the product. They're made of the same stuff.

Peter Drucker saw this coming before anyone else. When he coined the term knowledge worker in 1959, he was pointing exactly at this mutation: the worker no longer transforms matter into product, they transform information into information. And that changes everything.

"The knowledge worker cannot be supervised closely or in detail. He can only be helped. But he must direct himself, and he must do it toward performance and contribution, that is, toward effectiveness."

— Peter Drucker, The Effective Executive

In the traditional logic of any of those industries, the worker operates on a material that is different from the medium in which they are organized. The bricklayer lays bricks, the surgeon operates on tissue, the lawyer drafts clauses — but none of them is made of the same material as their product. There is a natural separation between the organization and what it produces. That separation allows for a certain kind of management: the manager designs the process, the worker executes it on the material. But once software enters the scene — whether as the main product or as infrastructure that runs through the whole operation — that separation begins to dissolve. The knowledge worker doesn't execute a plan — they contribute to a flow. And the flow is the same substance the organization is made of. That's why no industry that substantively incorporates software can keep managing itself with the models that worked when organization and product lived in separate media. It isn't a matter of style or management philosophy. It's a matter of physics: the material doesn't allow it.

Entropy

Drucker, who had a gift for sentences that seem obvious until you think about them twice, also wrote:

"Only three things happen naturally in organizations: friction, confusion, and underperformance. Everything else requires leadership."

— Peter Drucker, Managing Oneself

It's a sentence about social thermodynamics. The natural state of an organization isn't order — it's entropy. Left to itself, any organization degrades. Not because people are bad or incompetent, but because complexity grows faster than the capacity to coordinate it. Conway had already described it as a three-step process: first, the temptation to assign too many people; then, the fragmentation of communication paths as the organization grows; finally, the homomorphism that guarantees that fragmentation is transferred to the system.

On an assembly line or in an operating room, entropy is fought with processes. You standardize. You measure. You tighten nuts. But in the digital space — in the river — process isn't enough. Because what you produce isn't static. And because, as we saw, the material the organization is made of and the material it produces are the same. Entropy doesn't only degrade the operation: it directly degrades the product. Horowitz's cultural bugs and Catmull's invisible impediments aren't management problems that indirectly affect software. They are problems of the same medium as software.

The invisible code

Digital product organizations know this, or at least they intuit it. They've spent years trying to find ways of organizing that respond to the nature of the space they operate in. The names keep changing — squads, tribes, cross-functional teams, platform teams — but the underlying problem is always the same: how to make the structure not be a dam that slows the current.

Ben Horowitz expressed it with a metaphor that speaks directly to this difficulty:

"That's the nature of culture. It's not a single decision—it's a code that manifests itself as a vast set of actions taken over time. No one person makes or takes all these actions. Cultural design is a way to program the actions of an organization, but, like computer programs, every culture has bugs. And cultures are significantly more difficult to debug than programs."

— Ben Horowitz, What You Do Is Who You Are

Culture is code. But it's code that executes in a distributed way, without a compiler, without tests, without logs. When something fails, no error appears on screen — a meeting that shouldn't exist appears, a decision no one takes, a team that doesn't feel ownership of anything.

Ed Catmull, from Pixar, described the other side of the problem with unusual honesty:

"We start from the presumption that our people are talented and want to contribute. We accept that, without meaning to, our company is stifling that talent in myriad unseen ways. Finally, we try to identify those impediments and fix them."

— Ed Catmull, Creativity, Inc.

Catmull's starting point isn't that people fail. It's that the organization holds them back without meaning to. The talent is already there. The impediments are invisible. And the job of leadership isn't to design culture from above, but to remove the obstacles that prevent it from flowing.

Topologies of flow

It isn't a coincidence that the digital product industry has produced, in recent years, its own literature on how to organize. It's a symptom. When a field needs that many books on a single topic, the topic isn't solved.

Matthew Skelton and Manuel Pais published Team Topologies in 2019. Their proposal organizes teams into four types: stream-aligned teams, platform teams, enabling teams, and complicated-subsystem teams. What matters isn't the taxonomy — there are many — but the name they give the fundamental team: stream-aligned. Aligned with the current. It's the same word — stream — that names both the river and the flow of data. And it isn't accidental. What Skelton and Pais are saying, perhaps without fully meaning to, is that the team that delivers value must recognize that it is already in the water. It isn't about positioning yourself against something external. It's about accepting that organization and product are made of the same substance, and organizing yourself accordingly.

Amy Edmondson published The Fearless Organization that same year. Her argument attacks the problem from another angle: if the digital space is inherently uncertain — if problems are weakly defined, if the product keeps changing, if no one has all the answers — then you need people to be able to be wrong without fear. Psychological safety isn't a humanistic luxury. It's an operational condition. Without it, information doesn't flow, mistakes are hidden, and the organization goes blind to its own cultural bugs.

Without that foundation, it doesn't matter what leadership style you try to practice.

That these two books appeared almost simultaneously is no coincidence. They are complementary responses to the same problem: how to build organizations that can bathe in the river they inhabit without drowning.

Leadership rewritten

In December 2025, Lenny Rachitsky's podcast — probably the most influential in the product ecosystem — published a conversation with Matt MacInnis, CPO of Rippling. The title was provocative: "10 contrarian leadership truths." Among the ideas: deliberately under-resource projects. Fight entropy with energy and intensity. Don't assume that adding people adds productivity. Among the references cited: Conway's Law.

A 2025 podcast quoting a 1968 paper on COBOL compilers. The industry has spent almost sixty years discovering the same thing by different paths.

What MacInnis describes as "counterintuitive" is only counterintuitive if you come from industrial logic. In the logic of the river, it makes total sense. A small committed team reads the current better than an army of rowers. Conway had already written it: two people, if well chosen and if they survive the experience, will produce a better system than a hundred. The assumptions that serve to peel potatoes and lay brick walls don't serve to design systems.

Satya Nadella distilled it in a sentence that seems simple:

"Leaders are those who step up, not those who shout the loudest."

In an environment where problems aren't predefined and solutions aren't linear, leadership can't be directive. It has to be emergent. Not the one shouting loudest from the bank, but the one who steps into the water and reads the current. The six leadership styles that Daniel Goleman describes — coercive, authoritative, affiliative, democratic, pacesetting, coaching — aren't options to pick one from. They are registers to combine according to what the moment demands. A leader who only knows how to shout "do as I say" can work in a crisis. But if that's their only register, they will dry up the river.

The river

There is a way of reading the history of digital products as a technical progression: from mainframes to the internet, from the internet to mobile, from mobile to the cloud, from the cloud to artificial intelligence. That reading is correct but incomplete.

The other reading — the one I'm trying to trace here — is organizational. Ever since Taylor connected those three terminals, the people who build digital products have been learning that the space they work in doesn't behave like a factory. It isn't predictable. It isn't linear. It can't be managed with static org charts or fixed processes. It is a river: it flows, it changes course, it drags what it finds, it erodes rigid structures, it rewards those who adapt.

The tensions that product organizations live with — between autonomy and alignment, between speed and quality, between structure and flexibility — aren't signs that something is broken. They are the natural consequence of building inside a space that is, by nature, fluid. Conway's Law is a natural law of this space: your organization gets printed onto what it builds. If your organization is rigid, your product will be rigid. If your organization flows, your product will flow.

The constant publication of books, frameworks and podcasts on how to organize product teams isn't a sign of the discipline's immaturity. It's the opposite: it's the sign that the discipline has understood that the organizational problem is inseparable from the technical one. That you can't build well if you don't organize well. And that organizing well, in this space, doesn't mean finding the perfect structure and staying in it. It means keeping the capacity to change when the river changes.

Berners-Lee called his proposal Mesh. A net. What we build on that net often feels like a mess. A tangle. The temptation is to look for order, for control, for the nut that gets tightened at the right pace. That temptation must be balanced with a joyful surrender to bathing in the river.