An interviewer says - you run the architecture function for 400 engineers. Give me three numbers you would publish and tell me what each would have to do before you concluded the function should be shut down. What is being tested and what does a strong answer contain?

What the interviewer is testing

Not whether you can name metrics. Whether you will name a condition under which your own job should stop. Candidates who cannot do that are usually measuring activity - reviews held, decision records written, standards published - because activity cannot falsify anything. The question is unanswerable from an activity metric, and that is the point.

The three numbers, each with its falsifier

1. Review coverage: the share of production changes that passed through the function. Denominator is every change that reached production, from deploy records rather than from the function's own tracker. Shutdown condition: coverage above 70% for a year while the incident rate for the classes the function reviews is statistically indistinguishable from the twelve months before it existed. High coverage with no measurable effect means the function is a tax.

2. Intake-to-decision time, in days, at the median and the 90^th percentile. Shutdown condition: the 90^th percentile exceeds the time a team takes to ship the change anyway. At that point teams rationally stop asking, coverage becomes self-reported fiction, and number one can no longer be trusted. This is the number that audits the other two.

3. Reversals: decisions the function itself reversed, each naming the signal that triggered it. Shutdown condition: zero in two years. Either no decision carried a falsifiable expectation, or reversals happen and are not recorded. Both mean the register is a publication record, not a decision record, and the first two numbers are unaudited.

What makes these different from activity metrics

Each has a denominator the function does not control, each has a pre-period baseline, and each has a stated value that would end the argument. A metric with no value that would make you stop is a slogan with a number attached. Publishing the shutdown conditions alongside the numbers is also the cheapest credibility an architecture function can buy, because it is the one claim nobody expects.

Common weak answers

• "Number of architecture decision records written." Output, not outcome. It rises fastest when the function is slowest, because a backlog of decisions produces a backlog of documents.
• "Stakeholder satisfaction surveys." They measure whether the function is pleasant, and the function's job includes telling people no. A declining score is as likely to mean it is working as that it is failing, so it cannot discriminate.
• "Technical debt reduced." No denominator and no agreed unit. If you cannot state what the number was last year and what measurement produced it, it is not a number.
• "Incident count." Right direction, wrong attribution. Incidents fall for a dozen reasons; without the pre-period baseline and a restriction to the change classes the function actually reviews, you will claim credit for a quiet quarter.

When this is the wrong answer

At 25 engineers there is no function to measure. The sample is too small for any of these three numbers to carry signal: one incident moves a rate by a factor of two. The right answer at that size is to name the two or three decisions that must not be made twice - the data store, the deployment unit, the tenancy model - write them down with their falsifiers, and measure nothing. Instrumenting governance before there is enough traffic to produce a rate is the mirror-image mistake, and it is more common in interviews than under-measurement.