A payments platform has had a significant outage. An architect must brief the executive team. What should the brief contain, and what is the most common mistake?

What the brief must contain

In this order, because attention decreases:

1. Impact, quantified. How many merchants, how many transactions, what value, over what period, and whether any money is in an unknown state. The last clause is the one an executive at a payments company most needs and is most often omitted.
2. Current status. Resolved, mitigated, or ongoing — stated plainly, with the time it was mitigated.
3. What we are doing now, if anything is still in progress.
4. What caused it, in one or two sentences using the vocabulary of the business rather than of the system.
5. What prevents recurrence, with a date and an owner.
6. What we do not yet know, explicitly.

The most common mistake

Starting with the technical narrative. A chronological account beginning "at 14:03 a deployment to the ledger service introduced a connection pool exhaustion" loses the audience before reaching the number they need, and it invites questions about the mechanism rather than about the consequence.

The second most common: omitting uncertainty. An executive who is told the cause confidently and learns two days later that it was something else will discount every future brief. "We believe X; we will confirm by Thursday" costs nothing and preserves credibility.

The judgement about detail

Executives do not need the mechanism; they need to answer the questions they will be asked — by customers, by the board, by a regulator. Write the brief to make those answers possible, which means the financial exposure, the customer impact, the regulatory notification requirement and the remediation commitment.

The specific requirement in a regulated payments business

Whether a regulatory notification is required, and by when. That is a clock that starts at detection, and it is frequently the most time-critical item in the brief while being the one engineering thinks about last.

Similarly, whether any transaction is in an indeterminate state — neither succeeded nor failed — because that determines whether the outage is a service incident or a reconciliation incident, and the second takes weeks rather than hours to close.