Part 0 · 2 chapters · ~15 min

The Shape of a Large Frontend Org

Four kinds of team (product, platform, infrastructure, release engineering), what each owns and is measured by, the ratios between them as a budget and a diagnostic, how decisions land as code, and the thesis of the course: every piece of machinery is a fossil of a human process that stopped scaling.

1

Four kinds of team, and the ratios

the shape
  1. Product teams (most of the headcount: ~150 teams of ten at two thousand engineers): a surface or journey each, with a PM and a designer; they own their code through OWNERS, their surface's metrics, their on-call and their experiments. They consume the platform and rarely change it.
  2. Platform groups (~150 engineers across the framework, design system, data layer, i18n, telemetry, forms): internal customers, measured by consumers' velocity and by "ways to do one thing", which they drive to one.
  3. Infrastructure (~20): the monorepo and its tooling, the build system, CI capacity and flakiness, the developer environment, the artefact pipeline. Measured by p50 and p95 build, test and CI latency and by blocked-engineer days. Small, deep, and the team everyone depends on.
  4. Release engineering (~10): the trains, the rollout tooling, client incident management, compliance gates. Measured by time-to-detect and time-to-mitigate for client incidents.
  5. The ratios (10 : 1 : 0.1 : 0.05) are a budget and a diagnostic: an under-staffed platform produces three date pickers and a migration team; under-staffed infra slows everyone at once.
  6. Decisions land as code: a platform change ships with a migration plan and a codemod, never a memo; a product team consults the platform for new patterns. The failure modes are platform without consumers and product building its own platform.
THE SHAPE OF A LARGE FRONTEND ORG
product teams, platform groups, infrastructure, release engineering, and the ratios between them
swipe the figure sideways, or tap expand for full screen
1/6
product teams
Product teams: eight to twelve engineers each, aligned to a surface or a user journey, with a product manager and a designer; they own their code (OWNERS), their metrics (the surface's conversion, its Web Vitals), their on-call for their surface, and their experiments. They consume the platform and rarely change it. At two thousand engineers there are ~150 of them.
2

Why the machinery exists

each machine is a fossil of a human process
  1. Patterns by review → the framework (part 2): at fifty engineers three reviewers enforce "fetch in loaders"; at five hundred the framework makes the loader the only place a fetch can go.
  2. Dependencies by convention → the hermetic build (part 1): at fifty the machines are similar enough; at five hundred a build passes on one laptop and fails on another, and Bazel makes every input declared.
  3. Data access by discipline → data masking (part 3): at fifty reviewers catch over-fetching; at five hundred a removed field breaks a screen nobody can find, and Relay lets a component see only what its fragment declared.
  4. Upgrades by request → codemods and bots (part 4): at fifty a rename takes a week; at five hundred, a thousand call sites across a hundred teams take a year of nagging, or an afternoon of codemod.
  5. Experiments by spreadsheet → the platform (part 5): at fifty a spreadsheet; at five hundred, collisions, metrics chosen after the result, and no idea what a year of launches did together, until the platform assigns, logs exposure, pre-registers and keeps a holdout.
  6. The test before adopting any of it: is the human process measurably failing (review latency, environment-specific build failures, over-fetch incidents, upgrade cycle times, experiment collisions)? If yes the machine pays for itself; if no, a small organisation adopting Bazel because a large one did has bought the fossil without the animal.
how to read this course
Each part names the machine, the process it replaced, what it costs, and the signal that says you have reached the point where it pays. The ideas transfer at any scale; the machinery transfers only past the point.
MACHINERY REPLACES A PROCESS THAT STOPPED SCALING
the human process, the point it broke, and the machine that took over
swipe the figure sideways, or tap expand for full screen
1/6
the framework
Patterns by review → the framework. At fifty engineers, "we fetch data in loaders, not effects" is enforced by the three people who review everything. At five hundred, nobody reviews everything; the framework makes the loader the only place a fetch can go (part 2). The cost: a framework team, and a migration every time the pattern changes.