👋 Hey {{first_name|there}},
You’ve probably seen this before:
A service boundary that mirrors a team boundary, but doesn't make technical sense.
A data model shaped more by team turf than domain logic.
A system that’s hard to change because ownership is unclear.
At first, it feels like a coincidence. But it's not.
Your system will reflect the shape of your team.
Whether you like it or not.
That’s Conway’s Law in action, and ignoring it is how good designs become painful systems.
Let’s dig into this mindset shift and how to design with team dynamics in mind.
🧭 The Mindset Shift
From: “Teams work inside the system”
To: “Teams shape the system”
Most developers are trained to see the system as technical boxes, layers, and flows.
But architects see something else:
Communication paths
Ownership patterns
Friction points
Cross-team boundaries
That’s where real complexity lives.
You don’t just design code.
You design collaboration.
This shift is what separates strong senior engineers from effective architects. Because code is easy to change, people and politics are not.
💭 What Conway’s Law Actually Says
In 1967, Mel Conway observed:
“Organizations which design systems… are constrained to produce designs which are copies of the communication structures of these organizations.”
Translation?
If teams don’t talk to each other, their code won’t either.
If every team uses different standards, your system will be a mess of mismatched parts.
If one team owns too much, it becomes a bottleneck.
This is not just theory. It plays out in real-world systems every day.
🧰 Tool of the week: The Conway Mirror Map
Here’s a simple exercise you can run to visualize this dynamic.
Step 1: Sketch your system
Draw major components: services, modules, APIs, data stores.
Step 2: Map team ownership
Add labels: who owns what? Where do handoffs happen? Where’s the overlap or vacuum?
Step 3: Look for misalignments
Ask:
Are technical boundaries clean where team boundaries are not?
Are there modules with no clear owner?
Are some teams too entangled?
You’ll start to see where organizational tension is shaping, or breaking, your architecture.
This map becomes a conversation tool. Not to point fingers, but to ask:
“How do we structure our teams to support the architecture we want?”
🔍 Friction Means Coupling
Some of the most useful architecture feedback doesn’t come from load tests or PR reviews.
It comes from hallway conversations like:
“I don’t know who to talk to about that system.”
“We can’t ship this until Team X responds.”
“That module is a black box, and no one touches it.”
These are architectural red flags.
Because they reveal team coupling, not just code coupling.
You don’t need a complex design review to spot this.
Just listen for the friction.
🧠 Example: The Split That Backfired
I once worked with a company that split a monolith into microservices, one per team.
In theory, it was great. In practice?
Teams stopped talking to each other.
Shared concepts got duplicated.
Cross-cutting concerns (auth, logging, billing) became a mess.
The product slowed down because no one could make a full change without 3 other teams involved.
The architecture didn’t fail because of bad tech.
It failed because no one designed the team interactions around the new system boundaries.
That’s the blind spot Conway warned us about.
💡 Architecting the Org With the System
As you grow in responsibility, you may not have control over org charts.
But you can influence how work gets structured and how decisions are made.
Here are a few tactics that scale:
1. Propose APIs as Collaboration Contracts
If two teams need to integrate, make the interface a shared artifact, something both sides review and own.
2. Design for Autonomy, Then Verify It
Don’t just say “this team owns that.” Validate: Can they release independently? Can they monitor and debug without another team?
3. Use Ownership Maps
Make it clear who owns what, even for internal services and libraries. Lack of clarity = tech debt.
4. Add People to Your Diagrams
Try sketching not just the system, but who touches each part. If a component has five teams interacting with it, that’s a hotspot, maybe for a restructuring.
✅ Mini challenge: Run a Conway Mirror Review
This week, take one feature or system you’re working on.
Ask:
How is team ownership influencing the design?
Where do communication gaps show up?
What’s harder than it should be, and is the root technical or organizational?
Then ask: what would I change if I could redesign the collaboration first, not the code?
That’s architecture thinking in action.
🎯 Get More Architecture Tools That Scale With Teams
I cover these kinds of challenges, messy handoffs, tradeoff decisions, and cross-team design in the free 5-day crash course.
It’s the best place to start if you’re serious about stepping up into architectural leadership.
👋 Wrapping Up
Good architecture doesn’t fight the org chart.
It uses it.
Conway’s Law isn’t an excuse, it’s a warning.
If you don’t shape your team interactions, they’ll shape your system for you.
Design for communication.
Map your ownership.
And when you hit friction, treat it like a design flaw, not a people problem.
Thanks for reading.
If something here clicked, or didn’t, hit reply. I’d love to hear what part of the architect role feels most unclear to you right now.
See you next week,
Bogdan Colța
Tech Architect Insights