À quoi ressemble l'intégration d'un nouvel ingénieur dans votre équipe ?

Visez un vrai changement en production dès la première semaine et une vraie prise de responsabilité à la fin du premier mois. Donnez-lui un binôme qui n'est pas vous, une documentation d'installation qu'il répare en s'en servant, une première tâche avec une définition de terminé claire, et des attentes écrites à trente, soixante et quatre-vingt-dix jours. Introduisez le contexte par couches : le produit d'abord, puis l'architecture, puis l'histoire.

L'objectif, c'est un vrai changement en production dans la première semaine, aussi petit soit-il, parce que tant que quelqu'un n'a pas traversé toute la chaîne une fois il ne travaille pas vraiment ici. Pour rendre ça possible, je garde un petit backlog de vraies premières tâches, pas du travail bidon, calibrées pour toucher le build, la revue et le déploiement. Chaque nouvel arrivant a un binôme qui n'est pas moi, dont le rôle explicite est de répondre aux questions que les gens se sentent bêtes de poser à leur manager. La documentation d'installation appartient à la personne arrivée le plus récemment, donc elle est réparée à chaque fois au lieu de pourrir pendant un an. Sur le contexte, je fais le produit avant l'architecture, parce qu'un schéma de système ne veut rien dire tant qu'on ne sait pas ce que les clients en font, et je garde les histoires du pourquoi on a construit ça comme ça pour la troisième semaine. J'écris ce que j'attends à trente, soixante et quatre-vingt-dix jours et je le partage dès le premier jour, puis je le passe vraiment en revue avec la personne, parce qu'un plan que personne ne rouvre est de la décoration.