Your Org Chart Is on Your Homepage

The seam you noticed is a boundary between two teams, and it has been measured.

If you've moved between two parts of a product and felt it change hands under you, the typography shifting, the back button behaving like a different thing, a form asking for something the company already knows, you weren't imagining it and it wasn't a styling bug. You detected an organizational boundary. The interesting part is that this is one of the better-evidenced findings in the study of how organizations build things, and almost nobody applies it to services.

Conway wrote it down in 1968, and it was tested in 2012

Melvin Conway published a paper in Datamation called "How Do Committees Invent?" It contained a claim that has been quoted ever since: organizations that design systems produce designs that are copies of the organization's own communication structure.

For decades that was folklore with a good reputation. Then Alan MacCormack, John Rusnak, and Carliss Baldwin tested it, publishing in Research Policy in 2012. They found a natural experiment worth using: pairs of software products built to do the same job, one by a commercial firm whose people were tightly coupled, one by an open-source community whose people were loosely coupled. Same function, opposite organizational shapes.

In every matched pair, the product from the loosely coupled organization was significantly more modular. Not marginally. They measured how likely a design change in one component was to propagate into others, and the gap between the tightly and loosely coupled products ran as high as a factor of six.

Read that from the customer's side. The structure of the organization is not merely reflected in what it builds. It is the strongest available predictor of how the thing will hold together, and a stranger can see it without being told anything about your company.

Why the redesign never holds

There's a second finding that explains the part leaders find most frustrating, which is that the seams keep coming back after they've been paid to go away.

Manuel Sosa, Steven Eppinger, and Craig Rowles studied complex product development and published in Management Science in 2004. Their observation is that knowledge of the product's architecture is embedded in the communication patterns of the organization itself. That works well as long as you keep building the architecture you already have. It works against you the moment you want a different one, because the new architecture has to travel through communication paths shaped by the old one.

So a redesign that doesn't touch the communication structure is asking the old organization to carry a new architecture. The interface can be restyled. The seam is not a visual artifact, it's a division boundary with a rendering engine attached, and it reappears.

This is also why the redesign is the option that gets chosen. A redesign is a line item that fits in a quarter. A reorganization is expensive, political, and slow. Choosing the redesign is a rational decision made by people with real constraints, and it produces a predictable outcome: the seams come back, at higher cost, and someone asks why customers keep dropping out at exactly that point.

What it looks like when a bank ships its org chart

Here is the version I watched from inside.

Open a past banking client's mobile app, tap into home loans, and the native app quietly ends. What loads is the home-loans page from the bank's website, wrapped in a frame, the app's own chrome held around the edges. The typography doesn't match the rest of the app, the buttons respond differently, and the back gesture behaves like a website's. You've left the app, and nothing told you.

Home loans weren't special. Every section did it, because every section owned its own data, its own servers, and its own interface. Checking owned checking. Cards owned cards. The app wasn't one application. It was a frame, and each division handed it a picture.

Nobody chose that. Every decision behind it was locally reasonable, made by a team solving its own problem with the systems it controlled. The customer got the seams anyway, which is what Conway predicted and what MacCormack's pairs measured.

The rebuild inverted the organizing principle. Not "what does each division offer," but "what is a person actually trying to get done with their money." That sentence sounds soft. It isn't, because you can't organize an app around what a person is trying to get done unless the data, the systems, and the ownership underneath it are organized that way too. A person paying down a card with money from checking is having one experience. Two divisions are having two. One of them has to give way for the customer to get a single experience.

How to read a screen for its org chart

This costs nothing and I do it in the first week of nearly every engagement.

Open the product and look for the places where it changes personality. A different type ramp. An inconsistent back behavior. A form that asks for something the system already knows. A section that looks like a different team built it, because one did. Each discontinuity is a seam, and behind every seam is a boundary between two teams with no shared owner above them.

Then find the handoffs. Not the screens, the moments between them, where the customer's request passes from one team's responsibility to another's. Ask one question about each: who is accountable if this specific handoff fails? If the answer requires a pause, or a list of names, or the phrase "well, it depends," you've found where the experience is going to die.

The instrument works outside software too. At a past pharmaceutical client, the same question surfaced five parallel submission channels for master-data requests. Formal form, email, attached spreadsheet, photocopy, screenshot. Five channels existed because five teams existed, and nobody owned the request end to end. Those channels weren't a process. They were the org chart.

If you're skeptical that a walkthrough tells you anything your teams don't already know, that's a fair instinct, and it's cheap to test. Do it on the product you're most confident about and see whether the seams land where you'd have guessed.

The change that actually removes a seam

The honest version of this argument is that acting on Conway's Law isn't a design decision, and pretending otherwise is what wastes the budget.

There are degrees, and the small ones are real. The full version is aligning ownership with the customer's journey rather than the division structure. A smaller one is naming a single accountable owner for one handoff, the worst one, and watching what changes. The smallest is a single slide.

That slide is the one I'd push for, because it's the cheapest thing on this list and it moves the decision to the person who can actually make it. Put a screenshot of the seam next to the org chart. Those are the same picture. Until the person who owns the second one has looked at the first, another redesign won't hold, and the research says so.

The question was never whether your organization is showing on your homepage. It is. The question is whether anyone senior enough to change the structure has been made to look at it.