Twelve teams each maintain their own Helm charts. Would you standardise them on one shared library chart?

### What you are actually choosing between Three shapes compete here, and naming them separates the decision from the tooling. Duplication: every team keeps its own helpers. Cheap to start, zero coupling, and drift is guaranteed - a change to the standard label block is twelve independent edits, and you will discover the two nobody made during an incident. A shared library chart: helpers are authored once, versioned, and pulled in as a dependency. The change is written and reviewed once; adoption is still twelve version bumps, but they are mechanical and reviewable. One generic application chart everyone installs: centralises the most - a single chart version, one place to change anything - but it forces every workload into one templated shape and one release cadence, and every unusual requirement becomes a new values key on a chart that grows without bound. This is a different decision from how you slice releases; it is about who owns the object definitions. ### Where the line goes Share what must be identical for the platform to function, not what merely looks similar. Standard labels and selector construction, name truncation rules that keep generated names inside length limits, image reference assembly from registry, repository and tag, and any annotation your tooling reads: these are invariants, and a divergence in them is a platform bug. Share those. Do not share the workload. The moment a library exports a complete Deployment, its consumers stop owning their own objects. Every field somebody needs and you did not expose becomes a values key on your chart, and the team that cannot wait forks. You will also have made every consumer's rendered output change whenever you touch that template, which turns a helper bump into a fleet-wide risk. A useful test: if a consumer could reasonably want the helper's output to differ, it is not an invariant and does not belong in the library. ### Running it as a product A shared library with twelve consumers has consumers, and every consumer property applies. Ownership: one team is accountable, and the library has a changelog. A library everyone may commit to and nobody owns accumulates helpers nobody can safely remove. Interface discipline: the set of exported names is public API. Renaming an exported helper, or changing what context one expects, is a breaking change; give it a major version and a deprecation window in which both names exist. Consumers cannot adopt on your schedule, so give them one they can meet. Contract testing: keep a job that, for each consumer chart, renders it against the current library and against the candidate version and diffs the YAML. That diff is the real changelog. A library change whose diff across twelve charts is empty is safe by construction; one that changes a selector should stop the release, because a selector change lands as an immutable-field failure at upgrade time in someone else's namespace. Adoption: automate the bump pull requests. Adoption that depends on twelve teams choosing to do it produces a long tail on old versions, and a long tail means you are effectively maintaining several libraries. ### The failure modes worth naming up front The library becomes a bottleneck: any chart change requires a library release, so teams stop asking and copy the helper back into their own chart. That is the signal the boundary was drawn too wide. The library freezes: it has enough consumers that nobody will accept a breaking change, so it grows a second way to do everything. Cap this by budgeting for majors and by keeping the exported surface small - a small surface is what makes a major version survivable. Nobody knows who runs what: without an emitted version label you cannot answer "which namespaces still render the old block", and the migration has no end condition. ### The honest answer in an interview Start with the invariants, ship a deliberately small library, and let it grow only when the same helper has been copied twice. Measure success by whether a platform-wide change - one added label across a 12-namespace fleet - is one authored change plus mechanical bumps, rather than twelve hand-edits. If the library cannot deliver that, it is coupling without the payoff, and duplication was the better trade.