« Le code fonctionne » est le minimum, pas la norme. La véritable maturité d'ingénieur concerne la façon dont quelqu'un gère la portée, l'ambiguïté et les gens, pas seulement si sa fonctionnalité marche. La définition la plus simple que j'utilise : un ingénieur progresse quand il peut prendre en charge des problèmes plus importants avec moins de guidance.
| Signal | Moins mature | Plus mature |
|---|---|---|
| Taille du problème | A besoin de tâches bien définies | Prend en charge des problèmes ouverts |
| Guidance | A besoin de direction | Opère de manière indépendante |
| « Terminé » | Le code merge | Le résultat est livré et approprié |
| Rayon d'explosion | Leur propre travail | L'efficacité de l'équipe |
Deux ingénieurs livrent tous les deux une fonctionnalité. L'un ferme le ticket. L'autre signale un cas limite risqué au PM, ajoute un monitoring et rédige une courte doc pour que la personne suivante ne soit pas perdue. Même code livré, maturité très différente, et c'est le second comportement que je promeut.
Si vous mesurez uniquement si le code fonctionne, vous récompensez la production et manquez les choses qui composent vraiment : le jugement, l'appropriation et l'élévation des autres. Nommer ces critères explicitement donne aux ingénieurs une carte claire de ce que « croissance » signifie, et vous donne une base juste et cohérente pour les commentaires et les promotions.