Learn · Delivering across organisations

What transfers and what does not

After a few implementations you start to see the same shapes. The temptation is to package the outputs. Usually what travels is the reasoning, not the artefact.

Rarely portable

Queue topology. It looks reusable and it is not. Queue boundaries follow a customer’s platforms, their cost structure, their trust boundaries and their team structure. A topology copied from one organisation to another is a set of answers to questions nobody asked.

Pipeline definitions. Build steps are specific to a build system, a repository layout, and a test suite. A shared pipeline template that assumes a monorepo is worse than nothing at a customer with forty repositories.

Secrets integration. Everyone has a secrets manager; almost nobody has the same one, configured the same way, owned by the same team.

Usually portable

Policy expressed as a pattern. “Plugins must be version-pinned, allow-listed by regular expression, and disabled entirely on queues with deployment credentials” is portable. The specific list of allowed plugins is not.

Diagnostic method. The four questions to ask before recommending capacity are the same everywhere, because they are about how the system works rather than about one customer’s configuration.

Assessment procedure. How you establish what a customer’s builds cost them before proposing anything travels intact, and it is the thing most worth getting good at.

The failure mode

The shared tooling that encodes the first customer. It works, so it is reused; it is reused, so it accretes flags; the flags are the ways every subsequent customer differed from the first. Eventually it is unmaintainable and nobody can say what it assumes.

If you are building something for reuse, be able to state its assumptions out loud. If that list is long, or you cannot produce it, you have built a copy of one customer rather than a tool.