5 principes pour constituer des équipes technologiques performantes | de Carlo Bertuccini | décembre 2022

Trouver le droit les gens sont la clé du succès

Ici, je ne me concentrerai pas sur les techniques et les processus de travail, il s’agit principalement de principes, de culture et de personnes – et c’est là que je pense que l’efficacité a lieu !

Je gère des équipes depuis plus d’une décennie, j’ai eu plus de 1500 entretiens et je vais partager mon point de vue sur la façon de construire des équipes technologiques performantes.

Commençons par ce qui est peut-être le principe le plus difficile : Tout le monde dans la technologie devrait être en contact avec le code !

Qu’est-ce que je veux dire par tout le monde ? Simple, tout le monde, du stagiaire au directeur technique, en passant par les ingénieurs, managers, responsables de fonctions, etc.

Évidemment, tout le monde ne peut pas avoir le même niveau de contribution, mais tout le monde devrait contribuer ! J’entends déjà l’écho du : « Je n’ai pas le temps, je suis toujours en réunion » ou alors « c’est plus important que je mette l’équipe en condition d’exécuter plutôt que d’être moi-même un exécuteur ».
J’ai rempli chacun des rôles susmentionnés, de stagiaire à CTO et il n’y a aucune raison valable qui devrait vous empêcher de contribuer.

Mais pourquoi est-ce si important ?

• Pour obtenir la confiance des gens, ils ont besoin que vous puissiez comprendre ce qu’ils disent au niveau des détails, ils ont besoin que vous soyez capable de lire du code et de fournir des commentaires précieux, ils ont besoin que vous puissiez être autonome suffisant pour recueillir un certain niveau d’informations plutôt que de toujours leur demander de vous chercher.
• Si la situation devient difficile, avec des délais serrés et du stress pour l’équipe, vous devez être capable de retrousser vos manches et d’aller dans la boue avec eux. Rien d’autre ne les aidera, aucune promesse d’un avenir meilleur avec un meilleur rythme ne peut les aider autant que votre présence et votre contribution.

Il n’y a aucune entreprise pour laquelle j’ai travaillé qui n’avait pas « architectes », mais quand j’ai eu la chance de monter un département technique en partant de zéro, c’est le premier rôle que j’ai banni ! Faire dessiner des solutions par des architectes sur un tableau blanc, alors que d’autres personnes doivent les exécuter, est tout simplement toxique : les ingénieurs ne sont pas des singes et les décisions architecturales doivent toujours être prises avec quiconque a les mains sales de code !

Je ne fais pas confiance à une équipe d’élus qui prend des décisions pour toutes les autres équipes de l’entreprise. Si vous avez des personnes aussi talentueuses, vous devez les répartir au sein des équipes et les laisser contribuer tout en coachant les autres. Comment les gens peuvent-ils grandir si on leur fournit des solutions et non le processus de construction de ces solutions ? Comment une solution peut-elle être efficace si elle ne prend pas en compte tous les « détails » qui ont un impact énorme sur la mise en œuvre ?

Peut-être que votre question est maintenant : si vous n’avez pas d’architectes, comment prenez-vous des décisions complexes en matière de conception et d’architecture ? En mode collaboratif, à travers des documents de conception. Toute personne ou équipe ayant un besoin ou une amélioration à proposer se contentera de créer un document, expliquant le problème à traiter et une (ou plusieurs) solution possible, que tout le monde dans l’entreprise pourra commenter. Lorsque la conception atteint un état qui satisfait toutes les parties impliquées, elle entre en exécution.

Cela vous semble-t-il simple ? C’est simple!

Cela ne signifie pas que, lorsque des décisions rapides sont nécessaires, un groupe restreint de personnes bien informées ne peut pas s’asseoir ensemble et avoir une solution rapide à un problème, de toute façon cela ne devrait pas être la façon normale de travailler, mais plutôt l’exception.

J’ai remarqué trop souvent des séparations, la plus évidente étant toujours avec les externes. Dans de nombreuses réalités, j’ai vu des consultants non pas considérés comme faisant partie de l’équipe, mais plutôt comme une sorte de side-car. Ils ne sont pas impliqués dans les réunions décisionnelles, on leur demande de faire le travail merdique que les internes ne veulent pas faire, ils ne sont pas invités à des événements sociaux, etc. – comment cela peut-il aider ?
Avez-vous déjà entendu cette phrase :

« ils sont externes, ils s’en fichent »

Je parie que oui, mais est-ce la vérité ? Peut-être que la pleine vérité est que « ils sont traités comme des entités externes, ils ne se sentent pas intégrés à l’équipe et au projet, donc ils s’en moquent un peu »

Si vous les traitez de manière équitable, si vous les impliquez et si vous leur faites sentir qu’ils font partie de quelque chose, vous pourriez obtenir bien plus que la production actuelle.

Si vous embauchez des personnes formidables, vous devez leur donner les moyens de prendre des décisions importantes ; vous serez surpris par la sortie. Je veux partager un exemple.
Chez mon employeur actuel, iptiQ, nous avons commencé avec une nouvelle base de code écrite en Java. La raison du choix de Java est très simple : c’était le langage que peu d’entre nous connaissaient lorsque le projet a démarré — après quelques mois, au cours d’une technologie à tout faire, ont déclaré quelques développeurs.

« Nous devrions utiliser Kotlin ! C’est un excellent langage de programmation, bien meilleur que Java”

Cette idée a été discutée, et les gens m’ont demandé mon avis :

« Bien sûr, nous pouvons essayer, je ne suis pas un expert en Kotlin, mais n’oubliez pas que c’est toujours une affaire. Assurez-vous donc que si nous y allons, nous ne laissons personne de côté et nous ne forçons pas les gens à travailler à Kotlin dès le premier jour (merci l’interopérabilité !) »

Ma peur d’avoir un impact sur l’entreprise ou de laisser des gens derrière ne pourrait pas être plus fausse. Quelques semaines plus tard, il y avait des sessions de coaching régulières sur Kotlin, organisées en interne par les développeurs Kotlin les plus expérimentés. Tout le monde a eu le temps de monter en puissance et 3 mois après cette décision, le seul nouveau code poussé était le code Kotlin. J’ai moi-même appris Kotlin (et j’adore ça), et je dois dire merci à ces gars-là !

Les couches sont bonnes à des fins de gestion, mais la communication ne doit pas suivre le diagramme d’organisation. Si vous savez que la personne la mieux informée sur un sujet dont vous devez discuter est le chef de la zone X, le responsable de l’équipe Y, ou même le CTO, alors vous devriez les approcher directement et leur demander plutôt que de suivre une « chaîne de commandement » , peu importe votre rôle. Et cela va aussi dans l’autre sens, si vous avez besoin de connaître certains détails, vous devriez demander à la personne qui les connaît, et non demander à votre rapport de demander son rapport de demander à l’autre équipe… malheureusement, j’ai vu des environnements toxiques dans lesquels cela était impossible, où le « Chef de n’importe quoi” disait « Je ne veux pas parler avec le responsable technique de cette équipe. Mon homologue pour la technologie est le CTO, je ne parle qu’avec le CTO » – Inutile de dire à quel point c’est stupide à tous points de vue.

D’après mon dernier exemple, il est clair que cela va au-delà de la technologie, cela devrait être appliqué à tous les domaines.

On a vu jusqu’à présent 5 principes que j’adore, j’ajouterais quelque chose de plus lié aux personnes, car, au final, c’est de ça qu’une équipe est faite. Et trouver le droit les gens sont la clé du succès.

Nous disons toujours que nous recherchons des talents, mais qu’est-ce que le talent ? Sans entrer dans la définition du vocabulaire, je dirais que c’est une qualité décrivant à quel point vous êtes bon dans un domaine spécifique : donc si nous construisons une équipe de développeurs ou d’ingénieurs de données, nous voulons avoir des personnes que nous définissons comme « talentueuses », celui qui connaît le sujet dont il traite. C’est important, mais le 2P sont, à mon humble avis, bien plus importants.

Personnalité

J’ai lu une fois une phrase disant « 80% du travail concerne toujours les gens, 20% c’est le reste » et je suis d’accord avec ça. Vous avez besoin de gens formidables, ce qui signifie de grandes personnalités ! Les grandes personnalités peuvent amener des équipes entières au niveau supérieur, elles s’engagent sur des objectifs difficiles et surmontent tout obstacle pour garantir le résultat : elles se concentrent sur la solution et ne se plaignent pas des problèmes. Ils deviennent un modèle, ils établissent une nouvelle norme et, avec les bonnes personnes dans l’équipe, vous verrez que leurs idées deviendront les idées de l’équipe ou même du département. Nous reviendrons sur ce point plus tard.

Potentiel

Trouver des personnes avec un haut potentiel inexprimé est difficile mais très gratifiant. J’ai interviewé une fois une jeune fille, elle revenait travailler après un long congé de maternité. Elle ne savait pas grand-chose de ce que j’ai demandé – j’ai posé des questions de plus en plus simples pendant l’entretien : qu’est-ce que l’injection de dépendances, qu’entendons-nous par faible couplage, qu’est-ce que la composition, pourquoi la mutabilité est mauvaise… très peu de résultats. J’ai donc changé mon approche et lui ai demandé de faire un exercice ensemble. « Nous avons 5 ordinateurs, 1 Go de stockage sur chacun et nous voulons sauvegarder des données dans chacun d’eux : comment pouvons-nous faire ? »

À la fin de l’entretien, elle a écrit le pseudocode d’un algorithme de partitionnement, elle a surmonté mon défi sur la façon d’éviter les points de défaillance uniques en introduisant une réplique pour chaque paire clé-valeur stockée et elle a discuté des optimisations possibles. Elle n’a jamais utilisé aucun de ces mots techniques. J’aurais pu lui demander « dis-moi comment fonctionne une base de données distribuée », et je suis sûr que je n’aurais pas eu de réponse. Cette fille a passé 6 mois à faire du développement en binôme avec un super ingénieur, à apprendre des patrons et des principes, et depuis elle a été très performante ! Elle avait juste besoin de quelqu’un pour croire en elle, et je suis sûr qu’il y a quelques personnes comme elle. Fait amusant, 2 ans plus tard, un jeune homme prometteur m’a demandé

« Carlo, pourquoi m’as-tu embauché ? Je travaille en étroite collaboration avec {{aforementionné-top-performer}} et elle est à un autre niveau. Toute l’équipe est bien plus forte que moi.

« C’est vrai, mais tu lui ressembles beaucoup quand elle a commencé »

Ok, on a mis en avant les bonnes qualités des individus, qu’en est-il des pratiques ?

Les managers doivent coder, ce concept est déjà exprimé. Mais tous les développeurs ne peuvent pas être des managers, et le pire schéma que j’ai vu depuis des années est que les leaders technologiques (c’est-à-dire ceux qui sont doués pour livrer des solutions) sont souvent récompensés par le rôle de directeur de l’ingénierie : c’est le moyen le plus rapide de détruire un équipe.

Une équipe n’a pas besoin d’excellence technique en tant que manager, elle a besoin d’un leader humain avec une compréhension approfondie de la technologie. Il a besoin de quelqu’un avec de l’empathie, de la personnalité (nous y sommes encore), et quelqu’un qui peut attirer les critiques sur lui-même et mettre l’équipe en valeur.
Quelqu’un qui récompense publiquement et reproche en privé, quelqu’un qui s’intéresse au bien-être et à l’épanouissement de chaque individu de l’équipe, quelqu’un qui ne laisse personne de côté, quelqu’un qui écoute… « ouais, c’est une licorne »— Je suis d’accord, ils ne sont pas faciles à trouver, mais ils changent la donne !

J’embauche rarement des managers, j’ai tendance à promouvoir des personnes internes qui font preuve de toutes ces compétences à un niveau constant.