Your Users Don't Care How Your Teams Are Organized

Designing coherent experiences across product silos

Every mature product I've worked on has the same quiet problem. Different teams own different parts of the experience. They deliver against their own roadmaps, work with their own datasets, respond to their own users. Over time, quietly, the parts of the product that touch each other start to feel like they were built by different companies.

This is not a moral failing. It's what happens when the organization scales faster than the shared understanding of how its products should feel from the outside. Users, meanwhile, cross those boundaries dozens of times a day without noticing them. They notice the seams.

The framing I've come to use is:

Organizational silos are legitimate. Experience silos are the design failure.

That distinction is where most of the interesting cross-team design work sits.

Silos aren't inherently a problem

The literature that treats silos as a pathology usually skips over why they exist. Teams need boundaries. Specialization has value. Autonomy lets people focus, ship, and get good at what they do. Marty Cagan's model of empowered product teams depends on team autonomy. Team Topologies argues explicitly that team boundaries should be a deliberate design choice, not something to eliminate. Amy Edmondson, Tiziana Casciaro, and Sujin Jang's HBR work on cross-silo leadership frames silos as challenges to work across, not failures to remove.

Structurally, silos are fine. The problem is what happens to the product when the boundaries stop being invisible to the customer.

Melvin Conway made the mechanism precise in 1968: any organization that designs a system will produce a design whose structure is a copy of the organization's communication structure. The reasoning is interface dependency — two modules cannot interface correctly without their designers communicating. Structure follows conversation. This is a default, not a destiny. But defaults win when no one interrupts them, and in a mature product with many teams, defaults win a lot.

The result is experience silos: different interaction models for functionally similar work, different mental models for what a user is trying to do the same way, different behaviors that require relearning every time a user crosses from one part of the product to another. Users don't feel the org chart. They feel the seams.

The locally correct, globally fragmented problem

A product team can make a locally correct design decision that contributes to a globally fragmented customer experience.

This is the tension worth being explicit about, because it's not resolvable through "just try harder to align."

A team designs a filter interaction that fits its specific domain. It ships. It tests well. Users of that team's surface get value. Locally, the decision is correct. Meanwhile, another team, elsewhere in the product, ships a different filter interaction that also fits its domain and also tests well. Also locally correct.

The user who works across both surfaces now has two filter interactions to keep straight. The cost of that isn't borne by either team. It's borne by the user, and by whoever inherits the product architecture later. Both teams made defensible decisions. The product, as a whole, feels less coherent than either team intended.

The Nielsen Norman Group's research on mental models grounds why this hurts: mental models help users predict how a system will work. When a familiar-looking pattern turns out to behave differently, prediction fails. Users pay for it — every time, in small increments of attention and hesitation.

The design problem here is not who made the wrong decision. Both may have been right for their scope. The design problem is that the product needed someone thinking at a scope neither team owned.

Anchor story — a query builder, co-led

At athenahealth, I co-led a cross-team design effort on a self-service query-building experience. My co-lead was a designer from an adjacent product line — both of us officially designated as design co-leads for the collaboration. Multiple teams were independently working on related query-configuration problems in different areas of the product. Users experienced this as one product, even though internally it was several teams' work.

The tempting move was standardization. Build one query-configuration pattern; enforce it across teams. It would have looked like success by any metric that measures alignment. It would also have been bad design.

What we did instead is what most cross-team stories under-describe.

We aligned on a shared interaction foundation — a configuration surface for selecting fields and defining filters, and a workspace where the selected configuration was represented and could be manipulated in context. The shape of what a query builder is and how you configure one would be predictable across surfaces. Users learning it in one place could predict how the equivalent activity would work in another.

We also, deliberately, chose not to standardize everything. Three specific capabilities were preserved as domain-specific by explicit agreement rather than by drift:

• Boolean-style filtering for one product line's more complex logical composition needs
• A hierarchical multi-select control for a domain-specific measure taxonomy
• Different entry points into the query experience across each product surface, so users came from a place that made sense within the surface they were already using

None of these were failures of alignment. They were the alignment. Naming, together, that these were domains where users' needs genuinely differed was as much a cross-team design decision as agreeing on the shared foundation.

The reshape

The most useful thing the collaboration did was reshape my own design.

I had been building the query builder as if the attributes users needed for output columns and the attributes they'd filter on came from largely the same set. Requirements coming out of adjacent domains made it clear that wasn't true. Some attributes were filterable but not useful as columns. Others existed as columns but weren't useful filters. The tidy unified model I had started with was not going to survive contact with the real breadth of use cases.

That specific realization was the concrete instance of a broader shift: from thinking of the query builder as one unified configuration workflow to thinking of it as a coordinated set of distinct configuration workflows that together form one coherent query builder experience.

The reflective observation I've come back to since is this:

The first sign that cross-team collaboration was working wasn't that other teams adopted my pattern. It was that their requirements changed mine.

Cross-team collaboration, done well, isn't about persuading other teams to adopt what you already have. It's about bringing your solution into a room where other requirements will pressure it. If your solution survives that pressure without changing, either it was thought through unusually well or the pressure wasn't real. In this case the pressure was real, and the solution improved.

Consistency is not the same as standardization

This distinction matters because it changes what cross-team work is for.

Standardization is about implementations. Consistency is about the model the user builds.

A product can be highly standardized — every team using identical components — and still feel inconsistent to users if those components implement different mental models beneath the surface. Conversely, a product can vary substantially in implementation and remain consistent if the mental models align.

The mechanism is cognitive. Consistency operates on what the user learns and predicts, not on what the designers ship. Two teams can converge on identical UI components and still produce inconsistency for the user if those components behave differently in each context. Two teams can vary in components and still produce consistency if the underlying model the user builds is stable.

If the goal is standardization, cross-team work is about component sharing, design tokens, pattern libraries. Those are important and worth building. If the goal is consistency, the work is different: it's about aligning teams on what the user should be able to predict, even when the implementation varies.

Collaboration is not free

Cross-team design work is often described as a soft cost that pays off in consistency. The framing is misleading in both directions.

Coordination costs are real. During the active alignment period of the query-builder collaboration, roughly half my time went into it. That's not free. Rob Cross and colleagues have documented, across more than 300 organizations over two decades, that time spent in collaborative activities has grown by 50% or more. Value-added collaboration is unevenly distributed — a small share of employees carry a disproportionate load. If you are a designer taking on cross-team work at scale, you are one of them. That's worth acknowledging as a real cost of the role.

Team Topologies makes a related point from the org-design side: teams have finite cognitive load, and alignment overhead is one of the ways it gets consumed. The thinnest viable platform principle — provide only what other teams actually need to move faster — is a defense against alignment growing beyond the value it produces.

So the trade-off is real. Coordination cost sits on the teams doing the aligning. Fragmentation cost sits on users and future teams — the ones who weren't in the room.

The two are not symmetric in whose cost they are. Coordination costs are visible to the aligners, who have institutional voice. Fragmentation costs are distributed across parties who are absent from the decision. That asymmetry explains why fragmentation wins by default. The people who bear one side of the trade-off are present. The people who bear the other side usually aren't.

The design leadership move is to advocate for absent parties without pretending that alignment is free. That's what intentional coordination means in practice — not maximum collaboration; not minimum either; alignment where user continuity justifies the cost.

Four questions worth carrying into cross-team work

I've come to use four questions when working across team boundaries. They aren't a checklist. They're the questions I try to keep in front of me when the temptation is either to standardize everything or to leave everything alone.

1. Are these actually the same user concepts?

Two surfaces might look like they're doing the same thing, but the underlying user concept can differ. What one team calls "filtering" might be something the user thinks about as "narrowing," while another team's "filtering" is actually "excluding." If the underlying concept isn't the same, imposing a shared pattern makes users worse off.

2. What should remain predictable for users across surfaces?

The consistency question. What model should users be able to build from one surface and carry to another? Not "what components should be identical" but "what should the user be able to predict." Predictability is the outcome; components are one mechanism.

3. What genuinely needs to differ because of domain requirements?

Not every difference between teams' solutions reflects a real difference in user behavior. Some do. Some are historical accidents no one has revisited. It's worth naming which is which before agreeing on a direction. The right answer for parts of a product is: these domains genuinely need different solutions; we agree not to align this.

4. Who bears the cost if we don't align?

The asymmetry question. If we ship as-is, who pays for the fragmentation? The team? Users? A specific class of user who crosses surfaces? Future teams inheriting the pattern? Naming who bears the cost of not aligning is often what surfaces whether alignment is worth doing.

The design leadership move

Cross-team design work isn't about forcing sameness. It isn't, either, about preserving difference for its own sake. It's about naming which is which for the specific case in front of you, and being willing to reshape your own work in the process.

The design leadership move — not a slogan; the actual craft — is advocating for parties who aren't in the room, without pretending that alignment is free.

Organizational silos are legitimate. Product teams need autonomy. The design challenge isn't preventing silos from existing. It's preventing useful organizational boundaries from becoming customer-visible experience boundaries.

Your users don't care how your teams are organized. They shouldn't have to.