At six in the morning, a warehouse operator picks up a handheld device and starts his shift.
By noon, he will have used four different systems. All of them belong to the same company. All of them were built to solve versions of the same operational problem: track a product, confirm a step, move something forward. On a slide deck they would look like one platform. In his hands, over eight hours, they do not feel like one system.
Almost every step of his work starts with a scan. He points the handheld at the barcode on a product, a box or a shelf, and the system records what he did. The scan that confirms a receiving step in one system needs a different sequence of actions in the next. The message that tells him an action worked appears in a different place, with a different color, after a different delay. Errors also change from screen to screen. Some block him and some only warn him. Some clear when he tries again, and some need a supervisor. None of these differences is serious on its own, and each one is small enough to adapt to. Across a full shift, they add up to a constant, low level of friction. The system makes him work harder than it should.
Sometimes something goes wrong. Throughput drops, an operator makes the wrong choice, or a queue grows. The cause that gets recorded is rarely "inconsistent system design across several engineering teams." It tends to be recorded as human error. The fragmentation in the organization had moved down into the operation, and the operator paid for it with his attention.
I spent eight years building and changing the systems at the center of that experience. It started inside warehouse operations, at a technology company with the scale of a big tech. It was one of the largest e-commerce and logistics companies in its markets, operating in many countries and on more than one continent. My first domain there was the WMS, the warehouse management system. It is the software that runs each step of the work inside a warehouse, from receiving goods to shipping them out. Over those years, my scope grew. First it went from one logistics domain to several, when I became a tech lead for other logistics products. Then I joined a frontend core team responsible for the design system shared across the organization. Later I moved to a platform role, working on systems that served hundreds of product teams at the company. Each time my scope changed, I expected the problems to change with it. Instead, the same structural pattern returned each time, larger and faster, with more teams inside it and more at stake for everyone it touched.
The instinct to look at the whole system rather than just the local part came early and stayed with me. What took longer to understand was that a perspective like that, without the authority to act on it, works more like a constraint than like an advantage. It teaches you a lot, and it costs you something. For years I expected that tension to end once the scope of my role caught up with the scope of the problem. Instead, it changed shape, and the last chapters of this book show how.
I understood the problem slowly, in pieces. We had good engineers, shared libraries, cross-team forums and written standards. We still had the same inconsistencies. Different squads still solved the same behaviors in different ways. Operators still worked in a domain that looked like one business and behaved like several.
At some point the question changed. It stopped being why is the code inconsistent? It became why does the way we make decisions keep producing this result, even when the people making them are trying to do the right thing?
The second question needs a different kind of answer. Better abstractions, stricter reviews and longer guidelines do not answer it. The answer is about where each decision belongs. Some decisions can stay local. Some are too expensive to keep local. And when the system never forces anyone to make that choice explicit, the choice gets made anyway, one team at a time. Deciding where decisions belong is itself a decision, made by people with their own goals. That part of the answer took me the longest to see.
This book is built around that answer.
It has four parts. The first describes how distributed technical systems fail when coordinated behavior is optional. Many teams make decisions that are correct for each team, and the result does not make sense as a whole. The second shows how shared abstractions, even good ones, repeat the same problem at a different layer. They promise consistency, but they spread the conditions that break it. The third follows the evolution of a real platform, and the design my team created to give it clear ownership and control at runtime. The fourth is about what that design did not cover, and about the incentives that decided what happened to it. Each part looks at the same problem from a different position, because my role changes from one part to the next.
Each part follows the same form. It begins with a short introduction that prepares the stories ahead. The chapters that follow are those stories, told as they happened, with what I understood from each one. The part ends with a section called Questions for Your Own Team. That section asks you to look at your own context and to try something concrete, so that your team can avoid the patterns you have just read about.
The problems in this book are technical in their symptoms. Their causes are product decisions, made on purpose or by accumulation, by people doing their jobs well. Most of the real work happens in the gap between those two things, and so did most of what I learned.
The story begins inside a frontend platform for warehouse operations, but the mechanism is not specific to the frontend. Many teams share one execution surface, and each one makes decisions that are rational locally and incoherent globally. The same thing happens in backend platforms, data infrastructure, mobile tooling and internal APIs. Only the layer where the fragmentation becomes visible changes. The reason it keeps happening stays the same.
This book is for engineers, tech leads and managers who work on or alongside teams that build or operate shared technical systems. It is not a guide to better tools, abstractions or shared libraries, and it will not give you a framework to install. It describes what happens to technical systems when they grow too large for the quality of each team to decide how they behave. It also describes what has to change in the structure when that happens, because you need to understand a mechanism before you can change it.
If you know this field, you will recognize some of its ideas. Team Topologies gave platform teams a shared vocabulary, and the research behind the DORA reports measured what makes software delivery work. Chapter 1 starts from an older observation, Conway's. This book does not replace any of them. It is an account from inside the teams that built and ran these shared systems. It tells what we tried, what we got wrong, and what happened when we tried to use architecture to change who decides. Part of what makes it different is where it happens. In its later chapters, the platform has two kinds of users at once: the engineers who build on it and the operators who use what they build.
The first thing I had to accept was also the most uncomfortable. The problem was not the code, and better code was not going to fix it. That is where this book begins.
Next: Chapter 1 — One Business, Several Systems