Deux ingénieurs seniors sont en fort désaccord sur une décision d'architecture et ça bloque le travail. Que faites-vous ?

Rendez le désaccord explicite et donnez-lui une limite de temps. Faites écrire les deux positions avec les arbitrages et les hypothèses dont chacune dépend, puis identifiez les hypothèses testables à bas coût avec un spike ou un benchmark. Fixez une date de décision. Si les preuves ne tranchent pas, vous décidez, vous expliquez ouvertement le raisonnement, et vous gardez le choix réversible quand c'est possible pour que se tromper reste peu coûteux.

La première chose que je fais, c'est mettre une date, parce qu'un débat d'architecture sans limite coûte cher et ils le savent tous les deux. Ensuite je demande à chacun une page : l'approche, les arbitrages, et surtout les hypothèses dont elle dépend. Neuf fois sur dix, le désaccord ne porte pas sur la conception, il porte sur une hypothèse cachée à propos de la charge, des compétences de l'équipe, ou de la direction que prend le produit dans un an. La dernière fois, tout se ramenait à savoir si on aurait besoin de multi région sous dix-huit mois, ce qui est une question produit, pas une question d'ingénierie, donc j'ai fait venir le responsable produit et c'était réglé en vingt minutes. Quand c'est vraiment technique, je demande quelle est l'expérimentation la moins chère, et on passe deux jours sur un benchmark au lieu de deux semaines sur des opinions. Si c'est toujours à égalité à l'échéance, je tranche, j'écris pourquoi, et je dis franchement que c'était serré et voici le signal qui nous ferait revoir la décision. Ensuite je m'assure que la personne dont l'approche n'a pas été retenue porte quelque chose de significatif dans la réalisation.