“All teams will henceforth expose their data and functionality through service interfaces.”
That is how Steve Yegge remembered the start of a mandate Jeff Bezos sent around Amazon, “back around 2002 I think, plus or minus a year.” Yegge had worked there for about six and a half years. He told the story in 2011, in a post meant for his colleagues at Google that went public by mistake.
The rest of the list, as he gave it, was strict. Teams’ software would communicate only through those interfaces. No reading another team’s data directly, no shared memory, “no back-doors whatsoever.” The technology didn’t matter: “Bezos doesn’t care.” Every interface had to be designed so it could one day be opened to outside developers.
Then item six: “Anyone who doesn’t do this will be fired.”
There was an item seven, “Thank you; have a nice day!” That one, Yegge admitted, was his own joke. Six “was quite real, so people went to work.”
Bezos’s rule drew the boundaries between services: whose code could reach whose data, and by what route. Amazon’s chief technology officer, Werner Vogels, describes how the organization was made to fit. In 1998 every development team worked on one application, and every release had to be coordinated across all of them. Amazon wanted a system built from independent services instead. “To support this new approach to architecture,” he wrote in 2019, “we broke down our functional hierarchies and restructured our organization into small, autonomous teams.” The case has the rest, including what came of it.
Turning the law around
In 1968 Melvin Conway observed that organizations that design systems produce designs that copy their own communication structure. That became Conway’s law. Martin Fowler tells of a technical leader put in charge of a new project spread across six teams in different cities. His first architectural decision: “There are going to be six major subsystems. I have no idea what they are going to be, but there are going to be six of them.”
If the law holds, it can be run backwards. Decide what shape you want the system to have, then arrange the people to match. The consultancy Thoughtworks put the idea on its Technology Radar in 2014 as the “Inverse Conway Maneuver,” which “recommends evolving your team and organizational structure to promote your desired architecture.”
The name comes from a 2010 article by Jonny LeRoy and Matt Simons about replacing old, creaky software. Their version was modest. Before rebuilding an application, they suggested, it may be worth breaking down the silos that keep a team from working together, so the new system doesn’t inherit the old one’s flaws. They added that Conway’s law speaks of “communication structures” rather than reporting lines, so there are often light ways to change who talks to whom without a reorganization.
What it costs
Moving the lines moves the costs too. At Amazon, Yegge wrote, a pager ticket might now “bounce through 20 service calls before the real owner is identified.” Every peer team became “a potential DOS attacker,” able to flood a service with requests, so every service needed quotas and throttling. Teams learned not to trust each other “in most of the same ways they’re not supposed to trust external developers.”
Fowler adds a limit. If an existing system already has a rigid structure, reorganizing the people won’t fix it right away. It is more likely to leave developers mismatched with the code, which adds friction. His advice is to change the organization and the code base together, in small steps.
The newsletters
Imagine a small publisher with four newsletters, one each on food, travel, money and gardening. All of them go through one shared editing desk. Over a year they start to sound alike: the same jokes, the same layout, the same length. The publisher wants four distinct voices. So instead of writing a style guide, it gives each newsletter its own editor, who talks to that newsletter’s writers every week and to the other editors once a month. The voices may start to drift apart. So might the costs of sharing anything between them.
Arranging the agents
People building systems out of AI agents now make the same choice on purpose. Anthropic’s Research feature uses a lead agent that plans the work and sends out subagents to search in parallel, each with its own context window. Anthropic found that this setup did especially well on “breadth-first queries that involve pursuing multiple independent directions simultaneously.”
It also found where the split stops paying. “Some domains that require all agents to share the same context or involve many dependencies between agents are not a good fit for multi-agent systems today.” Most coding tasks, it wrote, have fewer truly parallel pieces than research. And the split has a price: in Anthropic’s data, multi-agent systems used about 15 times as many tokens as chats.
So the maneuver runs in both directions with agents. Where the work divides cleanly, give each piece its own agent and a clear interface back to the lead. Where the pieces depend on each other at every step, splitting them across agents builds in the handoffs you were hoping to avoid.
Bezos’s six items never named a product. They drew the lines between teams’ services, and Amazon then reshaped its teams to match them.