You know that feeling when you open a legacy codebase and your stomach drops? The tangled dependencies. The circular imports. The module that seventeen teams have touched but nobody owns. You think the problem is bad code. It’s not.
The code is just a fossil. The organism that made it is still alive — and it’s your org chart.
I’ve been there. Staring at a monolith that nobody fully understands, proposing a rewrite that everyone knows will take eighteen months and probably fail. We’d plan the refactoring, draw the target architecture, estimate the story points. And then six months in, the new system would start looking suspiciously like the old one. Same coupling. Same bottlenecks. Same pain.
Here’s why: we were treating the symptom, not the disease.
Conway’s Law — Melvin Conway’s 1967 observation that any system designed by an organization will mirror that organization’s communication structure — isn’t just a cute aphorism for conference keynotes. It’s the single most powerful explanation for why legacy architectures refuse to die. And almost nobody uses it as an active tool.
Think about it. When your frontend team and backend team communicate through a Jira ticket and a quarterly planning meeting, you get a frontend and a backend separated by an API contract that nobody wants to change. When your data team sits in a different building and reports to a different VP, you get a data pipeline that’s bolted on like an afterthought — because organizationally, it was.
You don’t refactor your way out of Conway’s Law. You reorg your way out of it.
There’s a dark Harvey Dent joke making the rounds in engineering circles: you either die before product-market fit, or live long enough to see the effects of Conway’s Law in your system architecture. It’s funny because it’s devastating. The same communication patterns that let you ship fast in the early days — everyone knows everything, decisions happen in hallways, the founding team is one Slack channel — those exact patterns calcify into the architecture that traps you later.
The startup that built a monolith because five people in one room could coordinate any change? That monolith doesn’t shrink just because you hired two hundred engineers and split them into fifteen teams. The architecture froze the moment the team hit a certain size, and nobody noticed because the code still compiled.
So here’s the twist: the fastest, most fundamental way to change your architecture isn’t a technical decision at all. It’s a people decision.
Want microservices? Don’t start with Docker and Kubernetes. Start by asking: what teams need to own independent deployable units? Then draw your service boundaries around team boundaries, not the other way around. Want to kill that shared database that everyone writes to and nobody owns? Don’t build a data access layer. Move the teams that need that data into the same room as the team that owns the database, and watch the integration patterns change on their own.
Code follows conversations. Always has. If you don’t like the code, change the conversations.
I know what you’re thinking. “I can’t just reorganize my company — I’m a tech lead, not the CEO.” Fair. But you have more leverage than you think. You can propose team structures around new initiatives. You can advocate for cross-functional squads instead of functional silos. You can make the case — with evidence — that every month you spend refactoring without addressing team boundaries is a month you’ll spend refactoring again.
The engineers who understand this have a lever that most don’t. They look at a legacy system and instead of asking “how do we rewrite this?” they ask “what organizational structure produced this, and what structure would produce something better?” That question is worth more than any architecture review board.
Most engineering leaders treat Conway’s Law like gravity — an immutable force you acknowledge but can’t control. That’s the passive reading. The active reading is this: Conway’s Law is a design tool. It’s the most reliable predictor of architectural outcomes you have. And it’s the only one you can change without touching a single line of code.
Your architecture is your org chart compiled. Recompile.
FAQ
Q: Isn't this just an excuse to avoid doing the hard technical work of refactoring?
A: No — it's the opposite. Refactoring without addressing team boundaries guarantees you'll refactor the same problems again. The technical work still needs doing, but it needs to follow an org change, not precede one. Otherwise you're painting a rotting wall.
Q: What if I'm a senior dev with no power to reorg teams?
A: You still influence communication patterns. Propose cross-team working groups, advocate for squad-based delivery on new projects, document the link between org structure and architectural pain in your postmortems. Leadership responds to evidence, especially evidence that ties technical debt to organizational design.
Q: Does this mean every team reorg will automatically fix the architecture?
A: No. Bad reorgs make things worse. The key is intentionality — you design team boundaries to produce the architecture you want, not the other way around. Conway's Law is a blade, not a wand. It cuts in whatever direction you point it, including the wrong one.