Have you ever worked at a company where you could see the org chart in the product?
It’s one of the oldest problems in how software gets built, and AI is making it worse. To see why, it helps to go back to before AI was in the picture.
When I was at eBay in the early 2000s, I lived it. Our product teams were organized around pages. There was the Home team, focused exclusively on the eBay home page. The Search team focused on Search and Results pages. The My eBay team, focused exclusively on the My eBay page. Each team optimized their piece of the product. Nobody was looking at the whole experience. But users didn’t think in pages. They thought about the thing they wanted to buy or sell. A collector hunting for a rare piece of Disneyana would move from Search to Search Results, click into a listing, back out to Search Results to compare another item, then save it to My eBay or place a bid, crossing four or five team boundaries along the way. They were focused on the hunt, not the friction. But watching them, you saw it clearly. The hesitations. The unnecessary backtracking. The moments of confusion they’d already learned to work around. To them it was one experience. To us it was five separate products that happened to share a URL.
As the User Research leader at the time, I asked one of the researchers to watch real eBay users use the product the way they naturally would, no tasks, no moderation, just observation. Then I asked her to document the primary flows users took and overlay our org structure on top of them.
The result was clarifying and a little uncomfortable. Every single user traversed multiple product teams. Nobody was thinking about the experience between the teams. Nobody owned the seams.
We were shipping our org chart. I never forgot what that overlay looked like, a user’s natural path cutting across team after team, with nobody responsible for the space between them.
Fast forward twenty years. At Meta, it took me a while to see it. The dogfooding culture felt like progress. It wasn’t until I started asking the same questions I’d asked at eBay that I realized we were doing it again. Each team was dogfooding their piece, not the whole experience. The Groups team tested Groups features. The Feed team used Feed. But nobody was experiencing the Facebook app the way a real user did, moving across surfaces in pursuit of something they actually cared about, checking in on a friend, finding an event, following up on a conversation. Employees also knew too much. They knew what the feature was supposed to do. They built it. They knew what was coming next. That insider knowledge made them fundamentally different from the people we were building for.
So I designed a program called Dogfooding with Real Users. At eBay, I showed leadership the seams. This time that wasn’t enough. I wanted the teams building the product to see the seams and inconsistencies, own them, and fix them before users fell through.
Working with engineering, we built a custom environment that pulled together features from multiple product teams simultaneously, things being developed in parallel by teams who rarely talked to each other. We recruited a hand-picked panel of approximately thirty real users and gave them access to this build for their actual, everyday tasks. Not contrived scenarios. Real use. We collected their ongoing feedback through dScout, a diary study and research tool, capturing behaviors and reactions longitudinally, not just in a single session.
Then we did the thing that mattered most: we shared the results across all the teams at once.
What happened in those cross-team readouts was revealing. Teams saw their feature in the context of the full product experience. They watched users stumble not because of their feature specifically, but because the handoff between their feature and the next team’s was broken. Nobody had designed that seam. Nobody owned it. And because nobody owned it, users fell through it.
We were still shipping the org chart. We just hadn’t seen it until we looked at the whole thing at once.
In 1968, a computer scientist named Melvin Conway published a paper called How Do Committees Invent? His central observation: “organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.” That insight is called Conway’s Law. And when Conway’s Law goes wrong in a product, the result is a disjointed design, fragmented features, and broken handoffs that mirror the internal silos of the company that built it.
This is a structural inevitability rooted in how teams are incentivized. Each team optimizes their surface. Nobody owns the seams between them. The leaders responsible for the whole experience rarely see how features from different teams interact in practice, until the friction becomes impossible to ignore and someone has to step in to untangle it. By then the cost is significant. And without deliberate intervention, the org chart always wins.
AI Breaks Open the Seams
Shipping the org chart has always been a problem. But traditional product fragmentation had a kind of consistency to it. The Search team’s surface felt different from the Feed team’s surface, but it felt that way every time. Users adapted.
AI adds a different kind of complexity, and it starts with the technology itself. AI is probabilistic. The same prompt on the same surface won’t always produce the same response, so the experience is never perfectly stable to begin with. Then the org chart enters. Each team tailors its slice of the model, tuning the tone, the guardrails, and the behavior to fit their own surface. A user moving across those features doesn’t experience one coherent AI. They experience several different AI personalities that may contradict each other. The org chart is now encoded in how the AI behaves and how it feels. The seams don’t just exist. They move.
Inconsistency looks like a bug, not a design decision. With AI, even the stability of traditional fragmentation is gone. The experience shifts not just across surfaces but across sessions and users. When the AI behaves differently from one moment to the next, users can’t adapt because there’s nothing consistent to adapt to. They conclude the product can’t be trusted. Trust is easy to lose and hard to rebuild. A visual inconsistency is annoying. Perceived unreliability could end the relationship.
Nobody owns the model layer across teams. Or rather, everybody does. In traditional product development, the design system team notionally owns consistency across surfaces. With AI, that clear owner often doesn’t exist. Instead, each team owns their piece of it. They tweak the tone. They adjust the guardrails. They override central defaults to make the model work for their specific surface. And unlike a traditional interface where a designer can look at a component and know exactly what it will do, AI behavior is opaque even to the teams building with it. Each decision seems reasonable in isolation. But no one is really tracking what happens when those decisions collide, and teams often don’t tell each other when they make a change. The user experiences the sum of all those independent decisions at once, with no one accountable for how they interact.
My co-author Beth Lingard saw this play out firsthand while leading research at Meta Superintelligence Labs. One team had identified a real problem and fixed it, but only for themselves. They had written the solution into their own app, so it worked there and nowhere else. The instinct was exactly right. They saw a problem and they solved it. What nobody had realized was that every other app had exactly the same need. The fix didn’t belong to any single team. It belonged at the orchestration layer, one policy applied everywhere, so the whole system behaved consistently regardless of which surface a user was on.
That’s the AI version of shipping the org chart. Not a broken handoff between pages. A broken assumption that each team’s solution is self-contained, when the user is moving across all of them. As Beth wrote in her piece Stop Treating AI Like a Mystery, this is one of the most urgent and least addressed problems in how organizations are building AI products today.
So How Do We Avoid It?
The honest answer is that you can’t eliminate Conway’s Law. But you can deliberately work against it. How depends on where you sit.
If you’re in a leadership position:
Organize some product teams around flows rather than features. When the team itself is accountable for the end-to-end journey rather than a single surface, the seams become everyone’s problem by design. It won’t work for every team but even one or two flow-oriented teams introduce a competing organizing principle, one that puts the user’s path at the center.
Run cross-team product reviews. Regular forums where teams present their work in the context of the broader user journey, not just their own feature, force a wider view. When the Search team has to show how their work connects to what happens before and after their surface, the seams become visible before they ship.
Point researchers toward the user, not the org chart, and equip them to understand the technical layer. When researchers are explicitly accountable for the experience across surfaces, not just their team’s feature, they create productive friction. They surface problems nobody owns. They make the invisible seams visible. But in an AI-driven product environment, seeing the seams isn’t enough. The further AI moves into the product stack, the harder it is to influence without understanding how it works. Leaders who ensure their researchers understand the model, the orchestration layer, and the prompting strategy are giving them the tools to shape decisions where they’re actually being made, not just deliver findings that arrive too late to matter.
If you’re an individual contributor:
Learn how the technology actually works. You don’t need to become an engineer. But understanding the basics of how AI systems are built changes what you can contribute (we wrote about this in our last article, Stop Treating AI Like a Mystery). When Beth Lingard was working with teams training models at Meta, she didn’t just deliver recommendations. She created documents specifying the rules the AI should follow, with examples of good and bad behavior and expected outputs, and handed them directly to engineering. Specific, actionable artifacts that fit into how engineers actually work. That’s a very different deliverable than “make the content easy to skim.” The closer your output is to what the team needs to act, the harder it is to ignore.
You can be the connective tissue. Follow the user across team boundaries. That means studying how they move through the whole product when they’re trying to accomplish something real, not just testing your team’s feature. Recruit real users and observe them the way they naturally would use the product. Document the hesitations, the backtracking, the moments of confusion. Then share what you find across teams, not just your own. A joint readout where multiple teams see the same user struggling across their boundaries is worth a hundred individual reports. The goal isn’t to point fingers. It’s to create a moment of shared witnessing that leads to shared ownership. It’s harder to look away, and harder to say it’s someone else’s problem, when everyone is looking at the same thing at the same time.
Partner with other researchers. You’re probably not the only researcher frustrated by the silos. Find the others. Pool your observations across teams. Strength in numbers, and a coalition of researchers all pointing to the same seams is much harder for leadership to ignore than one voice.
Someone Has to Own the Seams
Shipping the org chart is not a new problem. It is a deeply human one, a predictable consequence of how organizations divide work, communicate, and build. Conway identified it in 1968. I ran into it at eBay in the early 2000s and again at Meta twenty years later.
AI doesn’t create this problem. It amplifies it, makes it harder to see, and raises the stakes considerably. When the seams between teams produce inconsistent AI behavior, users don’t just experience friction. They lose trust in the system entirely. And in an era where trust is the currency AI products run on, that’s a cost no organization can afford to ignore.
The researcher’s job has always been to follow the user, not the org chart. In the AI era, that mandate is more important than ever. Not just because the seams are harder to see, but because the consequences of getting it wrong are so much higher. AI is no longer just presenting information. It’s taking action on our behalf. Writing our emails. Making payments. Navigating us through decisions. We grant these systems permission to act in our lives, and we do it on the assumption that they’re coherent, trustworthy, and consistent. When they’re not, the costs aren’t just friction. They’re social, financial, and in some cases life-altering. Someone has to hold the holistic view. Someone has to own the seams. Someone has to ask what the product feels like when you experience all of it at once, as a real person, with real goals, moving across surfaces that were built by teams who never watched them do it.
That’s always been the work. Now it’s urgent.
With thanks to Kaari Baluja, whose research at eBay made the invisible visible, and Jeralyn Reese, whose program at Meta showed what it looked like to finally look at the whole thing at once.
Elissa Darnell is co-authoring “Designing for Humans in the Age of AI” with Beth
Lingard. This newsletter is published every two weeks.