Your Team Grew. Its Dependencies Stayed Put.

Better process could help. But “better process” leaves you choosing a remedy before you know whether someone missed a decision or whether too much work depends on the same person. Another approval might catch the next conflict while making both engineers wait longer to ship.

The distinction matters before you hire again or divide the team. A missed decision needs a way to reach the people affected. A shared bottleneck needs its workload reduced or its capacity increased. The same meeting can help with the first and add to the second.

The headcount doesn’t tell you where it breaks

When everyone working on a service knows its code and hears its decisions, coordination can happen over lunch. Code review happens by proximity. Everyone has every file paged in. That arrangement depends on shared context: someone who missed lunch still needs to know that the meaning of a field changed.

The number of possible conversations grows faster than the number of people. Melvin Conway’s 1968 paper describes that growth as approximately half the square of headcount. For n people, count n - 1 possible counterparts each, then divide by two so each pair counts once: n(n - 1) / 2. Five people have 10 possible pairwise connections; fifteen have 105.

Those are possible connections, not measured hours of communication. The count assumes every person could need to speak with every other person. It says nothing about how many actually must coordinate on a given change, and it supplies no special breaking point at six, fifteen, or fifty engineers.

A bottleneck gives a more specific explanation for a sudden slowdown. If every change needs the same reviewer, hiring can increase the rate at which reviews arrive without increasing the rate at which they’re completed. Once arrivals consistently exceed completions, unfinished reviews accumulate. Work then waits even when the engineers writing it have spare capacity.

That’s one mechanism to investigate, not a diagnosis you can make from a headcount. Harder work, unclear priorities, or a slow test suite could also account for the delay. Look at where an actual change waited before deciding that the team needs a reorganization.

A boundary has to change the work

Conway’s broader argument was that an organization’s communication structure constrains the systems it can design. That makes team boundaries an architectural concern. It doesn’t follow that moving names on an org chart will untangle existing code.

Consider splitting a group into checkout and billing teams while both still edit the same price calculation. A billing change can still invalidate checkout’s assumptions. Separate managers and backlogs give that negotiation more places to happen; the shared calculation still requires agreement. Calling the teams autonomous doesn’t make either one safe to ignore the other.

Shopify’s experience puts a concrete dependency behind this problem. In Kirsten Westeinde’s February 2019 engineering account, a new shipping developer needed to understand order creation and payments just to make changes. The code was intertwined enough that seemingly innocuous edits could produce unrelated test failures.

Shopify chose to keep one application and separate its business domains within it, an approach called a modular monolith. The initial file moves grouped code around concepts such as orders, shipping, inventory, and billing. Then came the harder work: defining interfaces and data ownership so one component could use another without reaching into its internals. A tool called Wedge identified calls and data relationships that crossed those boundaries improperly.

Westeinde reported a specific outcome: the dependency-isolation work enabled Shopify to replace its legacy tax engine with a new calculation system. Complete isolation was still ongoing, and programmatic enforcement of boundaries was still being researched. The account offers no measured delivery-speed gain or ideal team size.

Our inference is narrower: the useful boundary was in what code could depend on, beyond where files or people were grouped. Shopify had work to do after the file moves. Keeping a single application also let it pursue that separation without taking on a separate deployment pipeline for every component. It retained a shared deployment, though; separating code inside the application doesn’t by itself let teams release components independently. Team growth alone doesn’t settle the choice between a modular application and separately deployed services.

Follow one delayed change

Return to the engineers who changed the same service. If one missed a decision about what a field means, write that meaning into the interface documentation and tests that its callers use. Review the changed assumption with the affected engineer. Requiring the whole department to attend another status meeting would spread the cost well beyond the missing conversation.

If the field’s meaning needs to change, they have a genuine shared decision. Suppose checkout expects a price before tax and adds tax itself. An unannounced switch to tax-inclusive prices would make checkout add tax again, even if the field kept the same name and type. The engineers need to agree on how callers will move from the old behavior to the new one. Giving them separate team names won’t remove that work.

Keeping the calculation shared may be sensible when both teams must apply the same rule. Copying it into separate services gives them separate code to edit, but someone still has to keep the rules in agreement. An interface helps when callers can rely on its behavior while its implementation changes. Its value depends on which changes it lets the teams make independently, rather than how neatly it divides the code.

If the only safe reviewer is the engineer who remembers every dependency, removing the approval would discard a useful safeguard. Pairing another engineer on those reviews can spread the knowledge, though it consumes the experienced reviewer’s time before it adds capacity. Reducing simultaneous changes can make room for that training, at the cost of deferring other work. Hiring for review capacity could help once the new engineer has enough context to review safely. Hiring more people whose output must pass through the same reviewer leaves the constraint in place.

Which team boundaries are load-bearing, and which are inherited? A review needed to protect a shared payment rule serves a different purpose from one routed to a former team lead by habit. You can distinguish them by following a real change: what did the reviewer know or decide that the author couldn’t, and what would let the next author proceed safely?

Take a recently delayed change into the next hiring or team-design discussion. Use its pull request and release history to separate time spent changing code from time spent waiting for review, a decision, or another deployment. Check that reconstruction with the people involved: a pull request with no comments may have been waiting on a product decision rather than a reviewer.

One delayed change gives you a place to look. Compare it with similar changes, including one that moved smoothly, before making the wait a reason to reorganize. If the same wait recurs, you have a specific constraint to address. If comparable changes clear review promptly, investigate what was different about this one.

Then put the proposed new team boundary beside that history and identify the handoff that would actually disappear.