The three-body problem is chaotic with a single force. A software team runs on half a dozen, and Conway’s law copies whatever that produces straight into your architecture. Here is the physics, the counting, and what an engineering leader can do about it.

The three-body problem: one force, still no closed-form solution

Two bodies under gravity have a closed-form solution. Three do not. Poincaré showed in 1890, in a 270-page memoir in Acta Mathematica, that the general three-body problem has no analytic solution and that its trajectories depend sensitively on initial conditions: change a late decimal in a starting velocity and the system ends up somewhere else entirely.

Sundman found a convergent series solution in 1909. It converges so slowly that nobody has ever used it to compute an orbit. The problem is “solved” and useless at the same time, which is a sentence most CTOs could put on a reorg slide.

And this is the easy case. Gravity is one force, always attractive, symmetric by Newton’s third law, with one constant and one parameter per body: mass. Everything else follows from positions and velocities. If three idealised point masses under the most polite force in the universe are chaotic, I would not bet on three people.

Why a software team is harder than the three-body problem

Put three engineers in a room and gravity is the least of their problems. Each of them is a body acted on by ego, ambition, incentives, fear, trust, and the educational distance between them: the PhD and the bootcamp graduate do not parse the same sentence the same way. Most people who reach for this analogy stop at “more forces, more complexity”. I think that undersells it. The human forces are not more of the same; they belong to a different class.

  • They are not symmetric. How much A defers to B has nothing to do with how much B defers to A. Newton’s third law does not hold in a standup.
  • They change sign. Trust attracts, fear repels, and the same relationship flips between the two inside a quarter. Gravity has never once pushed.
  • They are not conservative. A reorg, a promotion, a new hire inject energy into the system. Nothing is preserved, so there is no invariant to reason from.
  • The forces interact. Ambition amplifies ego; an educational gap distorts how incentives are read. In physics the forces simply add. Here the force law itself depends on the state.
  • The bodies read the simulation. People react to the model you build of them. No planet has ever changed its orbit because it saw the orbit on a slide.

So the honest comparison is not three bodies versus ninety. It is three bodies under one well-behaved force versus ninety bodies under half a dozen badly behaved ones, each with its own coupling constant per pair. The counting in the next section is the conservative version of the story.

Counting team complexity: pairs, forces and coalitions

Fred Brooks gave us the first number in The Mythical Man-Month, the 1975 book that also gave Conway’s law its name: n people have n(n−1)/2 communication channels. That is the gravitational count, one force per pair, and it is quadratic: 3 channels at three people, 66 at twelve. Give each pair six forces instead of one and you are at 396. Still quadratic, still fits on a whiteboard.

What is not quadratic is the number of ways the bodies can group. Any subset of two or more people can act as a unit: an alliance, a faction, “the backend people”. That is 2ⁿ − n − 1 coalitions: 4 at three people, 4,083 at twelve. The number of ways a team can partition itself into such groups, the Bell number, is 4,213,597 at twelve.

Log-scale chart of interactions versus team size from 2 to 12 people: pairwise channels n(n−1)/2, the same times six human forces, and coalitions 2ⁿ−n−1; at twelve people 66 pairs become 4,083 coalitions
Interactions by team size, log scale. Pairs grow with n²; coalitions grow with 2ⁿ.

The pairwise channels are the part leaders count and manage. The coalitions are the part that decides what actually ships, and nobody has them on a chart.

Conway’s law: the org graph becomes the architecture

Conway’s 1968 paper, How Do Committees Invent?, observed that a system’s design copies the communication structure of the organisation that built it. It is usually quoted as a warning about team boundaries. Read it next to the previous section and it says something stronger: the chaotic trajectory of the human n-body system is not the backdrop to your architecture, it is the compiler that produces it.

Diagram: three bodies under one force, eight people under six forces (ego, ambition, education, incentives, trust, fear), and the system with eight modules and 28 interfaces that Conway’s law predicts
Three graphs: three bodies under gravity, eight people under six forces, and the eight-module system Conway’s law predicts.

The left graph is solvable in principle and chaotic in practice; the middle one is neither; and Conway’s law says the right one inherits the middle one’s shape, forces included.

Conway himself named one of the forces. Marianne Bellotti’s rereading of the paper in USENIX ;login: (2020) points out that his mechanism was never the org chart as such but incentives: how people get ahead in an organisation decides which technical choices look attractive to them. The law was about human forces from the start. We flattened it into a statement about boxes and lines.

The forces never show up in the source code, but the decisions they produced do. The module nobody wanted to own. The interface that exists because two leads stopped talking in March. The service two coalitions built in parallel, each convinced the other would never ship. Every one of those is a trajectory the one-force model could not have predicted, frozen into a repository.

Five lessons from physics for organisational design

Physicists did not stop working on gravity when Poincaré proved there was no formula. They changed what they asked of it. Five of their moves translate directly.

Find the hierarchical configurations. The restricted three-body problem is tractable when one mass dominates and the third is negligible; triple-star systems are stable when the inner pair is tightly bound and the third body orbits far away. Translation: cohesive teams, loosely coupled to each other, with an unambiguous owner at every boundary. Team Topologies (Skelton and Pais, 2019) calls this stream-aligned and platform teams. Astronomers called it a hierarchical triple a century earlier.

Reduce n. A system with fewer bodies is not approximately easier, it is categorically easier. Bezos’s two-pizza rule and Dunbar’s inner circle of roughly five to fifteen are the same observation from two directions: below a certain n, the coalition count stays small enough for the team to hold it in its head.

Reduce k. You cannot remove ego from a person, but you can stop it acting across a team boundary. Shared incentives, a shared vocabulary (an ontology, in my language) and trust built over time each delete a force term from the cross-team equation. Educational distance is the force most often ignored: two teams that use the same word for different things are in a close encounter whether they know it or not.

Make the interfaces carry the coordination. In a stable hierarchical system the far body never meets the inner pair; it only feels their combined field. The organisational equivalent is a contract rich enough that the consuming team never needs the meeting. This is where I come back to my own doctoral research at NTUA on autonomous agents and web APIs: an API that advertises its affordances, what you can do next and under which conditions, lets an autonomous agent traverse it without a human in the loop. The same property lets an autonomous team traverse it without a Slack thread. I argued in We Fixed the Engine and Threw Away the Map, and again in Amazon Never Went MCP-First, that we are replacing structured traversal with exhaustive search between machines. We have done it between teams for decades. We call it alignment meetings.

Set the initial conditions. In a chaotic system the initial conditions are the only variable you control completely. Team Topologies’ Inverse Conway Maneuver says it plainly: design the organisation for the architecture you want, before the architecture exists, because afterwards the law runs the other way. MacCormack, Baldwin and Rusnak measured the effect in Research Policy (2012): across matched pairs of open-source and commercial products, loosely coupled organisations shipped more modular code than tightly coupled ones, with coupling that differed by up to a factor of six.

Shape it, do not solve it

Nobody will ever solve the n-body problem for your organisation. Not you, not the consultancy, not the next reorg. The forces are too many, too asymmetric and too reactive. What the physics teaches is to stop asking for the trajectory and start shaping the system so that most trajectories end somewhere acceptable: small n, few forces crossing a boundary, hierarchical separation, and contracts that make the meeting unnecessary.

We are very good at modelling gravity. We do not model ego, ambition or the distance between a PhD and a bootcamp at all. Conway’s law says the system will model them for us, in production, whether we drew the graph or not. Better to draw it first.

If this was useful, subscribe to APILama to get the next essay in your inbox. No hype, just what I learned the hard way.


Discover more from APILama

Subscribe to get the latest posts sent to your email.

Leave a Reply

Trending

Discover more from APILama

Subscribe now to keep reading and get access to the full archive.

Continue reading