An organisation with functional teams — development, QA, operations, database — wants to adopt microservices. What do you tell them?

What is being tested

Whether you address the operating model rather than the architecture, and in the right order.

What I would tell them

The organisation change must come first, or the architecture change will fail.

Conway's Law is an observation, not advice: systems mirror the communication structure of the organisation that builds them. With functional teams, microservices produce a distributed monolith — services that must be deployed together, coordinated through the same handoffs, with every cost of distribution and none of the independence.

They will have bought network calls, partial failure, distributed debugging and operational overhead, and will still be releasing monthly through a coordinated window.

The specific mechanisms of failure

• Every change still crosses four teams, so lead time does not improve — the handoffs simply moved.
• Nobody owns a service end to end, so operational quality has no owner and reliability is everyone's second priority.
• The database team becomes the constraint for every service, which recreates the shared-database coupling the split was meant to remove.
• QA as a separate stage forces batching, which is incompatible with independent deployment.

What to propose instead

1. Reorganise to stream-aligned teams, each owning a capability end to end including running it. The feedback loop between a design decision and being woken by it is what makes reliability an engineering concern rather than someone else's problem.

2. Build platform capability so those teams are not each solving infrastructure from scratch. Without it, autonomy is just isolation and cognitive load becomes unmanageable.

3. Start with a modular monolith, or with the existing system componentised with enforced internal boundaries. Boundaries are the valuable part; the network is the cost.

4. Extract services where there is a forcing reason — a different scaling profile, a different availability class, a different compliance boundary — one at a time, as reasons appear.

The sequencing argument

Reorganising first is slower to start and far more durable, because the architecture will follow the organisation regardless. Changing the architecture first means fighting gravity for the system's whole life.

How to say it without being obstructive

Do not say "you are not ready". Say what would have to be true, and offer to help make it true:

"Microservices deliver independent deployment. That requires teams that can deploy independently, which requires teams that own a capability end to end. Let us start with the team structure and the platform, then split the services where there is a reason. You will get most of the benefit sooner and take on the cost only where it pays."

What a strong answer adds

Naming what they may actually want. Frequently the underlying goal is faster delivery, better reliability, or the ability to use different technologies — and each has a cheaper route than microservices. Establishing the goal before the mechanism is the more useful conversation.