I built a lot of what I'm about to describe. That matters — because when the same problems kept repeating across my domain, I couldn't comfortably look away from them. I had created the shared boilerplate other teams were using. I had designed the architecture it encoded. I was one of the main maintainers of the cross-squad UI component library. I ran the forums.
But I was also missing something fundamental about why the problems kept coming back, and it would take longer than it should have to see what it was.
The WMS domain inside that logistics organization was organized around four business units — Inbound, Stock, Outbound, and Returns. Each unit ran its own internal product teams, focused on the operational problems that belonged to that part of the warehouse. Across those units, nine squads owned the applications operators used on the floor — a small number by the standards that domain would eventually reach, but already enough to produce what I'm about to describe. A single shift might move a worker through screens built by three or four different teams — and from the outside, the domain looked mature. Experienced engineers. Systems running in production. Teams shipping on their roadmaps. Nothing was on fire.
But once you crossed squad boundaries, the system stopped behaving like one system.
Scanning a product in one application didn't feel like scanning a product in another. Package-handling screens looked related at a superficial level and diverged in the details that mattered when an operator repeated the same gesture four hundred times during a shift. CRUD flows that should have taught operators one interaction model kept teaching slightly different ones depending on which squad had built the screen. Feedback surfaces confirming the same kind of action showed up in different shapes across flows that should have been symmetric.
Nothing was catastrophically broken. That was part of what I didn't understand yet. If the system had failed obviously, the diagnosis would have been easier. Instead, the domain had a landscape of local successes producing a globally incoherent experience — and because each local success was real, the pressure to name the global incoherence as a problem worth solving stayed weak.
Fragmentation rarely arrives as a dramatic failure. More often, it arrives as many reasonable local decisions that never converge.
The technical instinct
When repeated inconsistency surfaces in a codebase, the engineer's first move is to build structure. That was my first move, and it produced real results.
We built a domain-specific boilerplate on top of the company's internal framework — one that imposed TypeScript, standardized project structure, and encoded the architectural patterns WMS applications would hit every day. A meaningful part of that was observability: the backend was extremely fragmented across microservices, and a single operational transaction could cross several of them before anything returned to the UI. When something failed, the first question was always where the request had originated. The boilerplate encoded structured logging natively — not as a convention teams had to remember, but as a default, so every application automatically carried the fields needed to reconstruct what had happened across service boundaries.
We contributed heavily to the cross-squad UI component library. It had been started by the product squads before I joined, at a moment when the effort was still immature and under-structured at the process level. It had to exist as a separate library at all because the company already had a company-level design system, but that system had been built for the marketplace context — retail, search, checkout, listings, seller flows. Logistics did not share those primitives. An operational screen used inside a warehouse, often with gloves on, against a barcode scanner, under shift rotation, could not be built from marketplace components without constantly being forced to fight them. The interaction model was different. The density was different. The feedback expectations were different. The marketplace design system was not wrong — it was correct for its context. It simply was not this context. That is why a logistics-specific UI library had to exist in the first place, and why its fragility at the process level mattered so much.
We created a Node-side shared library from scratch because the drift on the server side was even worse than on the client. We organized weekly cross-squad forums and kept a technical backlog visible to leadership so that cross-cutting debt didn't disappear into individual team roadmaps.
TypeScript had an effect beyond type safety. It improved communication between teams because it forced contracts to be written down. Projects that adopted the stack became more predictable. Development became faster in practical ways. Onboarding improved because new projects started from a shared foundation instead of from each team's idiosyncratic copy of an earlier application.
For a while, the problems got better in squads that participated. Across the domain, the same divergences kept reappearing. I was doing the technical work right. I was missing what that work was supposed to be acting on.
What "optional" actually means
The forums were open to everyone. They were also optional. And I was learning what optional actually means in a large organization — it doesn't mean what engineers want it to mean.
It means that whenever product pressure gets sharp in a squad, participation drops. Not because teams stopped caring. Because a roadmap commitment doesn't renegotiate itself, and cross-alignment is the first thing cut when something has to give.
Some squads disappeared from the forums for weeks, then months. Each time, their applications kept evolving alone. The cost isn't linear: every cycle a squad stays outside the coordinating loop, the architectural distance between its codebase and the shared stack grows. What starts as a two-week catch-up becomes a two-month catch-up, then a rewrite nobody has budget to approve.
I missed meetings too. When the Stock or Returns roadmap got sharp, I would step out and ask one of the other engineers in the forum to drive the session, record it, and leave me notes. That felt survivable in my own case because I was still writing the code the domain depended on. It was not survivable for a squad that stopped participating entirely.
The maintenance of the shared foundation didn't distribute either. It centralized — around me and the squad I was formally part of. Teams benefited from the shared libraries without contributing back. Not because engineers were bad at it. Because the system didn't require contribution. It only offered the option.
That asymmetry taught me something I should have seen earlier. If a shared foundation is available but not required, its maintenance becomes the responsibility of whoever cares enough to do it. At small scale, that works. As the number of consuming teams grows and the contributors stay fixed, the structure becomes unstable. The foundation either stagnates or becomes a burden on a few people it was never meant to rest on.
The applications that had drifted far enough eventually hardened into something that could not be easily corrected. No consistent architectural pattern, no TypeScript, no shared tooling. Contributing to them meant learning a one-off stack. The only honest remediation was a rewrite, and nobody had budget to approve a rewrite for an application that was, technically, still shipping.
I kept doing it anyway. Not because it was formally mine to do, but because I could not watch the foundation drift without trying to hold it. That distinction mattered more than I understood at the time. The work was real and it helped. But I was absorbing an organizational gap rather than surfacing it — spending capacity on a structural problem and calling it technical maintenance. That is a pattern I would repeat in different forms for years before I had language to describe what I was actually doing.
The explanation that stopped holding
At some point I realized something uncomfortable: I couldn't blame the absence of solutions. The shared foundation existed. It sat in repositories the whole domain had access to. It had been adopted by the squads that showed up.
Same company. Same domain. Same operators on the warehouse floor. Same kinds of screens solving the same operational problems. Completely different systems shipped side by side.
Which meant the issue wasn't that engineers lacked tools. It was that the system allowed teams to remain outside shared behavior whenever local pressure made that the cheaper short-term option. Every time a squad skipped alignment, the choice was individually rational — it relieved immediate delivery pressure, preserved a roadmap commitment, avoided a meeting that had no direct impact on the squad's success metrics. Aggregated across nine squads over months, those individually rational choices produced a domain operators had to navigate as if it were nine separate businesses stitched together.
What made this genuinely difficult was that most of those local decisions were right — not just organizationally convenient, but right for the business at the time. A squad that skipped cross-team alignment to ship a flow the operation needed that week was not failing the organization. It was doing its job. The problem was not that they chose the business over the architecture. The problem was that there was no mechanism to track when the accumulated cost of those correct local decisions had quietly exceeded the value they had generated. By the time the fragmentation was visible, it had already become structural.
That was when I understood: this wasn't just a frontend problem. It was an organizational problem, and I had been trying to solve it with code.
Naming that clearly changed what I thought I was supposed to be doing. It did not immediately change what I was able to do. The gap between seeing a structural problem and having the organizational standing to act on it directly is where most of the friction in this story lived — and where it would keep living for a long time.
This played out in a frontend platform — but the same pattern appears wherever distributed teams share execution systems. The mechanism does not care about the layer. It cares about where the decision-making authority actually lives, and what the system does when teams choose not to coordinate.
Why this gets worse precisely when organizations grow
At small scale, weak system design is survivable because communication can compensate for it. Teams know each other. Patterns repeating are visible quickly. A senior engineer can notice the same component being rebuilt in a third place and redirect it before it hardens. Correction happens socially.
That mechanism stops working once scale increases. More squads. More applications. More parallel roadmaps. More operational urgencies running at the same time. More duplicated decisions happening beyond the visible horizon of any one person — including the person who is trying to keep the domain coherent full-time. Manual coordination does not scale forever. There is a threshold past which alignment becomes the bottleneck, and whatever is still left as an optional decision starts diverging faster than conversation can correct it.
WMS was already past that threshold when I started recognizing it. Nine squads is not even a large number by organizational standards. But nine squads each running three or four applications under independent product pressure, with cross-team alignment that was structurally optional, was already enough to produce the drift.
What the incoherence cost the operators
The reason fragmentation matters inside an operational domain is that it does not stay in the code. It lands on the people running the work, and they absorb it in ways that rarely get attributed back to the systems that produced them.
An operator in a shift does not move through one application. They move through several of them, often within a single workflow — one screen to receive inbound, another to move stock, another to pick, another to pack, another to close out a return. When those screens are built by independent squads with independent assumptions, the operator's muscle memory stops being transferable across them. A scan gesture that advances the flow in one application waits for a confirmation in another. A filter that narrows a listing in one report resets it in another. A feedback screen that confirms success in one flow shows up in a different shape — or does not show up at all — in a flow that should be symmetric. None of those differences are catastrophic individually. All of them accumulate.
The cost surfaces as error rates that get classified as "human error." It surfaces as longer training times, because every new operator has to learn each application as its own dialect instead of learning one system and varying only the domain. It surfaces as slower throughput during shift changes, when operators trained mainly on one set of applications are redistributed across another. It surfaces as friction that senior operators absorb by remembering which screen behaves which way — until those operators rotate out, at which point the accumulated tacit knowledge leaves with them.
The organization tends to read those costs as operational noise. They are not. They are the downstream signature of fragmentation the system is carrying. An operator who has to think about which application they are in, instead of which task they are performing, is the most direct evidence that the system is not one system.
Why the interface layer is where it surfaces
The interface layer is where organizational structure becomes visible to the people who use the system. Inside WMS, that was literal in a way most technical domains can avoid.
The backend can hide fragmentation behind service boundaries for a long time. Teams can hide it behind local success metrics — they hit their deadlines, shipped their features, closed their tickets. The interface absorbs none of those buffers. If two flows are conceptually the same and behave differently, operators feel it on the warehouse floor. If an interaction model shifts between applications on the same shift, the operator carries the cost in attention, confusion, and errors that get classified as human failure rather than as the downstream signature of a fragmented system.
The organization may describe independent teams delivering in parallel as a feature of its structure. The person navigating that domain from the outside experiences it as one system that refuses to behave like one system.
This is why the frontend was where the diagnosis became unavoidable inside WMS — not because the frontend engineers were uniquely failing, but because the interface layer had no structural mechanism for absorbing the organizational shape. Every upstream decision — product direction, design language, backend assumptions, team-level trade-offs — eventually collides at the surface where users work. When those decisions are coordinated, the experience is coherent. When they're not, the surface is where the divergence becomes impossible to ignore.
The belief worth abandoning
The belief that had to go: that consistency is the result of agreement.
At small scale, that can feel true. Teams meet, align, converge. But agreement doesn't hold across nine squads under sustained delivery pressure. It doesn't hold across a year. It doesn't hold when a roadmap forces a team to choose between shipping a feature and attending a cross-team alignment session, and the session is optional.
At scale, consistency is the result of design — not visual design, but system design. A system operating across many independent teams has to answer a specific set of questions structurally: which behaviors are allowed to remain local, which are too expensive to stay local, which abstractions are shared by requirement rather than by invitation, where variation is explicitly permitted and where it becomes drift. Without those boundaries encoded structurally, every squad optimizes for its own context. The domain-level incoherence that results looks like an unfortunate side effect. It is actually the designed outcome of a system that left the coordinating structure optional.
That realization changed what I thought the problem actually was. The system was not fragmented because engineers lacked solutions. It was fragmented because the organization allowed coordinated behavior to remain optional, and when you allow it to be optional, you get exactly the outcome you designed for.
Better code won't fix this. Better libraries won't fix it. Another design system won't fix it. What needs to change is the structure of the decisions themselves — what is global, what is local, what is required, what is negotiable. That is a different kind of problem. It is the one this book is about.
What This Means on Monday
If you're seeing the same behavior implemented differently across products, stop treating it as a simple inconsistency problem. Start treating it as a question of decision ownership — and whether that ownership is actually reflected in how your teams are organized.
This week, pick one repeated operational behavior that appears across multiple applications: a scan flow, a feedback screen, a filtered list, an action confirmation. Trace who currently owns that decision. Find where the behavior diverges. But before asking whether the divergence is a problem, ask something harder: were the local decisions that produced it wrong in the first place?
Often they weren't. A squad that chose local speed over cross-team alignment was probably doing the right thing for the business that week. The real diagnostic is not identifying that local decisions were made — it's determining when the accumulated cost of those correct local decisions started exceeding the business value they generated. That threshold is where coordination needs to become structural, not just optional.
Then ask: which of those divergences has already crossed that threshold — and is the organization tracking it, or just absorbing it?
The warning sign is not dramatic: each squad looks healthy in isolation — shipping, meeting goals, running retros — while the person navigating the domain from the outside experiences something that feels assembled by strangers. Individually, every local decision made sense. Together, they produced a system nobody designed and nobody owns.
The leadership move is not to convene a standardization initiative. It is to make the accumulation visible. Name the cost that has already been paid — in operator errors, in training time, in the engineers who have to hold the context nobody wrote down — and then ask:
At what point did the right local decisions become the wrong system-level outcome — and do we have a way to see that before it becomes structural?
That question is harder than asking who owns the decision. It is also the more honest one.
The analysis above had one gap I kept not seeing. I was building the case that organizational structure was the source of the problem, and that was right. But I was still assuming the problem was stable — that the same fragmentation pattern would keep repeating in the same form. What I hadn't accounted for was that the architecture itself was changing underneath us.
The domain was moving toward orchestration. That shift was quietly changing what the platform layer actually was — not just organizationally, but technically. By the time I understood what had happened to the BFF, what the client runtime was actually doing, and what it meant for the interface layer to participate in a distributed execution model rather than simply display what the backend returned, the gap between what the system required and how the organization was operating it had widened considerably.
That is what the next chapter is about.
Next: Chapter 2 — The Moment the Platform Stopped Being a Layer