Incident Commander

Come fare training per elevare altri colleghi Incident Commander

Quando succede un incident serio, non è solo una questione di CPU al 100%, errori 500 o code che esplodono.
C’è sempre un altro fattore in gioco: la capacità del team di restare lucido.
Al centro di questa capacità c’è una figura chiave: l’Incident Commander.

Questo articolo è pensato per chi vuole far crescere nuovi Incident Commander nel proprio team, definendo un percorso di training chiaro, ripetibile e soprattutto umano.

Cosa significa davvero Incident Commander

L’Incident Commander non è “quello più forte tecnicamente”.
È la persona responsabile del processo, non necessariamente della soluzione tecnica.

In pratica:

• è il punto di riferimento unico durante l’incident;
• dà ordine alla conversazione, assegna ruoli e step;
• comunica con l’esterno (stakeholder, management, customer-facing);
• tiene il focus sul “ripristinare il servizio”, non sul “trovare il colpevole”.

Un buon modo per definire il ruolo:

“L’Incident Commander non deve sapere tutto.
Deve solo assicurarsi che le persone giuste facciano le cose giuste, nel giusto ordine, senza farsi travolgere.”

Questo è il primo concetto da trasmettere a chi stai formando:
non sei il super-eroe tecnico, sei il regista dell’operazione.

Come gestire pressione e incertezza

Un incident importante mette addosso pressione, rumore e tempo compresso.
La prima skill da allenare è la capacità di restare calmi nell’incertezza, senza riempire i vuoti con panico o ipotesi affrettate.

Esercizi di training pratici

Puoi costruire momenti di training che simulano proprio questo:

• Simulazioni a tempo

  • Crei uno scenario (es. checkout down, API lente, coda backlog).
  • Dai al futuro Incident Commander 30–60 minuti per gestire il flusso, non per risolvere tecnicamente il problema.
  • Valuti:
    • chiarezza delle richieste,
    • capacità di fermare il rumore,
    • ordine nel raccogliere info.

• Incertezza guidata

  • Durante la simulazione, fai emergere informazioni parziali e anche contraddittorie.
  • L’obiettivo non è “indovinare”, ma esplicitare cosa si sa e cosa no:
    • “Al momento sappiamo questo…”
    • “Queste parti sono ancora ipotesi…”

Strumenti per supportare la calma

Insegna alcune micro-tecniche semplici:

• Chiarezza verbale
  Frasi brevi, soggetto chiaro, verbo d’azione:

  • “Mario, per favore controlla i log del servizio X nei ultimi 15 minuti.”
  • “Stop alle ipotesi per 2 minuti: ricapitoliamo i fatti.”

• Checkpoint regolari

  • Ogni 5–10 minuti:
    • “Riassumo dove siamo…”
    • “Questa è la nostra ipotesi attuale, questo il prossimo step.”

La calma non è “non sentire la pressione”, ma non scaricarla sul team.

Il ruolo come mission (non come titolo in CV)

Se vuoi far crescere Incident Commander credibili, devi presentarne il ruolo come missione di servizio, non come badge di potere.

Messaggi chiave da passare ai futuri IC

• Responsabilità verso il team

  • “Il tuo compito è proteggere il focus delle persone che stanno lavorando.”
  • “Devi creare un ambiente dove è più facile ragionare che farsi prendere dal panico.”

• Responsabilità verso l’azienda

  • Non si tratta solo di uptime:
    • c’è la reputazione verso i clienti,
    • la fiducia del business nel team tecnico,
    • la capacità di imparare dall’incident.

• Responsabilità verso la verità

  • L’Incident Commander ha il compito di far emergere i fatti, non di costruire una narrativa comoda.
  • Anche “non lo sappiamo ancora” è un output valido, se comunicato bene.

Come trasformare il ruolo in percorso

• Rotazione programmata:
  • non avere un solo Incident Commander “titolare”, ma una lista di colleghi in crescita.
• Affiancamento:
  • prima come osservatori silenziosi, poi come co-IC, infine in autonomia.
• Feedback post-incident strutturato:
  • 10 minuti specifici su “come è stato gestito il ruolo di IC”, separato dal debrief tecnico.

Mindset, rituali, comunicazione

Un buon Incident Commander non nasce dal nulla:
si costruisce con mentalità, rituali e stile di comunicazione allenati e ripetuti.

Mindset: poche idee, ma chiarissime

Cose da tatuare (metaforicamente) nella testa di chi stai formando:

• “Prima ripristino, poi capisco.”

  • Non è il momento per rifattorizzare.
  • Non è il momento per cambiare tecnologia.
  • È il momento di far tornare il servizio in piedi nel modo più sicuro e rapido possibile.

• “Meglio una decisione chiara che tre mezze decisioni.”

  • L’indecisione è anch’essa una scelta, spesso la peggiore.

• “Niente caccia al colpevole in tempo reale.”

  • Il blame è posticcio, la responsabilità è di sistema.

Rituali operativi durante l’incident

Puoi codificare veri e propri rituali, da insegnare e ripetere in training:

1. Kick-off dell’incident

   • Identifica l’Incident Commander a voce (o via chat) in modo esplicito:
     • “Da ora in poi, l’Incident Commander è X.”
   • Definisci il canale di comunicazione unico (es. #incident-1234).

2. Raccolta dei fatti

   • “In 3 minuti, ognuno scriva cosa vede, senza ipotesi, solo dati.”
   • L’IC riassume ad alta voce.

3. Definizione del piano

   • “Ecco cosa faremo nei prossimi 10 minuti: …”
   • Assegnazione chiara:
     • persona → task → tempo stimato.

4. Aggiornamenti cadenzati

   • Ogni X minuti:
     • “Stato attuale: …”
     • “Nuove informazioni: …”
     • “Piano aggiornato: …”

5. Chiusura provvisoria

   • Dichiarare esplicitamente il momento in cui l’incident è chiuso dal punto di vista operativo:
     • “Servizio ripristinato, ma in modalità degradata.”
     • “Incident chiuso, follow-up e root cause analisi domani.”

Comunicazione verso l’esterno

Parte del training deve includere anche la voce verso il business:

• Linguaggio chiaro, non tecnico:
  • “Una parte del sistema che gestisce X non sta funzionando correttamente.”
• Focus su:
  • impatto,
  • tempo stimato per la mitigazione,
  • azioni in corso.
• Niente promesse azzardate:
  • “Stiamo lavorando per ripristinare il servizio, il prossimo aggiornamento sarà tra X minuti.”

Conclusione: cultura del pensiero a blocchi

Alla base di un buon Incident Commander c’è un modo di pensare che puoi insegnare e coltivare:
la cultura del pensiero a blocchi.

In pratica, significa:

• spezzare situazioni complesse in blocchi gestibili;
• procedere per step espliciti invece che per intuizioni caotiche;
• ragionare per:
  • raccolta dati,
  • decisione,
  • azione,
  • verifica,
  • comunicazione.

Allenare nuovi Incident Commander significa proprio questo:

• dare un linguaggio comune (ruoli, rituali, step);
• creare sicurezza psicologica (si può non sapere, si può chiedere aiuto);
• trasformare ogni incident in palestre di lucidità, non solo in momenti di fuoco.

Se inizi a trattare il ruolo di Incident Commander come un percorso formativo continuo – e non come un cappello occasionale da indossare “quando tocca” – vedrai crescere non solo la qualità della gestione degli incident, ma anche la maturità complessiva del tuo team tecnico.