« Ça marche » est le minimum, pas l'objectif. Un projet lancé à temps mais que personne n'utilise, ou qui fonctionne aujourd'hui et réveille l'équipe chaque nuit, n'est pas un succès. En tant que tech lead, vous définissez ce que le succès signifie à l'avance, avec les parties prenantes, afin que l'équipe travaille vers des résultats plutôt que simplement vers « terminé ».
Convenance des critères de succès avec les parties prenantes avant d'écrire le code. « Nous considérerons ceci comme un succès si l'adoption atteint X et la latence p99 reste sous Y » transforme un objectif vague en quelque chose que vous pouvez réellement mesurer, et prévient la dispute post-lancement sur sa réussite.
Les équipes qui mesurent le succès uniquement comme « livré » optimisent pour la mauvaise chose : elles célèbrent les lancements qui échouent silencieusement en production ou auprès des utilisateurs. Un tech lead qui définit le succès à travers toutes ces dimensions guide l'équipe vers un travail qui compte réellement, identifie les problèmes pendant qu'ils sont encore peu coûteux à corriger, et peut montrer à la direction une preuve concrète d'impact plutôt que simplement de l'activité.