Which organisational facts would make you reject a technically sound microservices design?

What is being tested

Whether you treat organisational constraints as real bounds on the solution space rather than as obstacles to argue past.

The facts that would make me reject it

1. Functional teams. A development team, a QA team, an operations team, a database team. Conway's Law is an observation, not advice: the architecture will mirror the communication structure. Splitting into microservices with functional teams produces a distributed monolith — every cost of distribution, none of the independence, plus handoffs.

2. One release train. If the organisation releases monthly through a coordinated window, independent deployment — the entire point of microservices — is unavailable. The design cannot deliver its own benefit.

3. Insufficient headcount for cognitive load. Twelve services across four engineers will be badly operated regardless of design quality. Each service carries a fixed burden: pipeline, on-call, dependencies, patching, dashboards. That burden does not shrink with team size.

4. No platform capability. Microservices are only affordable with substantial supporting investment — service discovery, tracing, standardised resilience, deployment automation. Without a platform team, every delivery team solves it independently and badly. The Netflix decomposition is usually cited for the style and rarely for the platform that made it survivable.

5. Operations outsourced to a runbook-driven contract. A partner operating to fixed procedures cannot run a system requiring judgement, however good the design.

6. No experience of operating distributed systems. The failure modes — cascading failure, partial availability, eventual consistency — must be learned somewhere, and learning them across thirty services simultaneously is expensive.

What to recommend instead

A modular monolith with enforced internal boundaries, plus extraction of the specific components with a forcing reason: a different scaling profile, a different availability class, a different compliance boundary, or a genuinely irreconcilable release cadence.

That gives the boundaries — which are the valuable part — without the network, and it keeps the split cheap to perform later when a real reason arrives.

How to say it

Not "your organisation is not ready", which is condescending and invites argument. Say what would have to be true: "this design requires teams aligned to these capabilities, independent deployment, and a platform team. Which of those can we change, and what would it cost?"

That converts a rejection into a plan, and it makes the organisational change visible as part of the programme rather than as an assumption.

What a strong answer adds

That challenging a constraint is legitimate and is a separate project with its own sponsor. Confusing "this constraint is bad" with "I may ignore this constraint" is the most common way architectures fail to survive contact with the organisation.