Article original : The path to technical leadership: how to go from developer to team leader
Par Alex Bachuk
Si le développement logiciel semble n'être qu'une partie de votre vocation professionnelle, peut-être devriez-vous envisager de devenir un tech lead. Un tech lead peut signifier différentes choses : un responsable d'équipe (sans subordonnés directs), ou un manager. Par exemple, un engineering manager est une personne responsable de l'équipe et de ses projets. Cela signifie qu'il est également responsable des carrières des personnes, de la croissance de l'entreprise, des livrables, des délais, de la culture, des normes de code, de la dette technique, et plus encore.
Si vous êtes développeur, il peut ne pas être clair comment passer de votre position actuelle à un poste de leadership technique. Si votre objectif est de devenir manager bientôt, vous devrez vous demander pourquoi vous voulez ce rôle. Devenir manager peut ou non correspondre à vos objectifs à long terme.
Je me suis lancé dans le développement logiciel parce que je me sentais plus à l'aise de travailler avec des ordinateurs qu'avec des personnes. Mais après un certain temps, je me suis retrouvé à aider d'autres développeurs de plus en plus. J'aimais diriger des projets et pousser pour de meilleures normes de code. C'était un choix évident pour moi personnellement.
Pour de nombreux ingénieurs logiciels, grandir en tant que contributeur individuel (IC) pourrait être un chemin plus approprié. De nombreuses entreprises offrent des alternatives IC à la gestion. Ces alternatives incluent un staff engineer, un distinguished engineer ou un fellow engineer. Ce sont des rôles techniques très seniors, mais personne ne leur rend de comptes comme ils le feraient à un manager.
Alors, voulez-vous devenir un engineering manager ou un autre type de responsable d'équipe ? Il est important d'être honnête sur ce qui vous motive — est-ce écrire du code et architecturer des logiciels ? Ou est-ce aider les autres à obtenir de meilleurs résultats, négocier des délais avec les parties prenantes, et convaincre votre équipe commerciale que le refactoring de code n'est pas une perte de temps ? Vos réponses à ces questions devraient vous aider à déterminer quel chemin est le plus approprié pour vos objectifs souhaités.
Si vous êtes toujours convaincu qu'un chemin de leadership technique est fait pour vous, alors vous avez du travail devant vous. Envisagez de travailler avec votre manager ou un mentor pour qu'ils vous aident dans les domaines où vous êtes moins familier. Voici un aperçu de dix domaines clés de concentration :
Passer à l'action. Un vrai leader peut diriger sans titre ni autorité. Toute personne avec un titre pompeux et suffisamment d'autorité donnée par l'organigramme peut donner des ordres. Mais ce n'est pas ce qu'est le leadership — il s'agit de ce que vous faites.
Par conséquent, vous devriez commencer petit. Prenez plus de responsabilités lors de projets difficiles. Aidez vos pairs en fournissant des feedbacks dans les pull requests. Proposez-vous pour présenter les mises à jour du projet. Proposez des améliorations pour le workflow de votre équipe ou de votre produit. Mentorez un collègue.
Il y a suffisamment d'opportunités que les gens ne veulent pas voir ou n'ont pas assez d'expertise ou de confiance pour les saisir. Déterminez ce avec quoi vos collègues ont du mal, puis passez à l'action et faites-le.
Responsabilité. Lorsque vous prenez des responsabilités, soyez responsable de tout ce que vous faites ou ne faites pas. Un leader prend ses responsabilités et évite de blâmer les autres pour les erreurs, les délais manqués ou les bugs.
Plutôt que de vous plaindre d'un bug introduit par quelqu'un, aidez-le simplement à le corriger et expliquez comment l'éviter à l'avenir. Trouver des excuses n'aide personne. Prenez le temps de livrer ce à quoi vous vous êtes engagé. Si nécessaire, négociez un meilleur délai avec votre manager. Gérez un projet comme votre propre entreprise et intéressez-vous vraiment à lui.
Récemment, l'un des tech leads de mon équipe a récupéré la dernière branche master. Il a vu une forte baisse de la couverture des tests unitaires. Plutôt que de se plaindre, il a ajouté la couverture des tests manquants. Puis il a présenté comment vérifier correctement la couverture et comment écrire un test unitaire pour des fonctionnalités complexes. Il a proposé de l'aide si quelqu'un en avait besoin sans blâmer personne. L'équipe a apprécié cela.
Relations (ou politique). Parfois, les gens interprètent mal les relations et les appellent "politique". Ce sont les mêmes choses. Si vous ne voulez pas traiter avec la "politique", alors peut-être devriez-vous réfléchir à nouveau si vous voulez vous lancer dans le leadership en premier lieu.
Construire des relations significatives est l'une des responsabilités des engineering managers. Le management consiste à faire faire les choses par d'autres personnes. Commencez à construire de bonnes relations avec d'autres engineering managers. Ils sont vos futurs pairs.
Il y a plusieurs façons de faire cela, comme présenter des tech talks, faire des ateliers, et mentor des développeurs en dehors de votre équipe. Les engineering managers apprécieront les relations que vous construisez à travers ces tâches.
Expertise technique. Un engineering manager doit être un ingénieur avant tout. Ils doivent avoir une solide expérience en ingénierie logicielle et une expérience pratique. Devenir l'un des meilleurs ingénieurs de l'équipe est une exigence. Un manager qui ne peut pas coder ou ne comprend pas les détails techniques ne peut pas participer aux discussions techniques. Une fois que vous devenez manager, vous devez toujours garder vos compétences assez aiguisées pour être compétent en architecture de haut niveau.
Mentorat. Tout "vrai bon développeur" de l'équipe qui n'est pas un joueur d'équipe est plus nuisible qu'utile. Si vous êtes techniquement fort, alors vous devriez aider les autres à atteindre votre niveau. Le pair programming, les revues de code, les présentations, les projets open source ou inner source sont tous de bons exemples de la façon de commencer à mentor les autres.
Il est rare que quelqu'un vienne vous voir et vous demande de le mentor. Pourtant, en vous brandissant "l'expert" et en faisant proactivement les choses mentionnées ci-dessus, les gens viendront naturellement vous demander conseil. En aidant les autres, vous construisez des relations significatives et gagnez le respect des gens. Espérons qu'ils fassent de même en retour et mentorent les autres également.
Gestion de projet. Livrer des projets à temps est l'une des responsabilités principales de tout leader. Si, en tant que développeur, vous manquez constamment des délais et sous-estimez les tâches, les autres ne peuvent pas vous faire confiance. Vous devez être organisé et maîtriser vos tâches.
Nous savons tous que l'estimation des projets logiciels est difficile en raison de l'incertitude. Cependant, avec le bon processus, ce n'est pas impossible. Communiquez constamment les progrès et les attentes du projet avec votre manager ou les parties prenantes.
Par exemple, mon équipe fait un rapport d'état hebdomadaire, où les tech leads du projet ont l'opportunité de communiquer les progrès, de mentionner tout blocage ou de soulever une préoccupation majeure de non-livraison à temps.
Communication. Communiquer clairement et de manière concise est une caractéristique très importante de tout leader. Si vous ne pouvez pas expliquer clairement ce que vous attendez de votre équipe, alors vous avez échoué en tant que leader avant même que le travail ne commence.
La communication prend de nombreuses formes, y compris verbale, écrite et même le langage corporel. Travaillez toujours à améliorer toutes vos compétences en communication.
Mon équipe a manqué quelques délais parce que j'ai échoué à communiquer les exigences clairement et à temps. Il y a eu quelques cas où le manque de communication a créé de la confusion dans l'équipe sur qui devait faire quoi. J'ai appris que compter sur les chefs de projet ou les parties prenantes commerciales pour expliquer les détails du projet ne fonctionne pas. Un engineering manager doit comprendre le projet et ensuite l'expliquer et le vendre à l'équipe. Et les motiver à vouloir travailler dessus.
Gérer vers le haut. Gérez votre manager (et parfois leur manager). Cela signifie communiquer constamment avec eux et gérer les attentes. Les managers n'aiment rarement les surprises, bonnes ou mauvaises. Établissez des relations de confiance avec votre manager. Soyez la personne de référence pour les projets importants et de haut profil, et réalisez-les réellement à temps et dans le budget. Ensuite, d'autres projets suivront et vous pourrez répéter le processus.
Conflits et crises. Les problèmes de production arrivent, peu importe le nombre de tests unitaires ou d'intégration que vous avez. Oui, vous voulez minimiser le nombre de bugs dans vos projets. Ce qui compte plus, c'est comment vous gérez les problèmes de production. Une personne qui commence à paniquer sous pression est immédiatement disqualifiée en tant que leader aux yeux des autres. L'équipe et les autres managers veulent voir une personne calme qui a tout sous contrôle, même dans les situations les plus stressantes.
Un tech lead avec qui je travaillais était toujours calme. Il n'y avait aucun conflit ou pression qui pouvait le faire craquer. Au moins, personne ne l'a vu stressé. Lorsqu'il s'agissait de gérer un problème de production à 3h du matin, il n'a pas déçu. Le problème a été résolu en quelques minutes et il est venu au travail comme si rien ne s'était passé.
Un autre tech lead était tellement stressé par le délai qu'il a appelé malade le jour où nous devions lancer la fonctionnalité. Il était tellement anxieux que cela a rendu tout le monde autour de lui mal à l'aise de travailler avec lui.
Bien que ce soient deux opposés complets, vous pouvez deviner lequel a été le plus réussi en tant que tech lead.
Vision. Pour tout ce dont ils sont responsables, un leader doit comprendre "pourquoi". Ils sont également responsables de s'assurer que tout le monde comprend "pourquoi" ils travaillent sur un projet. Un leader doit expliquer (souvent plusieurs fois) pourquoi le projet se fait, pourquoi les personnes spécifiques travaillent dessus et comment ce projet s'intègre dans le "grand tableau". Une équipe doit croire en ce qu'elle fait, seulement alors peut-elle être efficace.
Dirigez la voie vers l'avant, dès aujourd'hui
Le leadership n'est pas limité à une ou deux personnes, alors n'attendez pas la permission, passez à l'action dès aujourd'hui. Soyez un expert dans votre domaine et commencez à aider les gens lorsqu'ils sont bloqués. Travaillez sur vos compétences en communication, même quelque chose de mineur comme la documentation technique. Construisez de grandes relations professionnelles avec vos pairs actuels et futurs. Assurez-vous de gérer votre temps avec sagesse et de maîtriser les délais de vos projets. Et n'oubliez pas que le leadership concerne les personnes, alors aidez sincèrement les gens à grandir et à faire de leur mieux.
Vous pouvez me trouver sur Twitter https://twitter.com/netxm si vous avez des questions ou si vous voulez simplement dire "salut".