S’intéresser vraiment aux informaticiens.nes

S’intéresser aux informaticiens.nnes, aux développeurs.ses, ce n’est pas juste s’intéresser aux mots-clefs ou encore aller dire bonjour dans des conférences techniques, c’est surtout mettre en place des actions concrètes et régulières, dans le quotidien des équipes techniques. 

Cela passe par : 

1) Initier une culture du droit à l’erreur favorisée par le dialogue, des post-mortem sur les projets : ce que l’on retient, ce que l’on jette, comment faire mieux la prochaine fois, accueillir le feedback des personnes juniors comme des personnes seniors, le feedback des personnes anciennes comme celui des personnes nouvellement arrivées. L’erreur est encore trop vécue comme une source de stress, de tension pour beaucoup de personnes dans les équipes techniques qui ne se sentent pas prêtes à dire les choses avec cette crainte de voir leur période d’essai se terminer. La culture du droit à l’erreur permet donc d’instaurer un cadre indispensable à la sécurité psychologique,

2) Mettre en place une vraie culture de l’accompagnement qui passe par : 

• La mise en place d’une sorte de buddy sur deux semaines avec lequel la nouvelle recrue fera du pair programming. Ce buddy n’a pas forcément un lien hiérarchique avec la nouvelle recrue. Cet individu est là pour aider la personne à être rapidement autonome sur son poste. L’entreprise doit donc bien définir quel est le rôle de ce buddy et les objectifs à atteindre. 
• La mise en place d’une plateforme neutre en interne qui reprend la stack de l’entreprise pour s’entraîner, sans enjeu, sans stress. C’est une bonne façon de percevoir la marge de progression de la nouvelle recrue, et de bien cerner où se situent les blocages. Est-ce une mauvaise compréhension du besoin métier ou alors des méthodes de développement à perfectionner ? 

3) Mettre en place des méthodes de communication claires et régulières : que l’entreprise soit agile ou pas, il est question de savoir comment les personnes évoquent leurs problèmes au quotidien ? Comment elles échangent avec les utilisateurs ? Comment elles se tiennent informées de l’état d’avancement de la solution et comment elles ont compris la vision produit ?

Ce n’est pas juste des discussions informelles à la pause café. 

Cela passe par une bonne documentation, des rituels courts et efficaces, de la revue de code et une définition claire des rôles de chacun. Des pseudos managers, des pseudos tech lead, des pseudos décideurs en somme…cela peut créer beaucoup de confusion et des concours d’ego. 

4) Qu’est-ce qui fait qu’on forme une équipe ? Cela passe par une culture du partage, de l’entraide, mais aussi par une certaine responsabilisation de son propre code qui n’a pas un usage individuel mais bien collectif : est-il compréhensible ? Maintenable ? Réutilisable ?

L’entreprise, avant de se lancer dans l’écriture de valeurs placardées au mur, doit se poser deux questions : quelle culture d’équipe je veux construire et comment j’y vais, qu’est-ce que je mets en place concrètement ? On ne peut pas exiger d’un.e candidat.e qu’il ou elle soit team player si, en face, en entretien, il n’y a pas l’esprit d’équipe, il n’y a pas de soutien, d’entraide, de respect dans la prise de parole. 

Cela peut donc passer par des des meetups internes, par des budgets dédiés à la cohésion d’équipe (séminaires, véritable salle à manger dans les locaux), des espaces de discussion et de partage, l’investissement dans une bibliothèque interne de livres, de l’accompagnement pour devenir speaker dans des conférences, devenir un espace d’hébergement pour des conférences, etc. 

5) Forte implication sur les enjeux business : une équipe technique réalise un code au service des utilisateurs avec, comme objectif, de faire grandir l’entreprise au niveau de son chiffre d’affaires. Ainsi, est-ce que la feature produite créer de la valeur business ? Évidemment toutes les solutions n’ont pas un seul objectif financier mais il ne faut pas pour autant perdre de vue l’idée que l’entreprise doit générer du cash pour payer les salaires, investir en innovation, recruter éventuellement d’autres personnes dans l’équipe pour éviter la surcharge de travail. Ainsi s’intéresser aux informaticiens.nes c’est les rendre conscients.es des enjeux business. 

Cela passe par une transparence des chiffres, par une connexion directe avec les utilisateurs, par aussi une valorisation financière de leur travail lorsque le code a permis de faire grandir le CA et/ou de fidéliser les clients, par l’obtention de parts. 

6) Avoir le courage de ses décisions : s’intéresser aux équipes techniques c’est les guider, les accompagner vers une vision, un objectif, Beaucoup d’équipes fonctionnent en roue libre car “entreprise libérée”, car management inactif ou absent. Cela crée une basse-cour avec des poulets sans tête. Ça court dans tous les sens, ça travaille chacun dans son coin, sans concertation, sans connexion entre les personnes.

Ainsi, cela demande un certain courage managérial : avec qui l’équipe souhaite travailler ? A qui on dit non lors des entretiens de recrutement et pourquoi ? A qui on arrête la période d’essai car la personne est toxique au bon fonctionnement de l’équipe ?

Avoir le courage de ses décisions, c’est montrer un chemin, une vision. Les équipes techniques ont besoin de mettre du sens dans ce qu’elles font sans avoir cette impression de coder dans le vide sur un projet qui va être jeté à la poubelle dans un mois. Beaucoup choisissent d’être manager pour le côté uniquement sympa sans le recadrage. Cela devient juste des copains avec les galons hiérarchiques. Et quand il faut trancher sur des choix majeurs pour l’évolution de l’entreprise, il n’y a plus personne. Ces managers ont choisi la casquette de manager pour gérer des équipes qui, finalement, se gèrent parfaitement toutes seules.

S’intéresser aux devs, c’est donc leur donner un environnement favorable pour bien travailler : donner une vision, investir dans des outils adaptés, écouter les remontées faites, acter, expliquer, se remettre en question aussi et faire en sorte que les choses avancent dans le bon sens avec une équipe soudée qui sait où elle va. 

7) Investir dans la tech : investir dans la technique peut se faire de multiples façons : bien rémunérer les personnes, donner la possibilité aux personnes d’avoir de bons outils de travail, de bons outils pour bien travailler en télétravail, se faire accompagner par des personnes freelance si besoin sur certains sujets spécifiques, humains comme techniques, mettre en place des moyens pour faire progresser les équipes techniquement (conférences, lectures, espaces de formation) et devenir aussi une entreprise sponsor sur certaines technologies. 

Une entreprise sponsor donne des moyens financiers à des devs externes qui travaillent sur certaines technologies, parfois de façon bénévole. Cet investissement dans l’open source, par exemple, permet de soutenir le jus de cerveau de beaucoup de personnes passionnées qui donnent beaucoup d’énergie au niveau de leurs contributions. Il arrive que les devs identifient ces entreprises sponsor comme de potentiels futurs employeurs car ils apprécient leur effort d’investissement. 

S’intéresser aux informaticiens, c’est ni plus ni moins, s’intéresser aux gens : les connaitre, les comprendre, les guider et faire en sorte que les personnes que vous avez recrutées aujourd’hui soient de meilleures versions d’elles-mêmes demain. Ne pas s’intéresser c’est uniquement penser à son petit confort, satisfaire son ego, ses propres intérêts, mais, malheureusement, aucun projet ne va bien loin quand on est seul à bord !

Shirley Almosni Chiche