Ma définition d’un lead dev
Le bon profil Pour moi, le lead n’est pas forcément le meilleur développeur technique d’une équipe.C’est pas simplement des compétences techniques pures et dures (connaissance d’un langage ou framework à 100%), c’est surtout beaucoup de relationnel et de capacité d’empathie.
Plus exactement, la technique est indispensable, même s’il n’a pas besoin d’être le meilleur de l’équipe, il doit inspirer la curiosité technique, mais le lead n’a pas que son équipe à gérer, il doit aussi gérer la communication auprès des autres poles et de la hiérarchie, c’est là que la confiance technique joue un rôle important. Dans la pratique, il s’agit de l’interlocuteur privilégié entre une équipe de développement et le chef de projet ou le responsable produit.
C’est lui qui connaît le mieux le système dans sa globalité et qui entérine les décisions d’architectures de code adéquates face aux demandes présentes et futures.
Il est le premier niveau de filtre pour être garant de la faisabilité technique. Il donne souvent des macro chiffrages, des estimations pour conseiller au mieux le responsable produit.
Il doit être force de proposition et être capable de faire converger les contraintes techniques, fonctionnelles et commerciales.
Un bon lead dev n’est pas buté ou obstiné, il est pragmatique et bon diplomate. Il est aussi le manager des développeurs, il connaît les points faibles et forts de son équipe et sait apaiser les tensions et frustration qui pourraient subvenir.
C’est aussi lui qui forme les nouveaux aux pratiques de la société et qui est garant de l’épanouissement technique de ses développeurs plus expérimentés.
Un bon lead connaît son équipe et passe du temps avec chacun, en 1 à 1, pour anticiper les changements. On devient lead dev car on a:
- Coder la première version de l’application et que des nouveaux arrivent par la suite,
- Parce qu’il y a au sein d’une équipe de dev en place des tensions ou problèmes de communication et qu’il faut mettre un intermédiaire pour le bien du projet.
Un bon lead dev se doit d’être organisé pour pouvoir restituer ces informations sur demande, et être capable de synthétiser pour être le plus pertinent possible. Il est néccessaire qu’il couche tout par écrit au lieu de faire confiance à sa mémoire, sinon le jour de la passation de compétences à un autre lead dev risque d’être très compliqué voir impossible à faire. A cela s’ajoute aussi que ça peut aussi être un frein pour les autres développeurs car ils devront tout le temps demander à leur lead pour avoir la moindre information.
Dans la pratique la journée type d’un lead dev est de:
- Faire de la revue de code pour conseiller et garantir une uniformité de code pour la maintenance future. C’est essentiel pour encadrer de jeunes développeurs et pour vérifier que le code ne partent pas dans toutes les directions.
- Participer à toutes les réunions de conceptions fonctionnelles et techniques pour apposer sa validation technique
- Imaginer, mettre en place des outils de qualité pour que l’équipe de développement soit la plus efficiente possible (r&d et qualité).
Comme disait un lead dev, “je fais tout ça pour ne pas avoir d’arnaques dans le futur” 🙂
Étiquettes : philosophie de comptoir
