I Spent Years on How Machines Coordinate. Then I Started Thinking About Us.

For most of my career I worried about agreement. Not the human kind (I’m an engineer, so I mostly got to skip that one), the machine kind. When you build concurrent systems, the hardest problems are almost never about a single processor doing a single thing fast. They’re about coordination: how do you get a dozen cores, each running at its own pace, each holding its own private copy of the truth in its own cache, to behave as though they share one coherent reality? There’s no conductor in there, no global clock, nothing waving a baton. No core is in charge. The illusion of a single, consistent memory that every thread can trust is one of the most elaborate negotiations in modern engineering, and it holds together right up until the moment it doesn’t, which is usually under load, usually at the worst possible time. I spent years learning to think in those terms, and I assumed those terms belonged to silicon. But perhaps they don’t.

That small realization has reorganized most of what I now find interesting, and it’s the reason I’ve decided to write this series; in it, we’ll explore how the same thinking applies to people, leadership, and how we communicate. At first glance, many of the questions an architect learns to ask about machines are exactly the ones worth asking about people, about the organizations they form, about whole societies, just pointed one level up (same questions, bigger boxes). How do independent agents coordinate without a central authority telling each one what to do? What does a shared abstraction conveniently hide, and who pays when the hidden thing surfaces? Where does a system that worked fine yesterday quietly lose coherence as you scale it? I used to ask those about coherence and parallel systems in general. Now I want to ask them about newsrooms, markets, classrooms, and the feeds through which a billion people assemble their picture of the world. The vocabulary transfers almost unchanged. I keep waiting to find the seam where the analogy breaks down, and I keep not finding it.

Consider the simplest possible object on a control panel: a button. Press it, and a result appears. A button is a promise that you don’t need to understand what lies beneath it in order to act through it, and most of the time that promise is a gift; it’s literally Pavlovian. You shouldn’t have to understand fuel injection to drive to work, or packet routing to send a message across an ocean. Civilization runs on the fact that nobody reasons from first principles about everything beneath their daily life. But every button hides a world. It compresses an enormous causal chain into a single gesture, and in doing so it decides which parts of reality you’re allowed to see and which simply vanish beneath the abstraction. A map hides terrain. A dashboard hides the argument that produced its numbers. A generated answer hides its own uncertainty. The power you gain at the surface is paid for with distance from the substrate, and that trade is so consistently worthwhile that we forget we’re making it at all. Things go wrong when someone forgets the button is a button. The map gets mistaken for the territory, the output for the truth, and now you’re debugging reality with the wrong mental model.

Here the engineering frame and the human frame line up, because the deepest claim about media was always architectural. When Marshall McLuhan wrote that the medium is the message in Understanding Media in 1964, the line got worn smooth into a slogan, but the real argument underneath it is one any systems person recognizes at once. McLuhan’s point was that a medium’s real effect has little to do with the content it carries. What matters is the change of scale, pace (rhythm), and pattern the medium introduces into human affairs. The container reshapes whatever it contains. A society organized around oral memory grows different minds than one organized around print, and one organized around the algorithmic feed grows different citizens than one organized around the long argument. That’s not a claim about messages. It’s a claim about architecture, about what a structure rewards and what it starves, and it’s the same kind of claim I’d make about why one caching strategy produces a fast, fragile system and another a slow, durable one. The structure is the message. The structure is almost always the message.

There’s an even cleaner bridge between the two worlds, and it comes from inside computing itself. In 1968 the programmer Melvin Conway published an observation now known as Conway’s Law: “organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.” Read that twice, because it runs in both directions at once. The shape of a piece of software ends up mirroring the shape of the human organization that built it. Three teams that rarely talk will ship three awkwardly integrated parts, with a bug living in every seam where the conversation didn’t happen. The communication structure of the people becomes the architecture of the artifact. That’s a statement about machines that’s entirely a statement about people, and it has stuck in my head for years precisely because it refuses to stay on one side of the line. If the way a group of humans coordinates determines the systems they can build, then studying coordination isn’t a detour from architecture, it’s the foundation of it.

Once you start looking, the resource you think you’re short on is rarely the one that’s actually binding. Herbert Simon saw this in 1971, well before the feed existed, when he noticed that a wealth of information creates a poverty of attention: once information is everywhere, the thing in short supply is attention, and whoever controls what gets attended to controls a great deal else.¹ Engineers know this instinct in our bones. We learn, often the hard way, that the bottleneck is almost never where the dashboard says it is. You add cores and the program doesn’t speed up, because cores were never the bottleneck. Same with people: drown them in information and they don’t get wiser, because information was never what they were short on. The discipline of finding the true constraint, the one thing actually governing the behavior of the whole, is the same discipline whether the system is made of transistors or of human beings deciding what to believe.

I’m not claiming people are computers (they’re not, and the differences matter more than the likeness). Minds and institutions aren’t deterministic; the resemblance between coordinating machines and coordinating people is a structural one that illuminates, not a law that predicts. What I’m claiming is narrower and, I think, more useful. The habits of mind that let you reason about a system you can’t fully see, that let you ask what a layer is hiding and where it will break and who inherits the failure, don’t expire at the edge of the hardware. They’re general-purpose tools for thinking about anything built out of parts that have to agree. This series is my attempt to point those tools, patiently, at the architectures that increasingly decide how we think and what we’re shown. I’ll move slowly and stay concrete, and I’ll try to earn each claim instead of just asserting it. The promise isn’t that any one of these pieces will resolve the big questions. It’s that we’ll keep our eye on the world the button hides, and keep asking who built it and why. In the next pieces I’ll point these tools at specific systems, one at a time. If I get something wrong, tell me.

Sources & Further Reading

• Melvin Conway, “How Do Committees Invent?” (1968): the original statement of Conway’s Law (Datamation, April 1968), in the author’s own archive; the elegant proof that the shape of a system mirrors the communication structure of the people who built it.
• Marshall McLuhan, Understanding Media: The Extensions of Man (1964): the source of “the medium is the message,” whose real argument is that a medium’s effect lies in the change of scale, pace, and pattern it introduces.
• Herbert A. Simon, “Designing Organizations for an Information-Rich World” (1971): the essay that diagnosed attention, not information, as the scarce resource once information becomes abundant.

Footnotes

1. Likewise, spin up a dozen different channels for the same information (bug dashboard + commit dashboard + doc comments + email + chat) and you effectively have none. Each one you add splits the attention paid to the rest, so as the number of channels climbs, the attention on any single one drives to zero. ↩