General Manager
I want a manager opening an Altaius report to find something they can discuss with the person who used the simulation. If the conversation begins and ends with a score, we have left too much of the work to the manager.
The report matters because it can bring a particular moment back into view. What did the participant know? What did they say? What happened next? That is a much better starting point for a development conversation than asking someone why their negotiation result was lower than a colleague's.
A leadership simulation debrief is a structured conversation about an attempt, the reasoning behind it and an action to try afterwards. I would keep the first discussion narrow enough that both people leave knowing what they have agreed to practise.
The worksheet below is a proposed approach. It is not a validated assessment instrument or a claim about results from Altaius clients.
Suppose a participant offers a customer an earlier delivery date. The customer accepts. On the surface, that looks like progress.
The manager selects that moment because the participant had not yet checked delivery capacity. There may be a good explanation. Perhaps they thought the scenario briefing gave them authority to promise the date. Perhaps they knew the promise was conditional, but did not say so. Perhaps they overlooked the constraint altogether.
Those explanations call for different conversations. I would start with: "What were you relying on when you offered that date?"
Let the person reconstruct the situation before introducing your interpretation. Keep the relevant conversation and available information beside the discussion. Memory can tidy an uncertain choice into a much more coherent story afterwards.
If a report marks down the offer, ask which criterion was applied and what supports that judgement. Did the participant exceed their authority, fail to explain a condition, or simply take longer than expected?
Those are not interchangeable findings. A timing measure needs context. A slower response could reflect confusion, but it could also reflect a sensible check before making a commitment.
Altaius OS is being built around detailed information for individual participants and their authorised managers. I want that detail to make an interpretation easier to inspect. A manager still needs to examine the situation and hear the participant's account.
Disagreement belongs in the record. If the scenario, transcript or scoring explanation is unclear, note it and seek clarification. Do not make the participant defend an unexplained result as though the software has already settled the question.
Return to the delivery example. The participant might try: "I can check whether that date is possible. Before I confirm it, I need to speak to the delivery team. Which part of the timing is most important to you?"
The exact words will depend on the relationship and the situation. The point is to practise acknowledging the request without presenting an unchecked commitment as an agreed fact.
Ask what the customer might say next. If the customer insists on an immediate answer, how would the participant handle that? Give the revised approach enough resistance to find out whether it is usable.
In a free-text simulation such as Grand Bazaar, a participant can attempt a response in their own words. A second attempt can inform the discussion, although improvement on a repeated scenario should not be treated as proof that the same action will appear at work.
The debrief needs a connection to a situation the person is likely to encounter. "Be more strategic" gives neither the participant nor the manager much to follow up.
A more specific agreement could be: before the next renewal call, write down the delivery commitments that need approval and who can approve them. After the call, review whether any promise went beyond those boundaries.
Agree what can reasonably be recorded. Development follow-up should not become an excuse to collect unrelated customer or employee information. Use the minimum relevant material and the organisation's approved handling arrangements.
| Worksheet field | Example entry |
|---|---|
| Moment selected | An earlier delivery date was offered before capacity was checked |
| Participant's explanation | They understood the offer as conditional, but did not state the condition |
| Evidence reviewed | The relevant exchange and the scenario's authority limits |
| Alternative attempted | Acknowledge the request, explain the approval needed and ask about timing |
| Workplace opportunity | Preparation for the next renewal call |
| Follow-up | Manager and participant review the commitment record after that call |
| Unresolved question | Whether the scenario briefing made the authority boundary sufficiently clear |
This is an example record, not a completed employee assessment.
At the follow-up, ask whether the opportunity occurred and what the person did. If the call was cancelled, there is no workplace observation to report. If a new policy changed the approval process, record that too.
The Kirkpatrick Model distinguishes learning from behaviour on the job. That distinction is worth preserving even in a short manager conversation. A better second attempt and a better renewal call are separate observations.
I would rather leave a debrief with one well-understood action and an honest follow-up than a long list of capabilities nobody knows how to practise. The manager's next conversation should be about what happened when the person tried it.
