La transition vers un poste de direction peut être difficile. Un jour, vous développez et révisez du code. Le lendemain, vous gérez non seulement des individus, mais une multitude d’équipes, évoluant vers une personne sociable et menant votre équipe vers une productivité maximale. Chaque responsable de l’ingénierie est différent, tout comme ses rôles, ses responsabilités et ses idées pour améliorer ses équipes. Cependant, à travers le spectre, voici les défis communs auxquels chaque responsable de l’ingénierie est confronté à mesure qu’il accélère son parcours logiciel.
Que fait un responsable de l’ingénierie ?
Mis à part ce que dit un JD d’EM, l’objectif ultime du poste est le même partout : aider les développeurs à devenir maîtres de leur travail. Cependant, en tant que gestionnaire, les résultats et les éléments de travail ne sont pas aussi tangibles que ceux d’un ingénieur. Un EM passe idéalement du temps à diriger des rétros, à encadrer et à gérer le bien-être des membres de l’équipe. Il n’est pas facile de créer un journal de validation direct pour les managers, un peu comme les ingénieurs. Pourtant, il existe des points communs pour la plupart des responsables de l’ingénierie dans trois catégories :
- Technique
- Gestion d’équipe
- Administration
Les responsables de l’ingénierie ne développent généralement pas beaucoup de code eux-mêmes, mais gèrent le SDLC, travaillent sur les meilleures pratiques d’équipe, lisent les mises à jour logicielles et associent des coéquipiers pour des projets. Du côté de la direction, ils dirigent des réunions stratégiques, se coordonnent avec les équipes produit et commerciales, créent des échéanciers spécifiques aux projets et assurent le bonheur et la vitalité de l’équipe. Un autre domaine d’intérêt pour les responsables de l’ingénierie consiste à recruter de nouveaux chefs d’équipe, à rencontrer des candidats et à assister à des conférences. Maintenant que nous savons ce que font les responsables de l’ingénierie ; découvrons les défis communs auxquels ils sont confrontés.
1. Bloqueurs SDLC élevés, faible visibilité du flux de travail
Le SDLC d’aujourd’hui est guidé par la culture de l’amélioration continue et des itérations continues. C’est le rôle d’un responsable de l’ingénierie de comprendre les obstacles auxquels ses développeurs sont confrontés pour obtenir des résultats ; ou les processus nécessitant une certaine optimisation. Un SDLC faible est un tueur de vitesse silencieux, mais la plupart des managers trouvent difficile de savoir le « quoi » et le « pourquoi » derrière. En discutant avec des centaines d’EM, nous avons constaté que les gestionnaires savent que quelque chose dans leur processus actuel est à la traîne et ont des résultats de métriques comme des étoiles du nord ; ils n’ont tout simplement pas les bons indicateurs ou la bonne approche pour aller de l’avant. L’une des raisons derrière l’énigme persistante du gestionnaire est la visibilité limitée.
La visibilité est importante
Mais quel est le problème? La visibilité est immédiatement corrélée à l’agilité et aide les managers à rester au courant de tout ce qui se passe au sein de leurs équipes de développement. Les problèmes de visibilité peuvent entraîner une hiérarchisation insoutenable, un retard de publication élevé pour les EM, un processus SDLC ambigu et des workflows de développement interrompus. Ne regarder que les métriques de l’étoile du nord pourrait ne pas aider les responsables de l’ingénierie à évaluer les prochaines étapes ; ce dont ils ont besoin, c’est d’une image claire de chaque phase du développement logiciel – depuis ce qui se passe dans la planification (tendances sprint sur sprint), l’exécution (délai, taille de déploiement) jusqu’aux livraisons au client final (stabilité du logiciel) pour évaluer où le vrai problème réside.
La plupart des managers à qui nous avons parlé ont eu du mal parce que leurs équipes n’effectuaient pas suffisamment de livraisons et étaient jugées « lentes ». L’examen de la métrique du temps de cycle leur a donné une valeur limitée ; Cependant, après avoir centralisé tous les indicateurs de processus en un seul endroit, ils ont pu constater que les développeurs travaillaient en dehors des heures de travail et que la charge de travail devenait insupportable. Ce n’est que lorsque les managers ont obtenu une visibilité complète sur le problème qu’ils ont pu créer un plan d’action, reconfigurer le temps et les tâches de l’équipe et gagner la confiance de leurs coéquipiers.
2. Communication interrompue
Les problèmes d’alignement et de changement de contexte entre les équipes logicielles sont réels, et la plupart des responsables de l’ingénierie ont largement reconnu le problème persistant. Et c’est là que réside le deuxième défi majeur d’un responsable de l’ingénierie : résoudre les dettes de communication découlant des deux.
Les responsables de l’ingénierie doivent être constamment mis à jour avec les éléments de travail de leur développeur. L’idée est de faire le point sur l’état actuel de l’équipe : ce que font les ingénieurs, leurs bloqueurs, et comment avancer. C’est pourquoi les stand-ups ont été inventés à l’origine. Aujourd’hui, la plupart des stand-ups concernent plus ou moins les mises à jour de statut et se terminent rarement par des commentaires constructifs ou des discussions sur les bloqueurs.
Même après des appels d’une heure, les développeurs peuvent ne pas savoir comment résoudre leurs bloqueurs. Vous est-il déjà arrivé de savoir que vos développeurs étaient frustrés à cause du travail mais que vous ne pouviez pas comprendre pourquoi ? Le fait de demander aux développeurs des mises à jour constantes peut les éloigner des managers – leurs meilleurs amis/mentors/système de soutien au travail. En permanence, cela peut nuire irrévocablement aux heures de concentration de l’équipe, voire nuire à la productivité des développeurs. Les EM doivent trouver un équilibre entre la prise de mises à jour de statut et la résolution « qualitative » des obstacles au développement. Comment? Des outils autonomes automatisés pour votre pile de communication (Slack, Teams, Emails) peuvent aider les responsables techniques à connaître les tâches de travail quotidiennes et les progrès réalisés, et à identifier les bloqueurs en déplacement.
3. Épuisement des développeurs
En ce qui concerne l’écosystème des développeurs, tout est lié et interconnecté. L’épuisement professionnel des développeurs est devenu un phénomène courant sur le lieu de travail, avec plus de 82% des développeurs passer par des symptômes d’épuisement professionnel inversés. Un responsable de l’ingénierie est considéré comme un pilier de soutien pour ses développeurs et devrait aider à traverser la crise avec beaucoup d’empathie et un plan d’action pour les remettre en forme et dans l’esprit.
Cependant, les managers ne peuvent pas être d’une grande aide pour les développeurs s’ils ne savent pas ce qui cause cette aliénation en premier lieu. Comprendre les raisons du retrait et du manque d’enthousiasme de votre développeur est un défi prioritaire pour les dirigeants d’aujourd’hui. Dans la même enquête ci-dessus, 77 % des développeurs ont accepté que leurs responsables ne soient pas au courant de ce qui se passe. Les causes peuvent aller de demandes ad hoc écrasantes à des conditions de travail dysfonctionnelles, des alertes d’incident et un débogage en dehors des heures de travail. Étant donné que les EM sont déjà confrontés à des problèmes de visibilité au travail, ces signes leur arrivent souvent trop tard. À ce moment-là, soit leurs développeurs très performants abandonnent, se désengagent ou subissent une forte perte de productivité.
4. Charge de travail insoutenable
La répartition de la charge de travail entre les membres peut sembler une tâche directe, mais c’est compliqué et, de loin, l’une des plus difficiles pour un directeur de l’ingénierie. Dans une enquête SmartBrief, seuls 29 % des responsables de l’ingénierie étaient assez confiants quant à la répartition de leur charge de travail. Le problème fait rapidement boule de neige chez les développeurs frustrés si les responsables ont une faible visibilité sur les charges de travail d’ingénierie (le gros problème de la visibilité, hein ?). Parfois, la répartition du travail se fait sans tenir compte des barrières géographiques, des tendances passées de progrès et du partage du travail existant. Vos prochains sprints sont destinés à diminuer si les développeurs ne sont pas en mesure d’éliminer leurs retards précédents en raison d’un travail surchargé.
Les responsables de l’ingénierie doivent trouver des moyens réalisables (et pratiques) de répartir le travail, en particulier en gardant tous les membres sur la même longueur d’onde. Une façon consiste à utiliser la visibilité basée sur les données pour gérer la plaque de travail de votre développeur : révisions des relations publiques, charge des entretiens, tâches WIP, etc. Il est plus facile de planifier un travail productif de cette façon et même de créer des développeurs heureux comme résultat supplémentaire.
5. Mauvaise expérience de développeur
Les développeurs sont doués pour changer d’équipe en fonction de leur progression de carrière, de leur bonheur ou de leur satisfaction globale. Cependant, pour les EM, cette transition est comme une arme à double tranchant : les heures de base consacrées par les développeurs par projet diminuent tandis que le temps de formation et de recrutement ne cesse d’augmenter. Et c’est pourquoi la protection de l’expérience développeur par les managers devient vitale pour l’avenir d’une entreprise.
Un bon DX ne doit pas nécessairement suivre l’approche de Steve Jobs, il s’agit d’améliorer l’implication et la satisfaction d’un développeur à l’égard du flux de travail actuel. Si votre processus actuel a de longues périodes de révision du code, un déséquilibre de la charge de travail, des problèmes de sécurité, des luttes contre les incendies fréquentes, des versions irrégulières, des charges de travail élevées en matière d’incidents et d’entretiens, et que les développeurs ont dû subir des changements de contexte fréquents et une dette technique ; alors votre vie en tant que directeur de l’ingénierie pourrait prendre beaucoup de peine.
La plupart de ces aspects répertoriés sont négligés car ils ne sont pas faciles à détecter, ou mesurés, appelés complexes, voire désordonnés. Ce que les responsables de l’ingénierie doivent comprendre, c’est comment ignorer ces indicateurs peut nuire à vos développeurs à long terme. Un Great DX est votre « solution miracle » pour garder vos développeurs heureux, atténuer les tendances à l’épuisement professionnel parmi les membres et créer une valeur durable du travail de vos développeurs. Les ingénieurs 10x ne sont plus un mythe ; maintenir DX au fil du temps peut vous aider à en créer un.
Aller au fond des défis d’un responsable de l’ingénierie
L’écosystème des développeurs n’est pas un casse-tête difficile ; la plupart des responsables de l’ingénierie commencent en tant que développeurs et comprennent les points faibles des processus inefficaces. Cependant, sans une bonne visibilité sur les allées et venues d’un développeur, les managers auront du mal à constituer une équipe productive, sans épuisement professionnel et cohérente. La synergie d’équipe, des développeurs heureux et une équipe autosuffisante qui travaille sans bloqueurs (ou en corrige un facilement) sont les caractéristiques du succès d’un responsable de l’ingénierie au travail.
L’utilisation d’une plate-forme de gestion de l’ingénierie peut aider les responsables à maîtriser les workflows de développement et à prendre les bonnes mesures pour atténuer les défis évoqués ci-dessus.
À mesure que les équipes deviennent plus complexes et réparties, les réunions de synchronisation ne devraient pas rester le lieu de référence pour la collaboration ; il est plutôt temps pour les managers de construire une culture axée sur les données qui favorise à la fois les liens et la facilité de travail.