Conway’s Law is nearly sixty years old, and it has never stopped being true. The structure of your software will mirror the structure of the organization that built it.

Luca Bonmassar laid out the tradeoff cleanly. Small, distributed teams that are loosely coupled but tightly aligned drift toward microservices almost by design. That’s the Netflix setup. Fewer, larger teams optimizing for reuse and stability converge on something closer to a monolith. Neither outcome is free. Small teams pay for speed with a web of cross-team dependencies. Big teams pay for stability with slower movement.

The Inverse Conway Maneuver, and why smart CTOs use it

Asked whether he had ever applied the inverse of Conway’s Law in practice, Luca’s answer was yes, repeatedly: when developing a new architecture, you start with org design, so that the org design puts pressure in the direction of the architecture you want to build. Decide the system you want first, then build the team to match it.

This works well beyond application code. A data leader in the same thread described the identical pattern on their side: give every business unit its own analysts and you get competing definitions of the same metric, each one correct for the team that built it. A shared semantic layer only exists if a team is shaped to own it. They ran the inverse maneuver deliberately, and the structure delivered exactly the architecture they had asked for.

The part nobody budgets for: architectural lag

Here’s where the theory meets Monday morning. One engineer in the thread put it perfectly: when you inherit a system for a rewrite, the seams read like an org chart from three years ago. Clean interfaces show up where two groups had to negotiate. The worst coupling sits exactly where one group owned both sides and never had to.

And the inverse maneuver has real lag. You can reorganize teams in a week, but the old shape stays in the schema for a long time. Splitting the org doesn’t split the database. Luca’s reply to that point was the honest one: reorgs are painful precisely because system inertia is so large.

The counterargument worth taking seriously

Not everyone in the thread accepted the framing. Sergiy Yevtushenko, founder of Pragmatica Labs, argued that Conway’s Law establishes correspondence between the system and the organization, not between the system and the structure of the development division specifically. Small distributed teams can and do produce distributed monoliths. Large colocated teams can and do produce highly modular systems. In his reading, scaling development is governed by Brooks rather than Conway.

That objection sharpens the point rather than dissolving it. If team topology alone doesn’t determine architecture, then the mapping between how you’re organized and what you ship is even less predictable, and even more worth measuring. You cannot manage a correspondence you’re only assuming.

Now add agent teams to the equation

The sharpest question in the entire discussion came from Brian Cripe, founder and agentic engineer: how does this strategy change when each developer soon manages an “agent team” of their own? Does it scale the same way, given the same properties of coordination cost and the limits of attention in context windows?

I believe it does, and that should worry and excite you in equal measure. Coordination cost doesn’t disappear when the coordinators are agents. It moves. Context windows are the new meeting rooms. An engineer orchestrating five agents is running a small team, with all the alignment overhead that implies, compressed into prompts, skills, and handoffs instead of standups. Conway’s Law will apply to human-plus-agent organizations just as reliably as it applied to purely human ones. The systems built by agent teams will mirror how those agent teams are structured, tooled, and supervised.

Which means the stakes of the Inverse Conway Maneuver just went up. If org design shapes architecture, and every developer is now effectively a team lead, then your architecture is being shaped at a resolution most leadership teams have never had to manage before.

You can’t shape what you can’t see

This is the gap in the whole conversation. Everyone agrees Conway’s Law is inevitable. Everyone agrees you should shape it deliberately. Almost nobody talks about the instrumentation required to do that.

Because here’s the uncomfortable truth: your intended org design and your actual org design are two different things. The org chart says teams are decoupled. The Git history says three teams touch the same module every sprint. The architecture diagram says clean service boundaries. The review data says every meaningful change waits on one senior engineer who sits in a different reporting line. The work itself is the ground truth, and the work lives in your delivery systems, not in your slides.

That’s exactly why we built Waydev around a work-first principle. Engineering intelligence drawn directly from the actual flow of work shows you the organization you really have, not the one you drew. You can see where coupling is forming, which dependencies are slowing delivery, where a reorg has landed and where the old structure still governs the code. You can watch the architectural lag instead of discovering it three years later during a rewrite.

See the real structure. Decide where to apply pressure. Act before the seams harden into schema. That’s the Inverse Conway Maneuver with instruments on, and as agent teams multiply the number of “teams” inside your organization, flying without those instruments stops being an option.

Conway’s Law is going to happen to you either way. The leaders who win the next few years will be the ones who can see it happening in real time.