Standardizing State Across Teams Everything so far in this chapter is an individually correct decision: the right level, the right tool for the framework, server state kept separate from client state, entities normalized instead of duplicated. And a multi-team codebase can still end up in trouble — not because any single decision was wrong, but because five different teams made five different, locally-reasonable decisions, with nothing tying them together. This closing lesson is about the organizational discipline that turns a correct individual decision into a correct shared one. How this actually happens No team sets out to fragment a codebase. It happens through ordinary, defensible choices made in isolation: Team A ships a feature using a query library with query keys shaped like . Team B, working on a different module, reaches for a different library entirely — maybe because that's what their lead knew best — with a completely different key convention. Team C, newer to the codebase, hand-rolls its server state in the global store, because nobody told them a query library was the house standard. Every one of these choices, made alone, passes code review. None of them is wrong by the decision tree covered earlier in this chapter. But a developer moving between modules now has to relearn the same underlying concept — fetch, cache, invalidate — three separate times, in three separate house styles. The fix: write the tree down, and enforce it The decision tree, the per-framework tool guidance, and the normalization discipline from this chapter are only useful if they're shared knowledge, not tribal knowledge living in one senior engineer's head. Three concrete steps turn them into an actual standard: 1. One approved tool per level , written down: which query library, which store library, which pattern for shared cross-cutting state — decided once, for the whole codebase, not re-decided per team. 2. One naming convention — query key shapes, store slice names, file/folder structure for a feature's state — specific enough that two engineers independently building similar features arrive at the same shape without having to ask each other first. 3. Enforcement that doesn't rely on memory — a generator or schematic that scaffolds a new feature's state in the agreed shape (an Nx generator, an Angular schematic, a Plop template), plus lint rules that catch the most common deviations automatically, so the standard survives without a human reviewer having to catch every violation by hand. Whether that generator produces an Angular service-with-signals or a React Zustand store, the point is identical: the convention is enforced by what's easiest to reach for, not by hoping every engineer remembers a document. The Trade-off: Is Writing This Down Worth the Overhead? A written standard, a generator, and lint rules are all real, ongoing maintenance cost. For a single team working alone, that cost buys nothing — there's no divergence yet to prevent. The pain, concretely v1: Team A ships a feature using a query library with sensible, consistent query keys. Locally, entirely correct. v2: Team B, on a different module, uses a different library with a different key convention — nobody told them otherwise, and nothing stopped them. Also, individually, locally correct. v3: An engineer moves from Team A's module to Team B's for a sprint, and has to relearn a completely different mental model for what should be the identical concept — losing real time to something that was never actually a hard problem, just an unshared one. v4: A cache-invalidation bug is found in one of the two patterns. It has to be fixed twice — once in each team's independent implementation of the same underlying idea — because there was never one shared implementation to fix a single time. Side-by-side Tribal knowledge, per-team decisions Written standard, enforced by tooling --- --- --- A developer moving between modules Relearns the pattern from scratch each time Recognizes the same shape everywhere Fixing a systemic bug Fixed once per independent implementation Fixed once, in the one shared pattern Code review consistency A matter of each reviewer's personal taste Checked against a written, agreed standard Cost for a single team working alone None — there's nothing yet to diverge Real, and mostly unearned this early The signal to switch The moment a second team or module independently reinvents a state pattern that already exists elsewhere in the codebase — that's the trigger to write the convention down and standardize, retroactively including whichever team's version turns out to be the better one. Start simple A single-team codebase doesn't need a written state-architecture standard yet — tribal knowledge is fine when there's only one tribe holding it. The discipline earns its cost the moment a second team starts making independent state decisions in the same shared codebase. The rule The moment more than one team is making state decisions in the same…