A 60-engineer platform organisation of nine teams is introducing decision records and leadership asks what a healthy annual volume looks like so they can tell whether the practice is working. Roughly how many records should they expect per year?

The assumptions and the arithmetic

Start from what a record is for: a choice that constrains future work and would be expensive to reconstruct from the code. Choosing a queue technology qualifies. Choosing a variable name does not. Naming the boundary is most of the estimate.

A product team of six to seven engineers makes that kind of choice a handful of times a quarter — picking a store for a new subsystem, settling an API shape two teams depend on, accepting a vendor, deciding not to split a service. Call it 2 to 3 per team per quarter, a range any working team recognises.

9 teams × 2.5 records/quarter × 4 quarters ≈ 90 records/year

So on the order of 100 a year, with a defensible range of roughly 60 to 150. The dominant error is the threshold, not the team count: shift the bar by one notch and the answer moves by 3x. That is why the number is only useful as a diagnostic band.

What the number diagnoses

• Far below (under ~20): decisions are being made and not recorded. The records that do exist are ceremonial, written for large migrations after approval, and the day-to-day choices that actually shape the system live in chat.
• Far above (over ~300): the bar has collapsed. Records are being written for reversible choices, which costs the organisation roughly an hour each plus review time — call it a week of engineering a month — and buries the ten records that matter.
• Concentrated in one team: usually the team with the most cross-team dependencies, which is information about coupling rather than about discipline.

Why the other options fail

• "About five a year - only the irreversible choices." This is the mistake of reserving records for one-way doors. One-way doors are rare, and the choices that later confuse a new joiner are mostly the reversible ones nobody bothered to explain.
• "One per sprint per team - roughly 240 a year." A cadence, not a trigger. Tying records to a calendar guarantees filler in quiet sprints and omissions in busy ones, because decisions do not arrive fortnightly.
• "One for every pull request that changes a component boundary." Ties the record to a code event rather than to a choice. Most such pull requests implement a decision already made, so the record arrives after the fact and reads as documentation.

When this is the wrong answer

For a single team of eight on a new product, counting is pointless — the useful measure is whether last quarter's three biggest arguments have records. Volume targets only become meaningful once no one person can hold the decision history in their head, which in practice is somewhere around four teams. Publishing the target as a goal also corrupts it immediately: teams write to the number, and the records get thinner.