De nombreux leaders de l’industrie du logiciel sont issus des rangs des développeurs en activité. Ils veulent souvent se développer dans la gestion car leur maîtrise de la technologie leur donne confiance, mais ils ne veulent pas abandonner la pratique qui leur apporte franchement leur épanouissement.
Entrez le responsable du codage.
Ce nouveau type de leader est responsable à la fois de la stratégie et de la pratique de la technologie et évolue dans le monde des affaires et de la technologie avec une aptitude égale.
En se tenant au courant de la pratique du codage, ces dirigeants gardent un aperçu du fonctionnement des projets, restent au courant des développements de l’industrie et peuvent percevoir où les changements peuvent le mieux profiter à l’organisation.
Et cette tendance peut aider à résoudre l’un des problèmes les plus épineux de l’industrie du logiciel : le sentiment des développeurs qu’ils sont aux prises avec de mauvais gestionnaires.
Mythe : Les programmeurs ne peuvent pas être de bons leaders
Le travail quotidien du codeur est souvent détaillé, ligne par ligne, bien sûr, et il peut avoir tendance à penser davantage aux arbres qu’à la forêt.
Le danger permanent pour l’ingénieur est de devenir obsédé par la construction de choses, perdant de vue la valeur commerciale de ce qu’il fait. Je considère cela comme le Pont sur la bévue de la rivière Kwaioù la tâche technique temporaire du personnage (la construction du pont) vient éclipser le but beaucoup plus élevé (vaincre l’occupation impériale).
Mais à mesure que les développeurs grandissent dans leur rôle, leur vision englobe davantage les systèmes et les processus en jeu, avec une compréhension des éléments individuels. Au fur et à mesure qu’un développeur qualifié devient vraiment expérimenté, en particulier lorsque sa connaissance du système spécifique en cours de développement devient étendue, il est capable de plonger dans des domaines à forte valeur ajoutée, d’aider à apporter des modifications et de maintenir la vue de haut niveau. En ajoutant à cela une appréciation du côté commercial des choses, on obtient une puissante combinaison de talents.
Le changement de mentalité qui est requis des codeurs ici est de permettre un véritable équilibre des priorités. Alors que les développeurs en activité peuvent avoir tendance à voir tout sauf le codage réel comme une simple interruption, les responsables du codage qui réussissent peuvent garder à l’esprit l’importance des besoins commerciaux et techniques, ce qui s’apparente à un équilibre travail/vie personnelle, où les deux méritent une attention égale.
Le responsable du codage sait comment garder une large perspective qui intègre à la fois les arbres et la forêt, comment passer de l’un à l’autre et, surtout, comment permettre aux deux de s’informer mutuellement afin que les informations circulent entre eux.
Cela inclut, bien sûr, le travail de guider les humains dans l’entreprise.
Mythe : les codeurs sont mauvais avec les gens
C’est une notion tellement éculée. C’est aussi un peu vrai.
Les machines sont logiques et susceptibles d’être contraintes de faire exactement ce que vous voulez en leur disant de la bonne manière. Les gens ne le sont pas. Il y a quelque chose de différent dans le genre diriger les gens. Au fur et à mesure que le programmeur évolue de faire des choses, à diriger d’autres personnes qui font des choses, à diriger des personnes qui dirigent des personnes qui font des choses, cette distinction est amplifiée.
Certaines personnes ont juste un don pour les gens, comment obtenir d’eux leurs besoins, leurs peurs et leurs désirs ; comment percevoir où les conflits de personnalité surviennent ; comment voir où ils peuvent pousser ; et comment s’engager efficacement avec ces forces pour les aider, ainsi que l’entreprise, à réussir.
Pour le reste d’entre nous, ce sont des compétences acquises, parfois durement acquises. Les codeurs ne sont pas différents. En reconnaissant l’importance de l’interaction humaine, le responsable du codage s’engage à acquérir des connaissances et des compétences, tout comme il l’a fait lorsque l’écriture d’une boucle for ou d’un composant fonctionnel était intimidante et étrangère. Le fonctionnement interne de l’entreprise est tout aussi stupéfiant qu’Internet.
La beauté est que le codeur a un vaste avantage pour diriger les autres codeurs et le personnel technique.
Les leaders du codage sont « l’un d’entre nous »
Chaque programmeur reconnaîtra ce scénario : le chef de projet entre et fait des projections absurdes basées sur son diagramme de Gantt. Ou encore plus digne de grincer des dents, commence abuser des mots à la mode. Communiquer efficacement les besoins de l’entreprise aux constructeurs est un art particulier. Être un pont efficace entre les deux est encore plus précieux.
Rien ne remplace l’expérience réelle de la mise en conformité du silicium. Cela se traduit non seulement par une empathie plus profonde pour le travail technologique effectué, mais aussi pour les joies particulières accordées et les péages exigés des gens par la profession.
Il y a beaucoup de valeur à trouver dans le fait de garder vivante la connaissance de ce que c’est que d’être dans les tranchées. La capacité de se mettre à la place du codeur de travail est certainement une grande pièce du puzzle pour améliorer la perception et la réalité performance de la gestion technique.
En faisant des recherches et en réfléchissant à cette question du codage par rapport à la gestion, il m’est arrivé d’apporter une voiture au mécanicien. Le magasin était une grosse opération, mais j’ai vu le propriétaire sortir d’une voiture et ramper dessous pour aider à diagnostiquer un problème. Il y a un certain respect qui vient des ingénieurs avec la volonté et la capacité d’un leader de se lancer dans le vif du sujet.
Ce genre de respect et d’affection se traduit dans le monde du logiciel, où le leader est considéré comme « l’un des nôtres ».
Le leader doit-il continuer à coder ?
En écrivant sur sa propre expérience en tant que codeur et gestionnaire, Mark Porter, CTO de MongoDB, dit « Il existe plusieurs types de CTO. Un directeur technique d’une petite entreprise qui dirige le développement du premier produit de l’entreprise doit absolument coder. Un CTO qui se concentre sur les activités sortantes pour une grande entreprise ne devrait pas le faire. »
Il s’agit d’une reconnaissance réaliste du fait qu’il y a bien sûr des rôles qui exigent que la personne qui le remplit abandonne le codage pratique, mais il y a aussi une place dans le monde pour les personnes qui aiment le codage, qui veulent continuer à y participer, et évoluer également vers le leadership.
De nos jours, il n’est pas difficile de trouver même des leaders éminents possédant des connaissances techniques approfondies. Werner Vogels d’AWS et Brendan Eich de Bravepar exemple, donnent toutes les indications sur la connaissance et l’attention portées aux types de spécificités qui préoccupent les développeurs sur le terrain.
Dans le domaine des outils technologiques, ce type d’expertise est encore plus précieux. Non seulement le responsable du codage est-il mieux à même de communiquer avec les développeurs internes, mais également avec les clients.
Le responsable du codage démontre qu’un programmeur est comme un musicien classique, plutôt qu’un joueur de football ou un pilote de chasse. Un musicien classique peut devenir un chef d’orchestre qui maintient ses prouesses instrumentales pour améliorer son travail.
Lorsque l’on considère la question importante des cheminements de carrière, la notion selon laquelle il faut choisir une voie à suivre entre le codeur en exercice ou le responsable informatique devient moins concrète. Il peut peut-être être vu comme un spectre, au lieu d’une disjonction. D’un côté, le chef d’entreprise pur, de l’autre, l’ingénieur pur. La plupart des DSI, CTO ou autres leaders technologiques mélangeront certains des deux aspects, le leader du codage se situant davantage au milieu du spectre.
Quant à la question, dois-je être un gestionnaire ou un codeur ? La réponse est peut-être : les deux.
Source link