Conway's Law has a temporal dimension that is often overlooked: if you disband the team, the software architecture will degrade. The organizational structure that produced the architecture must persist to maintain it.
The Project Model (Bad for Architecture)
The project model is the default in many organizations, especially those that grew up doing waterfall or agency-style work:
- Approach: Assemble people from various departments for "Project X." Build it over 6 months. Declare victory. Disband the team and move everyone to "Project Y."
- Conway Effect: The software structure (Project X) loses its corresponding organizational structure. The engineers who understood the system's internals are now working on something else. Knowledge dissipates. Maintenance becomes a "shared" burden — which in practice means nobody owns it. The architecture rots because there's no team whose job it is to keep it healthy.
- Symptom: "Nobody knows how this works anymore." Every organization has a system like this. It's usually the most critical one.
The Product Model (Good for Architecture)
The product model treats software as a living thing that needs a permanent owner:
- Approach: Create a "Payment Team." They build the Payment Service. They stay together to run, fix, and evolve it for years. The team has a product roadmap, not a project deadline.
- Conway Effect: The organizational structure persists, preserving the software boundaries. The team optimizes their own internal architecture because they have to live with it. They have strong incentives to keep the codebase clean, the tests green, and the on-call burden low — because they're the ones getting paged at 3am.
- Symptom: "The Payment Team knows everything about payments." Expertise accumulates rather than dissipating.
Stable teams build stable software. This is not a coincidence — it is Conway's Law operating over time. The team's communication structure persists, and so the software structure persists with it.
The Transition Challenge
Moving from project to product teams is organizationally difficult. It requires budget owners to fund teams rather than projects, which feels less controllable. It requires managers to accept that "their" engineers are permanently assigned to a domain rather than available for reallocation. These are real organizational change management challenges — and they're exactly why the Inverse Conway Maneuver is hard to execute even when everyone agrees it's the right approach.