"Il codice funziona" è il minimo, non lo standard. La vera maturità ingegneristica riguarda come qualcuno gestisce scope, ambiguità e persone, non solo se la sua feature funziona. La definizione più semplice che uso: un ingegnere sta crescendo quando riesce ad affrontare problemi più grandi con meno guida.
| Segnale | Meno maturo | Più maturo |
|---|---|---|
| Dimensione del problema | Necessita compiti ben definiti | Affronta problemi aperti |
| Guida | Necessita direzione | Opera in modo indipendente |
| "Fatto" | Il codice si mergia | L'outcome è consegnato e posseduto |
| Blast radius | Il proprio lavoro | L'efficacia del team |
Due ingegneri entrambi spediscono una feature. Uno chiude il ticket. L'altro segnala un edge case rischioso al PM, aggiunge monitoring, e scrive una breve documentazione così la prossima persona non è persa. Lo stesso codice spedito, ma maturità molto diversa, ed è il secondo comportamento che sto promuovendo.
Se misuri solo se il codice funziona, ricompensi l'output e perdi le cose che davvero si compongono: il giudizio, l'ownership e il fare crescere gli altri. Nominare questi criteri esplicitamente dà agli ingegneri una mappa chiara di cosa significhi "crescita", e ti dà una base equa e coerente per feedback e promozioni.