Contenuti

Dare feedback tecnici senza distruggere motivazione e autonomia

Dare feedback tecnici senza distruggere motivazione e autonomia

/en/feedback_tecnici/img.png

Nel mondo tecnico il feedback è una lama a doppio taglio. Serve a migliorare la qualità del codice, dei sistemi e delle decisioni, ma se dato male può distruggere motivazione, autonomia e fiducia in pochissimo tempo.

Il paradosso è che spesso le persone più competenti sono anche le più fragili sul piano del feedback: il loro valore personale è profondamente intrecciato con ciò che producono.

Questo articolo nasce da anni di code review, retrospettive, errori miei e altrui, e da una convinzione maturata nel tempo:

Il feedback tecnico non è un atto correttivo, ma un atto di leadership.

Perché il feedback tecnico genera resistenza

La resistenza al cambiamento viene spesso etichettata come un problema individuale. In realtà è una risposta fisiologica.

Quando riceviamo un feedback tecnico percepito come minaccia:

  • il cervello entra in modalità difensiva
  • l’attenzione si sposta dal problema alla protezione dell’ego
  • l’autonomia viene vissuta come a rischio

Non è una questione di maturità, ma di sicurezza psicologica.

Se vogliamo ridurre la resistenza, dobbiamo prima capire che:

  • non stiamo solo parlando di codice
  • stiamo parlando di identità professionale

Separare radicalmente la persona dal codice

Una delle regole più semplici e più difficili da applicare:

Si revisiona il codice, non la persona.

Il feedback deve sempre riferirsi a:

  • comportamenti osservabili
  • effetti tecnici misurabili
  • rischi concreti

Mai a:

  • intenzioni presunte
  • capacità personali
  • giudizi impliciti sull’autore

Il codice è negoziabile. L’autostima no.

Dare contesto prima del giudizio

Molti feedback tecnici falliscono perché arrivano senza contesto.

Dire che qualcosa “non va bene” non è sufficiente. È fondamentale spiegare:

  • perché è un problema
  • in quale scenario diventa critico
  • quale obiettivo di sistema stiamo proteggendo

Scalabilità, manutenibilità, resilienza, rischio operativo: quando il feedback è ancorato a questi elementi, smette di sembrare un’opinione e diventa una valutazione condivisibile.

Feedback come ipotesi, non come sentenza

Il linguaggio cambia tutto.

Un feedback formulato come verdetto chiude la conversazione. Un feedback formulato come ipotesi la apre.

Esempi:

  • Cosa succede se questo servizio scala di 10x?
  • Hai considerato l’impatto sul recovery time?
  • Mi preoccupa questo punto in caso di failure parziale

Questo approccio trasforma il feedback in co-progettazione, non in correzione gerarchica.

Trasformare l’attrito in crescita

L’attrito tecnico è inevitabile. Il disaccordo, se gestito bene, è un segnale di salute del team.

Il problema non è il conflitto, ma come viene incanalato.

Quando il dissenso è normalizzato:

  • il cambiamento non è percepito come imposizione
  • le idee circolano prima di cristallizzarsi
  • la qualità delle decisioni aumenta

Un team che non discute non è allineato: è silenziato.

Analizzare gli errori senza cercare colpevoli

Ogni errore tecnico è un’occasione sprecata se viene trattato come colpa individuale.

La domanda giusta non è:

Chi ha sbagliato?

Ma:

Perché il sistema ha permesso questo errore?

Spesso emergono pattern ricorrenti:

  • review troppo superficiali
  • requisiti ambigui
  • mancanza di checklist o guardrail
  • pressione sui tempi non dichiarata

Qui il feedback diventa architettura organizzativa, non solo tecnica.

Dall’errore al case study

Uno degli strumenti più potenti per preservare autonomia e motivazione è trasformare l’errore in case study.

Non come lezione calata dall’alto, ma come:

  • retrospettiva guidata
  • documentazione leggera
  • esempio riutilizzabile

Il messaggio implicito è fondamentale: Non ti controllo. Ti do strumenti.

Così l’esperienza individuale diventa patrimonio collettivo.

Il ruolo del leader tecnico

Chi guida un team tecnico non è lì per dimostrare di avere sempre ragione. È lì per:

  • creare contesto
  • facilitare decisioni migliori
  • rendere gli altri autonomi

Dare feedback efficaci significa:

  • scegliere il momento giusto
  • distinguere feedback tecnico da feedback emotivo
  • chiudere sempre con una direzione chiara

Un feedback senza direzione genera frustrazione, non crescita.

Conclusione

La qualità tecnica non nasce dal controllo, ma dalla sicurezza. L’autonomia non nasce dall’assenza di feedback, ma dalla fiducia nel modo in cui viene dato.

Se il feedback distrugge motivazione, non è feedback: è solo potere mascherato.

E nel lungo periodo, il potere non scala. La fiducia sì.