The pitch for microservices at engineering conferences is mostly technical: independent deployability, polyglot freedom, fault isolation, language-appropriate runtimes, granular scaling. That pitch is wrong. Not the words — the framing. Microservices are an organizational pattern that ships as software architecture. Mistake the cause for the effect, and you'll spend two years and millions building something harder to operate than the monolith you wanted to escape.
Here's what's really happening.
Conway's Law, written in 1968 by Mel Conway, states that any organization designing a system will produce a design mirroring the organization's communication structure. People nod at this in talks and then ignore it on Monday. They shouldn't. It's not a cute metaphor. It's the most reliable predictor of how your system will end up. It works both ways: your org shape produces your system shape, and the system shape you commit to will, over time, force your org into that shape too.
When a team adopts microservices successfully, it's because the company already had, or was willing to grow into, the org shape that microservices require. That shape is small, autonomous, full-stack teams with end-to-end ownership of a bounded business capability. Two-pizza, fully cross-functional, end-to-end accountable, with their own on-call, deploy cadence, and product roadmap. Spotify-squad lite, Amazon two-pizza heavy. If you have that, microservices work. If you don't, they won't.
What I see repeatedly is the inverse. A 60-person engineering org with three product managers, a centralized DBA team, a separate platform group owning CI, a security team approving all dependencies, and a single staff engineer reviewing every production change. That org wants to "move to microservices" because the monolith is slow to deploy and AWS just pitched Lambda. They split the monolith into 23 services and ship them. Eighteen months later, every feature requires changes in five repos, three teams must coordinate every release, and incident response requires opening seven dashboards. The deployment is technically independent — they could deploy any service independently — but they can't, because the business logic spans services and the org doesn't allow autonomous decisions, so every release is still a coordinated event. They've built a distributed monolith, the worst of both worlds: monolith coupling with microservice operational cost.
This is the pattern. You didn't have an architectural problem. You had a team-design and authority problem. Splitting the binary didn't fix the org. The org is still the bottleneck, and the cluster is the second bottleneck.
Teams that benefit from microservices got something else right first. They drew bounded contexts at the business level — payments is a different domain from billing is a different domain from notifications — and staffed each context with a team that has the authority to make decisions and the discipline to maintain a contract with other teams. That contract is the API. The API doesn't change without a deprecation policy. The team owns its service end to end, including production. When a different team wants to cross the boundary, they negotiate at the API surface, not at the database, and not by bypassing the team to a shared platform group.
If you can't point at five or ten teams in your org that look like that today — autonomous, full-stack, end-to-end accountable, drawn around business capabilities — you shouldn't be building microservices. You should be building a modular monolith with strong internal boundaries, hard module ownership inside the repo, and a deploy pipeline that one team can use without coordinating with others.
A monolith with strong internal seams is a perfectly good architecture. It scales further than people think. Shopify ran for a decade on a Rails monolith they continually refactored into "components" with explicit boundaries, well after the rest of the industry declared the monolith dead. Stack Overflow famously ran their site on a handful of servers and a single SQL Server instance long past the point any consultant would have told them to shard. GitHub was a giant Rails app for years. Basecamp still is. The point isn't that monoliths are correct — the point is that the architecture-quality-bar isn't "is it microservices." The bar is: are the seams clear, is the team accountable for each seam, and does the system match the way the org actually communicates?
Once you have that, you can split services where the business benefit of splitting outweighs the operational cost. Some examples where that math is positive: a write-heavy service whose scaling profile is wildly different from the rest of the app; a service needing a different language for legitimate reasons (a memory-bound matching engine in Rust, an ML serving layer in Python, a video transcoder in Go); a service owned by a team that genuinely operates on its own cadence and shouldn't be coupled to anyone else's release calendar; a service needing to scale to zero or autoscale to thousands of replicas independently. Each of those is a real reason. Notice none of them are "we want to be more modern."
A short list of things to fix in the org before touching the architecture:
Map your bounded contexts. Not your services — your business domains. If you can't name eight to ten of them and assign a team to each, you don't have the org shape yet. Stop. Fix that first.
Push deploy authority to the team. If a team can't deploy without approval from outside the team, microservices won't help them deploy faster. The bottleneck is the approval, not the binary.
Push on-call to the team that ships. If a separate ops team carries the pager for code they don't write, the team that writes the code has no production feedback loop. Microservices will make this worse, not better, because now ops carries fifty pagers instead of one.
Get your CI fast and your test suite reliable in the monolith first. If you can't deploy your monolith with confidence in twenty minutes, you won't be able to deploy fifty microservices with confidence. The operational discipline has to exist before you fragment the substrate.
This isn't a "don't do microservices" piece. There are real systems at real companies that need them and benefit from them — and there are very few of them, relative to the number of orgs that adopted them. If you're at the size where you genuinely have ten autonomous teams owning ten bounded contexts, by all means, ship microservices. They will let your org go faster than anything else you can do.
If you're not there, microservices will calcify whatever org dysfunction you have, in production, where it's harder to fix. Don't ship your org chart unless the org chart is right.
Conway was telling you something important. Listen to him.