Come spieghi argomenti tecnici a stakeholder non tecnici?

Question

Accepted Answer

Gran parte della leadership è **traduzione**, trasformare la realtà tecnica in termini su cui product manager, dirigenti e clienti possono agire. L'abilità è guidare con *impatto e compromessi*, non implementazione, e abbandonare il gergo tecnico.

## Perché è importante

```text
✓ Lead with the SO WHAT — impact on cost, time, risk, or users
✓ Drop the jargon — or define it once, plainly
✓ Use ANALOGIES for complex ideas
✓ Frame as TRADE-OFFS and OPTIONS, not absolutes
✓ Be honest about uncertainty and risk
✓ Tailor depth to the audience — exec vs. PM vs. customer
```

## Un esempio concreto

Non dire: "Abbiamo bisogno di refactorizzare il servizio di autenticazione perché è strettamente accoppiato e non testabile." Di' piuttosto: "Attualmente, modificare il login è lento e rischioso, ha causato due outage. Due settimane di pulizia ridurrebbero quel rischio e ci permetterebbero di spedire funzionalità di login il doppio più velocemente." Stessi fatti, inquadrati nei *loro* termini: rischio, tempo, velocità.

## Offri opzioni, non ultimatum

Gli stakeholder prendono decisioni migliori quando dai loro scelte: "Possiamo spedire la versione veloce in una settimana con limitazioni note, o la versione robusta in tre. Ecco il compromesso." Questo rispetta la loro decisione e costruisce fiducia.

## Perché è importante

Le decisioni sul tuo lavoro vengono prese da persone che non leggono codice; se non riescono a capirti, decideranno senza di te.

Un TL che traduce bene diventa il ponte di fiducia tra l'ingegneria e il business, ed è lì che vive la vera influenza.