Notes sur The Manager's Path

Voici ma sélection de citations et de notes sur le livre The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change.

Introduction au management

Management 101

Plus vous devenez senior dans votre métier de développeur, plus votre manageur attend de vous que vous lui apportiez des solutions, pas des problèmes.

The secret of managing is keeping the people who hate you away from the ones who haven't made up their minds.

Encadrement

Mentoring

L'écoute et l'empathie sont les compétences fondamentales d'un manageur de qualité.

Un manageur doit aider son équipe à réussir en fixant des objectifs clairs, ciblés et mesurables.

En voulant créer une culture d'excellence, le geek alpha finit par créer une culture de la peur. Soyez prudent en leur donnant des postes de manageur et surveillez de près leur impact. C'est peut-être la culture féministe de l'auteure qui installe la connotation péjorative du terme alpha geek ici.

Encadrer une nouvelle recrue est l'occasion d'observer ce qui n'est pas évident pour lui. Vous pourriez vous rendre compte qu'il y a des choses que vous pensiez comprendre, mais que vous ne pouvez pas expliquer clairement.

Lead tech

Tech lead

La définition exacte du rôle de responsable technique (ou tech lead) varie d'une organisation à une autre.

La définition de Patrick Kua dans Talking with Tech Leads :

Un responsable d'une équipe de développement de logiciels, qui passe au moins 30 % de son temps à écrire du code avec l'équipe.

Attribuer le rôle de tech lead automatiquement au meilleur ingénieur est parfois une erreur que font même les manageurs expérimentés.

La pire erreur de planning est de se laisser entraîner dans des réunions : il est très difficile d'écrire du code si vous êtes interrompu toutes les heures.

Principaux rôles :

• architecte technique et analyste métier
• management de projet
• développeur et leader de son équipe
• aide le management (CEO, responsable produit, etc.) à garder le focus sur les objectifs
• limite le nombre de réunions pour son équipe
• veille à la diffusion d'un niveau d'information égal au sein de l'équipe

Management de projet par le responsable technique :

• identifier les tâches métiers ayant le plus de valeur
• décomposer les tâches métiers en tickets
• approfondir les détails et les zones d'ombre : ne pas s'arrêter quand vous en avez marre ou êtes coincé
• tenir tout le monde au courant quand les délais s'allongent (et c'est toujours le cas)
• gérer les changements de priorités : être clair sur le coût d'un tel changement
• pour une grosse fonctionnalité : faire un pré-mortem, un plan de lancement, un plan de rollback, et ne pas oublier de célébrer

Comment être un bon tech lead ?

• comprendre l'architecture
• jouer en équipe et déléguer les parties funs
• déterminer quelles décisions doivent être prises par :
  • le tech lead
  • ceux ayant davantage d'expertise
  • l'ensemble de l'équipe
• communiquer clairement et fournir fréquemment du feedback individuel

Les responsables techniques qui réussissent :

• écrivent bien
• lisent attentivement
• peuvent parler devant un groupe

Manager des personnes

Managing people

Construire une relation et instaurer la confiance dès le premier 1:1 :

• comment aimez-vous être félicité, en public ou en privé ?
• comment vous faire un retour d'information sérieux, par écrit ou à l'oral ?
• pourquoi avoir décider de travailler ici ?
• comment savoir si vous êtes de mauvaise humeur ?
• y a-t-il des choses qui vous mettent toujours de mauvaise humeur et que je devrais savoir ?
• y a-t-il des comportements de manageur que vous détestez ?
• avez-vous des objectifs de carrière clairs que je devrais connaître pour vous aider à les atteindre ?
• avez-vous eu des surprises depuis votre arrivée, bonnes ou mauvaises ?

Voir Questions for our first 1:1.

Les 1:1 réguliers sont comme les vidanges, ne les ignorez pas au risque d'être bloqué sur l'autoroute au pire moment.

Quand quelqu'un fait quelque chose qui nécessite un retour immédiat, n'attendez pas le 1:1 pour le faire.

Pour une nouvelle recrue :

• fixer des objectifs clairs réalisables pendant les 90 premiers jours vous aidera à détecter une erreur de recrutement
• la faire participer à la mise à jour de la documentation d'onboarding
• lui communiquer clairement votre style et vos attentes
• en obtenir un maximum de feedback pendant les 90 premiers jours

Les problèmes sur le lieu de travail doivent être traités ou mis de côté d'un commun accord. Il y a peu de valeur à revenir constamment sur un drama.

Les pires micro-manageurs sont ceux qui demandent constamment des informations qu'ils pourraient obtenir facilement par eux-mêmes.

Identifier le potentiel : nos biais cognitifs nous conduisent à supposer un potentiel, à accorder aux gens le bénéfice du doute, alors qu'ils ont montré depuis longtemps que leur "potentiel" est une illusion.

Or un vrai potentiel se révèle rapidement :

• par un travail soutenu pour faire le petit effort supplémentaire
• par des suggestions perspicaces sur les problèmes
• par une aide dans des domaines auparavant négligés

Vous devez bien comprendre le travail qu'une personne est censée fournir et, si ce n'est pas le cas, lui faire comprendre très tôt et lui dire souvent qu'elle ne répond pas aux attentes.

Savez-vous comment fonctionne le processus de promotion dans votre entreprise ? Sinon, pouvez-vous demander à quelqu'un de vous l'expliquer ?

Manager une équipe

Managing a team

Les leaders techniques sont capables :

• d'identifier les projets ayant le plus de valeur
• de garder l'équipe concentrée sur ces projets
• d'identifier les besoins en effectifs de l'équipe et de recruter pour y répondre
• d'identifier les domaines où la dette technique est stratégique

Pour gagner le respect d'une équipe de développeurs, ils doivent vous considérer crédible techniquement. Si vous arrêtez d'écrire du code trop tôt dans votre carrière, vous risquez de ne jamais acquérir un savoir-faire technique suffisant.

Débogage des équipes dysfonctionnelles :

• quand ça ne livre pas :
  • est-ce à cause des outils et/ou procédures ?
  • y a-t-il une procédure lourde de tests manuels ?
  • les fonctionnalités sont-elles trop grosses ?
  • les développeurs savent-ils comment découper une tâche ?
• drame humain : les personnes négatives ne doivent pas rester dans cet état d'esprit trop longtemps au sein de votre équipe
• mécontentement lié à la surcharge de travail : si la cause est l'instabilité de la production, c'est au manager de ralentir la feuille de route du produit afin de mettre le focus sur la stabilité
• problèmes de collaboration : pas de solution miracle, s'il existe une volonté d'améliorer les choses, cherchez à créer des opportunités pour par exemple vous retrouver sans parler uniquement du travail

Les membres d'une équipe qui fonctionne sont prêts à prendre des risques et à faire des erreurs les uns devant les autres. La sécurité psychologique est la base d'une équipe qui réussit. Test d'une équipe qui fonctionne : "si vous achetez une pizza un soir, votre équipe restera-t-elle, ou se précipitera-t-elle vers la porte le plus vite possible ?"

Pour obtenir la compréhension et la crédibilité technique nécessaire pour être considéré comme un leader compétent quand vous rejoignez une petite équipe :

• demandez à quelqu'un de vous présenter :
  • les systèmes
  • l'architecture
  • les procédures pour tester
  • les procédures pour mettre en production
• suivez la procédure d'onboarding si elle existe
• passez un peu de temps à vous familiariser avec la base de code
• commencez à regarder les revues de code et les pull requests
• prévoyez de travailler sur au moins quelques fonctionnalités au cours de vos 60 premiers jours
• faites équipe avec l'un des développeurs sur la fonctionnalité sur laquelle il travaille

Chaque fois qu'on vous demande une estimation de temps, prenez votre estimation et doublez-la.

Comment votre équipe prend-elle ses décisions ? Y a-t-il une procédure d'attribution de la responsabilité décisionnelle ?

Manager plusieurs équipes

Managing multiple teams

Quand on écrit du code, on a souvent des opportunités de quick wins, surtout les développeurs expérimentés. Quand on manage, on a beaucoup moins d'opportunités de quick wins, surtout les nouveaux managers.

Pour devenir un bon manager, vous devez vous concentrer sur les compétences de management et renoncer à une partie de votre implication dans le domaine technique.

Gérer votre temps se résume à comprendre la différence entre importance et urgence.

Des réunions courtes mais productives exigent que tous les participants fassent un travail préalable pour arriver préparés.

Une réunion peut être urgente, mais pas importante, et vous pouvez décider de ne pas y assister. Soyez prudent avec cette stratégie à ce niveau particulier de management. Pendant les réunions, regardez votre équipe pour évaluer son engagement. Si la moitié d'entre eux s'endorment, regardent en l'air, sont sur leur téléphone/ordinateur portable, ou se désengagent d'une autre manière, la réunion leur fait perdre leur temps.

Délégation :

• déléguez les tâches simples et fréquentes
• occupez vous des tâches simples et non fréquentes si c'est plus rapide, même si vous jugez que c'est indigne de vous
• servez-vous des tâches complexes et non fréquentes comme opportunités de formation pour les futurs leaders

Stratégies pour dire non :

• "oui, et…" : oui nous pouvons faire ce projet, il suffit de retarder cet autre projet de la roadmap
• "aidez-moi à dire oui" : posez des questions sur les éléments qui vous semblent douteux
• travailler en équipe : agissez ensemble pour dire non
• ne pas tergiverser

Évaluer la santé de votre équipe de développement :

• fréquence des changements et des mises en production
• travaux en cours visibles et mis à jour régulièrement
• fréquence des incidents et stabilité du logiciel

Faites attention à ne pas vous concentrer uniquement sur vos équipes en excluant le reste du groupe.

Comprendre les objectifs d'une équipe peut prendre du temps. Dans les startups en démarrage en particulier, il y a souvent une certaine confusion quant aux objectifs ou à la mission sous-jacente. Essayez de comprendre la culture de l'entreprise. Collaborez avec les autres équipes pour avoir une vue d'ensemble de la situation.

Chaque fois que vous voyez quelque chose qui vous semble inefficace :

• pourquoi ça me semble inefficace ?
• quelle est la valeur de ce que nous sommes en train de faire ?
• pouvons-nous livrer cette valeur plus rapidement ?
• pouvons-nous simplifier ça et le rendre plus rapide à faire ?

Manager des managers

Managing managers

Faire des skip-level meetings une fois par trimestre, c'est à dire des réunions avec des collaborateurs sans la présence de leurs responsables directs.

Par exemple, des 1:1 brefs :

• qu'est-ce qui vous plaît le plus ou le moins dans votre projet actuel ?
• dans votre équipe, qui travaille vraiment bien en ce moment ?
• avez-vous des retours à faire sur votre manager ?
• quels changements pourrions-nous apporter au produit ?
• y a-t-il des opportunités que nous ratons ?
• y a-t-il des aspects de la stratégie commerciale que vous ne comprenez pas ?
• que pourrions-nous faire pour rendre le travail dans l'entreprise plus agréable ?

Un manager est responsable de la santé et de la productivité de l'équipe. Faire un mauvais choix de personne est une erreur, mais la maintenir à cette position une fois que vous avez réalisé qu'elle n'est pas la bonne est une erreur critique.

Déboguer des équipe dysfonctionnelle :

• ayez une hypothèse
• inspectez les données : chats, e-mails, tickets, dépôt de code, calendriers etc. de l'équipe
• l'équipe passe-t-elle de nombreuses heures par semaine en réunion ?
• le manager fait-il des 1:1 ?
• observez mais soyez conscient que votre présence modifie le comportement de l'équipe et peut cacher le problème que vous essayez de trouver
• posez des questions, demandez à votre équipe quels sont ses objectifs
• vérifiez la dynamique de l'équipe : les gens s'apprécient-ils ?

Traitez les projets techniques comme les projets produit. Lorsqu'un développeur vient vous voir avec un projet technique qu'il voudrait faire :

• quelle est la taille de ce projet ?
• quelle est son importance ?
• peut-on expliquer sa valeur à ceux qui nous le demandent ?
• quels bénéfices en cas de réussite pour l'équipe ?

Rédigez la description du poste de manager qui vous rendra des comptes. De quoi est-il responsable ? Comment allez-vous l'évaluer ?

Ne faites pas de compromis sur l'adéquation avec la culture de l'entreprise. Beaucoup de gens sont réticents pour recruter des managers à l'extérieur, et ce à juste titre.

La cour des grands

The big leagues

Si le CTO ne siège pas dans l'équipe de direction et ne capte pas les enjeux commerciaux, il ne peut pas orienter la technique.

La communication dans les grandes organisations est difficile. D'après l'expérience de l'auteure, la plupart des gens ont besoin d'entendre quelque chose au moins trois fois avant que ça ne rentre. N'ayez pas peur de vous répéter, trois fois est souvent le chiffre magique.

La "culture tech" actuelle a tendance à faire passer les développeurs pour les personnes les plus intelligentes. Les autres métiers ne sont pas stupides. Les abreuver de jargon technique qu'ils ne connaissent pas nous fait paraître stupides à leurs yeux.

Établir une culture

Bootstrapping culture

Si vous voulez créer de bonnes équipes, vous devez avoir une idée de ce qui est important pour vous, pour votre entreprise et pour votre équipe de collègues.

Un manque apparent de structure cache trop souvent un leadership informel, à cause de la nature de la communication humaine et des défis à relever pour la faire passer à l'échelle. Voir The Tyranny of Structurelessness.

La culture est la façon dont les choses se font, sans que les gens n'aient à y penser. C'est généralement un ensemble de règles tacites d'une communauté.

En l'absence de règles en matière de rémunération, la plupart des personnes sont payées en fonction de leur précédent salaire et de leurs capacités de négociation. Créez une grille de rémunération avec différents niveaux (de l'ingénieur débutant à l'exécutif) divisés en catégories :

• compétences techniques
• capacité à mener son travail à terme (getting stuff done)
• impact
• communication et leadership

Ce qui fonctionne pour une entreprise ne fonctionne pas toujours bien pour une autre.

Loi de Conway : les organisations qui conçoivent des systèmes tendent inévitablement à produire des designs qui sont des copies de la structure de communication de leur organisation.

Code review is largely a socialisation exercise, so that multiple team members have seen and are aware of the changed code.

Conclusion

Pour progresser dans la gestion des conflits, il faut savoir retirer son ego de la conversation. Pour avoir une vision claire d'une situation complexe, vous devez voir au-delà de vos interprétations et des histoires que vous vous racontez. Vous devez apprendre à reconnaître la voix de votre ego.

Examinez vos réactions émotionnelles et observez quand ces réactions font qu'il est difficile de voir clairement ce qui se passe autour de vous et ce qui doit être dit.

D'autres synthèses du livre :

• The Manager’s Path by Camille Fournier
• Learning Notes - The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change