Conway's Revenge: Why Your Team Headcount Is Already Writing Your Architecture
The Architecture You Borrowed Might Not Fit You
Someone at a conference gives a talk about how their team migrated to microservices and cut their deployment time by 80%. The slides are clean, the numbers are impressive, and you come back to the office fired up. A few months later, your team is drowning in service boundaries, inter-team coordination overhead, and a distributed tracing setup that nobody fully understands.
What went wrong? Probably nothing with the architecture itself. The problem is that you copied a solution built for a team that doesn't look anything like yours.
Conway's Law—the old chestnut that says organizations ship systems that mirror their communication structures—gets cited a lot. But there's a corollary that doesn't get nearly enough attention: the inverse is also true. The architecture you choose will reshape how your team has to communicate. Pick the wrong one for your current size, and you're not just making a technical mistake. You're manufacturing organizational friction.
The Solo Developer: Optimize for Speed, Not Separation
When it's just you, the best architecture is the one that gets out of your way. A well-structured monolith with clear internal modules beats a distributed system almost every time. You don't need service boundaries to enforce separation of concerns—you have a brain that holds the whole thing. You don't need an event bus to decouple components—you can just refactor.
The solo developer tax on microservices is brutal. You're paying the operational complexity cost—multiple deployments, network hops, distributed debugging—without getting the benefit that justifies it, which is parallel development across teams that can't step on each other. You're essentially hiring the problems of a large organization without the people to absorb them.
If you're building alone, your architecture should be boring. A single deployable unit, a clear folder structure, good tests, and a deployment pipeline you can run in your sleep. That's not laziness. That's appropriate engineering.
Small Teams (Two to Seven): The Sweet Spot for Pragmatic Patterns
This is where things get interesting. A small team can move faster than a solo developer in many cases because you have parallelism without the coordination overhead that kills larger groups. But you also have to start thinking about how the code communicates your intentions to other humans, not just machines.
At this size, a modular monolith still makes sense for most products, but the internal architecture starts to matter more. Clear domain boundaries inside the codebase—even if they're not service boundaries—let two developers work on adjacent features without constantly stepping on each other. Shared components need documentation. API contracts between modules become worth writing down.
This is also the stage where your tooling choices start to compound. The CI/CD setup you build for a team of four will be the foundation your team of ten inherits. Keep it simple and opinionated. Avoid the temptation to build for the team you imagine you'll be in two years. You'll probably be wrong about what that team needs anyway.
Mid-Size Teams (Eight to Twenty): Where Process Debt Gets Expensive
Something shifts around eight to ten people. The informal coordination that worked fine when everyone sat near each other starts to break down. Two developers make a conflicting assumption about how a shared service behaves, and you don't find out until staging. Pull requests start sitting longer because nobody's sure who should review what. Deploys get scary because the blast radius of any given change is hard to predict.
This is the inflection point where teams reach for microservices, and sometimes that's the right call. But it's worth being honest about what you're actually solving for. Service decomposition is primarily a people problem solution, not a technical one. You're drawing explicit boundaries in the code that mirror the team boundaries you want to create. If your team isn't structured to own those services independently—including on-call, deployment, and roadmap—the services create overhead without the benefit.
The better first move at this size is usually to invest in process before architecture. Feature flags, trunk-based development, a clear definition of done, explicit ownership of code domains. Get the team working smoothly as a unit before you start adding network boundaries between them.
Large Teams (Twenty-Plus): Complexity Is the Product
At scale, architectural complexity isn't a bug—it's a feature. You genuinely need explicit service contracts because you have teams that shouldn't need to coordinate for every change. You need distributed tracing because you have enough services that you can't hold the call graph in your head. You need platform teams and internal developer tools because the cognitive load of the full system exceeds what any individual engineer should be expected to carry.
The trap here is different: large teams sometimes under-invest in the platform layer that makes their complexity manageable. They add services faster than they add observability, documentation, and developer experience tooling. The architecture scales, but the ability to reason about it doesn't.
A Simple Framework for Evaluating Fit
Before you adopt any architectural pattern, run it through three questions:
Does the coordination overhead match our team structure? Every architectural boundary is a communication contract. If you don't have the team structure to maintain that contract, the boundary becomes a burden.
Are we solving today's problem or tomorrow's? Building for future scale is usually a form of speculation. Build for the team you have, with clear migration paths to the team you might become.
Does our tooling support this pattern? A microservices architecture without solid CI/CD, service discovery, and observability isn't an architecture—it's a distributed monolith with extra steps and fewer guardrails.
The Right Architecture Is the One That Fits Your People
The best technical decisions aren't made in isolation from the humans who have to live with them. Team size isn't a footnote in your architecture doc—it's a primary input. The teams that get this right aren't necessarily the ones with the most sophisticated systems. They're the ones whose systems match their current reality and give them room to grow without forcing a full rewrite every time they add five engineers.
Ship the architecture that fits your team today. Refactor it when the team changes. That's not a compromise—that's good engineering.
