Mel Conway wrote his observation in 1968. More than half a century later, it remains the most precise framework for explaining why composable projects fail.

Kelly Goetsch quotes it on page 3 of Microservices for Modern Commerce (O'Reilly, 2016) and names microservices directly as "Hacking Conway's Law." His framing: "Any organisation that designs a system (defined broadly) will produce a design whose structure is a copy of the organisation's communication structure." Goetsch then describes how horizontally specialised org structures, Java developers in one group, storage admins in another, UI teams separate, inevitably produce tightly coupled, monolithic systems.

In 2026, this insight still has not fully landed. Not from ignorance, but because org redesigns are politically and organisationally costly, considerably more so than purchasing new SaaS tools.

Why composable without org change fails

Consider this scenario: you're replacing your Shopware monolith with a composable stack. Backend microservices via commercetools, search via Algolia, storefront via Next.js. The architecture is modular. The contracts are signed. The domains are registered.

But your org structure looks like this:

• A central frontend team processing all UI tickets
• A backend team configuring composable APIs
• A content team working in the old CMS, writing tickets to the frontend team
• A DevOps team approving deployments

What happens now? Every frontend change flows through tickets. Every deployment through an approval process. Every new A/B test setup through coordination across three teams. The technical modularity is there, but the organisational coupling produces the same inertia as the monolith.

Goetsch describes exactly this pattern through the example of a Java developer needing a new database column: ten serial steps, DBA ticketing system, handoffs, waiting times, for a change that is two minutes of actual work. "These steps are exhausting even just to read, yet this is how even minor changes are implemented in enterprises."

The composable-stack equivalent in 2026: a content person wants a new landing page section. Technically every component is available. But six tickets and three coordination meetings later, the moment has passed.

What Conway's Law means for composable teams

You cannot override Conway's Law. But you can use it deliberately by aligning your org structure with the desired system structure, that is what Goetsch means by "Hacking Conway's Law."

Concretely: if you want a composable system made up of autonomous, decoupled capabilities (storefront, search, checkout, content), you need autonomous, decoupled teams that own those capabilities.

The pattern that works here is cross-functional product teams per business capability. One team owns the storefront, frontend code, deployment, performance, A/B testing, everything. It has a product manager, one or more developers, a content operations person. It does not wait for tickets from other teams. It deploys itself.

Goetsch describes the ownership principle for microservices clearly: "A single team of 2 to 15 people develop, deploy and manage a single microservice through its lifecycle. This team truly owns the microservice. Ownership brings an entirely different mentality."

Applied to the frontend layer: a team that owns the storefront can actually live composable. A team that processes storefront tickets but has no deployment autonomy is structurally a monolith, regardless of what the API architecture underneath it does.

The most common org patterns that block composable

Three patterns consistently cause problems in practice:

Pattern 1: The central frontend team as bottleneck A single team responsible for all frontend artefacts does not scale with a composable stack. When ten business teams simultaneously want storefront features, the central frontend team becomes the constraint. The solution is not a larger central team, but decentralised ownership with shared infrastructure.

Pattern 2: Content teams without a deployment path In many organisations, content teams cannot take new pages or sections live themselves. They need developer support for every new template. This means content teams either stay in the old monolith CMS or constantly produce dependencies. A good FMP setup separates content autonomy from code deployment.

Pattern 3: DevOps as central approval body When every deployment requires central DevOps approval, release frequency is capped, regardless of how modular the stack is. Deployment ownership needs to sit with the team that owns the service.

What an FMP resolves here

A Frontend Management Platform addresses the interface between org structure and technical stack. It creates the infrastructure that allows different teams to work autonomously on frontend capabilities, without constant coordination.

Concretely: a content team can configure new page layouts in Laioutr Studio without waiting for developer tickets. A growth team can set up A/B tests without blocking frontend deployments. A developer team can build new components, register them in the FMP, and make them available for other teams to use autonomously.

This is not only a technical feature, it is the technical enablement for the cross-functional team model that Conway's Law calls for.

The alternative, every team builds its own frontend stack and manages its own deployments, produces what Goetsch describes as duplication cost: "Each microservices team selects, sometimes procures, and always runs their own stack. But the point of microservices is speed." For the frontend layer, this does not quite hold: frontend complexity is better managed through shared infrastructure, not full decentralisation.

Three questions for your replatforming brief

If you're preparing a composable replatforming, these three questions are worth answering before the first architecture meeting:

1. Which teams currently have deployment autonomy for frontend artefacts? If the answer is "none" or "only the central frontend team," you have an org structure that will block composable.

2. Can content teams take new pages live today without developer support? If not, that is not a feature gap in your CMS, it is an ownership gap in your org.

3. How many teams would be affected by a single storefront feature request? If the answer is more than two, you have a coordination overhead structure that prevents composable speed.

The answers to these questions matter more for your replatforming outcome than the choice between Hygraph and Contentful.

Conclusion: composable is an org question, not a tooling question

Goetsch's 2016 observation remains unchanged in 2026: microservices, and composable generally, is more an organisational topic than a technology topic. Buying the tools without adjusting the org structure buys you more expensive complexity, not higher velocity.

This does not mean you need a complete org transformation before a replatforming. It means you need to resolve the ownership questions consciously: who owns what? Who can deploy what independently? Who needs whose approval?

An FMP like Laioutr's can help map this ownership structure technically, but it does not replace the decision of who owns which capability.

More on the technical side of this question, how frontend layer standards affect TCO in the composable stack, in our posts 10 Years of Microservices in Commerce and Headless Alone Is Not Enough.

[Discuss your composable replatforming, the org question comes first](https://www.laioutr.com/demo)

Source: Goetsch, K. (2016). Microservices for Modern Commerce. O'Reilly Media.

Related Insights

• Saving Existing Investments: Why Gradual Composable Transition Beats Full Replatforming
• Publisher Replatforming in 2026: Why Composable Frontends Are Doubling Magazine Revenue

Related resources: Composable Digital Experience Platform.