En dehors du titre, le générique masculin est utilisé sans aucune discrimination et uniquement dans le but d'alléger le texte.

Garder les développeurs heureux c’est super compliqué. Et je comprends pourquoi autant de boîtes sont en galère. Le dev sauvage est une bien curieuse espèce dans un environnement à son avantage. Du coup, j’ai posé la question à énormément de dev autour de moi. Je me suis posé moins même la question. Aujourd’hui je te dévoile tout ce qu’il faut savoir.

Lancer un défi

C’est évidemment ce qui revient instantanément dans toutes les discussions. Nous voulons plus de connaissances et de maîtrise de notre métier. C’est compliqué ce métier. T’as plein de dev qui partent immédiatement en crise d’épilepsie s’ils restent pas au top de ce qu’ils font. Ce métier est infernal niveau rythme, donc ça se comprend. Les boîtes qui prennent bien en compte cette réalité augmentent de façon incroyable leur rétention de dev.

Pour faire ça efficacement, le meilleur moyen est de lancer un défi technique à tes développeurs. Un projet qui va demander du temps et de l’expertise. Quelque chose qui va les pousser dans leurs retranchements niveau connaissances. Un défi qui donne envie.

Concrètement, il faut que tes développeurs se disent qu’ils perdent pas leur temps à rester dans ta boite. Si c’est vraiment le cas, franchement t’as déjà fait la moitié du boulot pour les garder. Mais ça veut pas dire que c’est suffisant.

Promouvoir l’apprentissage

Pour renforcer le point précédent, il faut mettre en place une politique d’apprentissage. Énormément de développeurs pratiquent ce qu’on appelle de la veille technologique. Ils le font dans leur temps libre. La plupart des boîtes refusent que du temps soit alloué pour de telles choses. C’est complètement con ça. Tout le monde est gagnant à allouer du temps de veille.

La boite est gagnante car ses développeurs font de l’amélioration personnelle et ça se verra sur la qualité du boulot produit. Les développeurs sont gagnants car ils n’ont plus à le faire pendant leur temps libre.

Et là je te parle pas d’un truc de l’enfer qui va bloquer une journée à tout le monde. Allouer une à deux heure(s) par semaine de veille technologique à tes développeurs est déjà un argument béton. Pareil les boîtes qui font un effort là-dessus sont un cran au-dessus côté rétention.

Liberté technique

Tes développeurs ne veulent pas bêtement suivre une tâche. Tes développeurs veulent du pouvoir sur ce qu’ils construisent. Pour garder un développeur, il faut lui laisser une liberté technique dans ses technologies et sa façon de régler les problèmes. Alors évidemment on parle ici de développeur avec assez d’expérience pour prendre des décisions techniques décisives. Mais c’est vraiment important.

Il n’y a rien de mieux que de donner du pouvoir sur la partie technique à tes développeurs. Il y a rien de pire que de devoir subir des mauvaises décisions techniques. On l’a tous vécu et c’est pas drôle.

Le même scénario arrive fréquemment et fait fuir énormément de développeurs. Ils font une recommandation technique, cette recommandation n’est pas suivie ou même écoutée. Une catastrophe arrive, et ce sont ces mêmes développeurs qui doivent payer le prix. Ça, c’est de la kryptonite. Ça rend barjo le plus zen de tes développeurs.

En laissant de la liberté technique à tes développeurs, ils vont s’épanouir dans ta boite. Et qui dit liberté technique, dit environnement technique intéressant. Et ça les développeurs en raffolent. Laisse-les dans un environnement rigide où ils font toujours la même chose sans aucune décision : tu vas finir par développer ton projet tout seul.

Avoir du sens

Jusqu’ici, on a parlé de choses spécifiques à la technique et aux développeurs de façon générale. Et oui, je le répète, les développeurs sont une espèce à part. Mais ça veut pas dire que les choses basiques ne s’appliquent pas pour eux aussi.

Sans un projet intéressant, avec un but qui fait du sens, tu les perds immédiatement tes développeurs. Si en plus ils sentent que l’organisation n’est pas capable d’ajuster les choses, ils vont mettre à jour leur Linkedin.

Pour pouvoir faire l’architecture et développer les features de ton projet, il faut que tes développeurs comprennent pourquoi ils font ça. Pour qui ? D’où ça vient ? Où ça va ?

En les sortant du contexte et des problématiques clients, plus grand-chose va faire du sens dans leur travail. Et si ça fait plus de sens ce qu’ils font, le code et la façon dont ils vont résoudre les problèmes ne va plus faire de sens non plus. Tout le monde est perdu et plus personne a envie de rester dans ta boite.

C’est fou, mais beaucoup de boîtes ont tendance à faire ça. Beaucoup de boîtes considèrent leurs développeurs comme des subalternes. Le code étant en fin de chaîne, le contexte et les besoins clients ne sont pas arrivés chez les développeurs. Et ça fait fuir beaucoup d’entre eux.

Concrètement je conseille plusieurs choses. Inclure tes développeurs dans les discussions du besoin client, leur demander leur avis très tôt et les impliquer dans les décisions clefs du projet. Si tu fais ce genre de choses, tu vas encore augmenter ta rétention.

La thune

L’écrasante majorité des développeurs adorent leur métier. Le développement c’est l’une de leurs passions. Voir même leur unique passion dévorante. Et dans ces conditions on voit beaucoup de boîtes s’engouffrer et exploiter ça à la limite de l’acceptable. Jouer à fond la carte de la passion et en profiter pour payer au lance-pierre leurs développeurs.

Mais voilà, être passionné ne fera pas fermer les yeux sur une paie misérable. En tout cas pas sur la longueur. Surtout avec un marché aussi favorable aux développeurs qui ont un peu d’expérience. Non, tes développeurs ne sont pas insensibles au salaire, bien au contraire. Oui, beaucoup d’entre eux partiront uniquement à cause de ça.

Et c’est encore plus vrai si tu veux garder d’excellents développeurs qui ont de l’expérience. Ces développeurs là se font harceler avec des offres de plus en plus importantes. Il faut investir dans ces développeurs pour garder les plus expérimentés. Ça me fait penser à la fameuse phrase de James Goldsmith: “If you pay peanuts, you’ll get monkeys”.

Mon conseil c’est au minimum de rester sur les prix du marché. Récompenser gracieusement ceux qui investissent leur temps pour que leur expertise reste chez toi. Et si possible proposer des salaires compétitifs si tu veux une rétention forte.

Un bon groupe

Enfin si tu veux vraiment garder tes développeurs, il faut commencer par créer une équipe solide. Rien n’est plus efficace pour ta boite qu’une bonne équipe de développeurs. Rien n’est plus motivant pour aller travailler. Rien n’est plus déterminant pour faire réfléchir à deux fois un développeur à son départ.

Malheureusement construire un bon groupe c’est compliqué. Y’a beaucoup de cases à cocher. C’est dense comme sujet. Tellement dense que j’en ai dédié un article entier. Tu trouveras toutes les clefs pour la construire dans ce dernier.

Il y a cependant quelque chose que je n’évoque dans cet article. L’importance pour chaque développeur d’avoir une voix dans le groupe. Ce que je veux dire par là c’est qu’il faut qu’il y ait un équilibre entre le temps d’écoute et de parole de chacun. Sans ça on entend toujours les mêmes pendant que le reste du groupe met à jour son CV.

Concrètement il faut créer un groupe sain où l’information circule normalement et où tout le monde se sent à sa place. Si tu arrives à faire ça, ça va être un déchirement pour tes développeurs de partirent. Et là t’as tout gagné.

Épilogue

Voilà on a fait le tour des points les plus importants pour garder tes développeurs. C’est vraiment en comprenant leur besoins que ta boite ne les fera plus fuir. On gardant tout cas en tête, et surtout en appliquant les conseils, je te garantis une meilleure rétention.