Every observation has to become a recommendation
The exercise ends and the facilitator has a pile of notes. Somebody said the runbook was on the file server that was encrypted. Somebody else asked who calls the customer, and the room went quiet for eleven seconds. The backup administrator gave a restore time, and the person who has actually run a restore gave a different one.
Those are observations. A report full of them is not yet useful to the person who has to decide what to spend money on next quarter, and the distance between the two is where the real work sits.
Observations are cheap and recommendations are not
An observation is a record of what happened in the room. It is nearly free: the exercise generates it whether or not anyone is ready to use it.
A recommendation is a claim about what should change. It has to name what is wrong, say what would put it right, and be specific enough that the organization can plan how to address it. Not costed—a report rarely produces a number, and one that pretended to would be guessing at prices and internal effort it cannot see. Specific enough to plan from is the standard: somebody reading it should know what the next step is and who would take it.
Take the eleven seconds of silence. As an observation it is a note about hesitation. Turning it into a recommendation means deciding what the silence was evidence of, and the candidates are not the same problem:
- Nobody holds the responsibility, so it is unassigned.
- Somebody holds it and did not know they did.
- The responsibility is assigned and written down, and the person who holds it was not in the room.
- Everyone knew who it was, and nobody wanted to say it, because the answer is a person who would have to be woken up.
Four different fixes. The exercise supplies the silence, and the facilitator has to work out which of the four it was, usually by going back through what else happened that day for corroboration.
The obligation is coverage, not volume
The hard part is not writing recommendations. It is ensuring that every observation is accounted for, and that is laborious in a way that is easy to underestimate before doing it.
It is tempting to write up the five observations that convert easily and let the rest sit in an appendix as "additional observations". That produces a comfortable report and a dishonest one. The observations that resist conversion are not the unimportant ones. They resist because the underlying problem is ambiguous, or organizational, or expensive, and those are usually the findings worth the customer's attention.
An observation left without a recommendation also puts the work back on the reader, who has less context than the facilitator and was not in the room. In practice it means nothing happens about it.
So the discipline is a completeness check rather than a writing task: enumerate the observations, and account for each one. The test each has to pass is whether it maps onto something—a problem worth naming, or evidence that a part of the response worked, which belongs in the report as much as the failures do.
Most pass. Some legitimately resolve into something else: the control is already adequate and no change is needed; the point is real but too small to spend the reader's attention on; the observation raises a question the exercise cannot answer, and the useful output is the question.
And some resolve into nothing, because the material will not carry them. That happens, and it is worth being honest that it does. In a recent exercise several observations did not reach the report, and in at least some cases the cause was that the notes taken at the time would not support a confident statement of what had occurred. An observation that cannot be supported should not become a finding; one resting on a facilitator's imperfect recollection is worse than none, because somebody will act on it.
That particular failure has a cause and a fix, and both sit outside this article: it is an argument for recording the exercise, where the decision about what mattered can be made during the write-up rather than in the moment.
None of this appears in the report. The completeness check is the facilitator's own process, not a section. What was considered and left out stays out, without a list of near-misses for the reader to wonder about. The discipline exists so that nothing is dropped through inattention, not so the reader can audit the dropping.
What none of these resolutions may be is silence. An observation dropped without a decision is indistinguishable, later, from one nobody noticed.
One observation, two findings
A worked example from a recent exercise, because it shows several of these moving at once.
The person holding the IT security role that day was the most junior member of the team. Through the exercise she repeatedly raised the incident response plan and the procedures under it—what it said, what step came next—and the senior people in the room repeatedly carried on past her. That is one observation. It produced two findings pointing in opposite directions.
The first is positive, and positive findings belong in the report. She did exactly what the role required: she knew the plan existed, she knew what was in it, and she brought it into the response unprompted and more than once. An exercise that only reports failures gives an organization no way to tell what to protect, and this is worth protecting. Reporting only the second finding would also have made her the subject of a document about a failure she was the one person not committing.
The second is the problem, and it is not about her. The response did not follow the plan, because the people with the authority to direct it were not listening to the person holding the plan. Written carelessly, this becomes a finding about seniority and personalities, which is unactionable and unpleasant to receive. The recommendation that comes out of it has four parts and is a subject of its own.
Written usefully, it is a documentation gap. The plan did not say who coordinates the response. With that unstated, the room defaulted to the organizational hierarchy, which is exactly what it does under pressure. The recommendation is that the plan names the coordinating role—IT security—and, just as important, that everyone else knows that during an incident that role directs the response regardless of where it sits on the org chart. Coordinating is not the same as outranking: the coordinator's job is largely to send more senior people to go and find things and do things, and they need to have agreed to that in advance rather than discovering it mid-incident.
That reframing is what makes it fixable. Nobody can action "listen to your junior colleague". Somebody can action a paragraph in the plan and a line in the briefing that goes with it.
It also lands in two of the groups below at once. The plan needs editing, which is documentation. And the room needs to accept direction from a role rather than a rank, which is a change in how the organization behaves under pressure and will not be fixed by the edit alone.
The recommendation that follows from it has more parts than fit here—who the coordinator should be, what they must not also be doing, and how management has to be told about the arrangement in advance—and those are set out separately.
What happens to them next
Accounting for every observation is one job. Ordering the recommendations that come out of it so a reader can act on them is a second one, and it has its own rules: severity is not the only order, grouping by what acting on something involves beats ranking it, and a rating made from outside the organization has a weakness worth stating out loud. That is a separate subject.
Ultimate TTX runs facilitated exercises where the report is part of the engagement rather than an afterthought.