Comment garder tes développeurs informatique ?
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.
On dirait la wishlist d’un millénium, totalement égocentrique et déconnecté de la notion de marché.
Pour répondre de manière un peu cynique :
A) Lancer un défi
Cela s’appelle de la R&D : chaque entreprise devrait avoir un budget innovation/recherche, fraction du budget total. Évidemment en fonction d’un type de société, de la taille etc, le budget est plus ou moins grand. Et donc dans certaines PME, il y en a pas ou presque.
D’autre part, un défi ou challenge, nécessite d’avoir confiance et d’accepter de perdre. Pas évident pour tous.
B) L’apprentissage et la veille payée par l’employeur
Oui et non. Les employés veulent limiter au maximum leur temps de travail pour le max de « thune ». Et déconnectent souvent totalement de leurs métiers une fois la porte franchie. Le nombre de développeurs faisant de la veille et des projets perso est 1) largement minoritaire cf tous les entretiens que je réalise 2) en pente fortement décroissante avec l’âge. Tout le monde n’a pas 25 ans et un unique hamster à s’occuper en rentrant chez lui.
Le temps passé sur stackoverflow pour masquer l’incompétence du développeur est déjà du temps d’apprentissage pour moi.
C) La liberté technique
Dans quel contexte la liberté technique peut-elle et doit elle s’exprimer ?
A une époque pas si lointaine, l’informatique reposait plus sur l’algorithme et les concepts que l’utilisation de template et de framework. Combien de développeurs aujourd’hui suivent aveuglément les nouvelles tendances informatiques ? Réagissant à telle mode ou tel nouvelle resucée d un concept plus ancien.
L’informatique est devenue un spectacle, avec ses saltimbanques (les conférenciers,les instacodeurs) et autres intermittents du spectacle, qui nous présentent leurs derniers helloworld Javascript.
En arrière-plan les nègres et autres pigistes et musiciens de studio (aka l’immense majorité des devs qui ne sont pas de la première catégorie) mais qui font l’informatique de tous les jours.
Et enfin les jeunes développeurs qui associent liberté technique et cherrypicking de technologies prepubères.
Pour prendre une métaphore, un logiciel est un jardin où les jeunes développeurs sous prétexte de liberté technique vont remplir l’espace de plantes diverses, variées et exotiques sans prendre en compte les contraintes biologiques, climatiques et budgétaires.
Et enfin,la notion de longévité applicative est complètement absente de la nouvelle génération qui saute de job avant que l’application soit arrivée à maturité.
D) Faire du sens
Bonjour jeune développeur, tu viens d’arriver dans une nouvelle entreprise ou un nouveau client. Son métier c’est XYZ. Sais tu ce qu’est l’assurance ? La logistique ? Cela te barbe? Tu me réclames un BA? Comment veux tu être impliqué dans ton travail et trouver un sens à ce que tu fais ?
Enfin tu veux du thune. Tu fais partie de la classe moyenne en sortant d’école, (peu importe le patrimoine parental), si tu es compétent, tu peux faire de jolis sauts salariaux régulièrement, le chômage est bas, tu peux travailler facilement à l’étranger. Je suis, je suis.. une classe sociale privilégiée.
Je conçois que certains postes soient mal payés parceque cette niche technique soit complètement non pertinente avec le marché. Mais cela reste rare. Je conçois également que les frontaliers de fassent exploiter lors de leur première expérience abroad.
Mais le salaire est loin d’être mauvais en France, le chômage est plutôt protecteur. Et si tu n’es pas content, Barres-toi. Ou bien va faire un tour sur upwork et regarde le TJM de développeurs thaïlandais plus compétents que toi et reviens te plaindre la prochaine fois que tu pars faire du trekking en Indonésie pour voir des gens avec un coeur gros comme cela….
Cette réponse est ironique et à ne pas prendre au premier degré mais c’est évident que certains tomberont dans le panneau.
Lien plus lisible : https://sylvainleroy.com/2020/04/20/frenchonly-reponse-a-jesuisundev-comment-garder-tes-developpeureuses-informatique/
Salut,
En effet, c’est une wishlist, mais justement le marché y semble favorable alors pourquoi ne pas en profiter ? Ta description du jeune développeur sans expérience est en effet assez cynique, voir même caricaturale en fait, c’est assez insultant (peut être parceque je rentre dans certaines cases ?).
Bref, l’article semble quand même viser les développeurs passionnés, et j’ai l’impression que ces développeurs là valent de l’or pour les boites (oui, j’nous lance un peu des fleurs). Du coup, oui c’est important de refiler un challenge à ton équipe, qui va faire de la veille pour trouver la meilleurs solution et donc améliorer ses compétences, le tout en ne voyant pas le temps passer parceque les personnes auront aimé ça.
Concernant « faire du sens », personnellement je travaille pour des assurances, et je ne souhaite qu’une chose c’est partir loin des gros groupes et des entreprises du CAC40… comme tu l’as dit, je me barres, mais je suis pas stupide, j’attends la bonne offre… Et au passage, c’est pas parcequ’il y a pire ailleurs en faire une norme…
Bref, tu m’as l’air assez aigri, j’espère que tu te plais dans ton travail, car parti avec cette vision tu risques vite de finir en dépression ^^
Allez salut !
« millénium, totalement égocentrique et déconnecté de la notion de marché », « stackoverflow pour masquer l’incompétence », « leurs derniers helloworld Javascript », « technologies prepubères », « la nouvelle generation », « si tu n’es pas content, Barres-toi », « développeurs thaïlandais plus compétents que toi »… Que de mépris générationnel sous couvert d’ironie. L’exemple même de ce pourquoi les développeurs ne restent pas dans certaines entreprises.
On est fondamentalement en désaccord sur absolument tout.
Je vois beaucoup d’aigreur, de colère, un ego surdimensionné et un manque de recul effrayant sur tout.
Pour le coup je suis déçu de ta réaction de ne pas remettre en question un peu ton point de vue, même si je comprends ton ressenti car le ton du commentaire est assez agressif et dédaigneux. Je pense que t’as loupé un ou deux trucs intéressants dans son discours.
Je trouve que la métaphore du jardin est très pertinente : Quand on veut un champ de patate, le jardinier qui vient te planter des orchidées c’est pas le mec que t’as envie de recruter.
Une majorité de devs (ou du moins une bonne partie) codent des projets pas très originaux, répondant à des besoins techniques qu’on a maîtrisé depuis des années (faire pousser des patates). Mais l’attrait (ou la pression) du défi technique, de la dernière techno qu’on maîtrise pas encore, va pousser les devs à parfois compliquer artificiellement les solutions techniques souvent au détriment d’à peu près tout le monde (boîte, collègues, client, utilisateur).
Exemple basique : Qui code encore un site vitrine de 5 pages en pur html/css, sans framework front, sans générateur, sans cms, etc… Et pourtant, quoi de plus stable, basique et éprouvé ? Bon je caricature un peu bien sûr, car des fois innover ça a du bon quand même 🙂
Aujourd’hui je pense qu’un des problèmes de notre métier est que plus personne ne veut planter de patates, et tout le monde veut faire pousser ses orchidées (et demain ses renoncules ou je sais pas quoi). Donc même les producteurs de patates sont obligés de recruter des jardiniers d’orchidées, quitte à avoir un champ ingérable et moins productif.
Alors on pourrait dire que les patates c’est pour les débutants, mais c’est un gros problème pour n’importe quelle boîte de ne garder ses devs qu’un an ou deux, même si on bosse sur des technos anciennes et éprouvées. Ça me fait penser aux US qui rappellent des devs COBOL à la retraite. On recherche du sens OK, mais est-ce qu’on rate pas un peu notre « mission » sociale en dédaignant et négligeant des technos pourtant essentielles, répandues et utiles à plein de gens au quotidien ?
Au final, on mange des patates et pas des orchidées non ?
Je trouve l’article pertinent mais ton commentaire aussi.
Par contre cynisme et ironie ce n’est pas la même chose. Aussi marquer « Cette réponse est ironique et à ne pas prendre au premier degré mais c’est évident que certains tomberont dans le panneau. » après avoir marqué « Pour répondre de manière un peu cynique ».
C’est un peu ne pas assumer ses positions ?
Aucune animosité, juste que ta position n’est pas clair.
Je suis dev et je vois beaucoup de conneries autour de moi, de la part de dev ou autres et je n’ai aucun problème avec ton point de vue hormis que si tu considères qu’aller sur stackoverflow c’est montrer son incompétence technique alors forcément on ne parle pas du même métier.
« Le temps passé sur stackoverflow pour masquer l’incompétence du développeur est déjà du temps d’apprentissage pour moi. »
J’ai arréter de lire là
« faire du sens »
Avoir du sens ? (to make sense)
Oui ! Je vais corriger ça.
ça me ferait plaisir… cette faute est devenue tellement répandue que ça finira par devenir un usage courant (brrr.) « ça prend tout son sens » peut marcher aussi, quand il faut.
Je préfère : « fabriquer de la raison »
Merci ❤
Je vais ajouter un point crucial : un environnement serein et pro. Dans une des boites par lesquelles je suis passé les cadres et chefs de projets prenaient les devs pour de la merde tout en étant pas foutus de faire un cahier des charges, un planning ou reporter un bug.
Content que tu soit parti de cette boite !
Dommage que le développeur rédigeant le premier commentaire et re-publiant son analyse sur son propre blog n’autorise pas… la réponse via les commentaires sur son propre site (vous m’avez suivi ?)
Ma contribution à cet article, c’est qu’il est toujours ici (jesuisundev) implicite que le.a développeur.se est passionné.e, commit son code en raccourci clavier sous Vim, à fond dans la techno, etc
Pourquoi ne pas admettre que comme dans tous métiers, il y a des profils qui font ça pour payer le loyer et la nourriture, sans chercher plus loin (paragraphe « faire du sens ») ? Et il n’y a aucun mal à ça !
Pour la liberté technique, dans un monde idéal OK, mais… on a bien souvent affaire à des contraintes non ? Code legacy, architecture dépassée, impératifs de sécurité qui t’imposent de ne pas utiliser autre chose que l’avant-dernière version stable supportée (parce que « même la dernière stable release est encore trop attaquée)…
Bref pour moi le.a dév’ n’est pas un clone. Et donc, pour le/la garder, il faut prendre en compte sa personnalité. Bref, comme dans tout autre métier.
Je suis totallement d’accord, néanmoins gros bemol 👎, je me considère pas mauvais et plutôt passionné et j’utilise TortoiseGit pour commit/fetch/rebase/conflits/toutquoi et je trouve ça plus productif et visuel 😊.
Sinon le développeur cité autorise bien les commentaires via Disqus, tu as peut être un bloqueur de pub ou autre qui a désactivé le module.
Dans « avoir du sens », ne jamais sous-estimer l’importance de l’explication de la situation : « ok on a des soucis avec cette partie qui est merdique, parce que mais on a besoin d’améliorer ça parce que « . Perso, bricoler un truc un peu merdique sans explication/contexte, ça passe mieux que je comprends pourquoi c’est le bordel (et ça arrive, et non, ce n’est pas forcément grave) et ce qu’on veut en faire.
Ou les demandes WTF… quand on me dit « en faisant ça, tu vas simplifier la vie de telle personne/lui permettre de faire ça », c’est une phrase, mais ça aide bien à comprendre l’utilité du bouzin ^^
Dans un de mes jobs précédents, ma motivation a été totalement ruinée car les demandes WTF affluaient d’un client, mais le CP ne prenait plus le temps de me les expliquer à partir d’une période. Résultat, on partait d’une solution (mauvaise ou inutilement compliquée) imaginée par le client alors que quand on nous expliquait le problème, on le solutionnait bien mieux… car bien entendu, vu que personne ne documentait quoi que ce soit chez eux, on finissait par être ceux qui avaient les clés de comment le monstre fonctionnait.
This a good work and Intersting
J’ai lu les commentaires, et là où je rejoins un peu les autres, c’est que c’est probablement plus nuancé, surtout sur les deux premiers points.
Le défi ne conviendra pas forcément à tout le monde. Il y a des devs en fin de carrière qui préfèrent rester pépères et qui se moquent comme d’une chaussette de leur avenir professionnel (puisque c’est la retraite). Il y a aussi des devs en plein syndrome de l’imposteur qui ont besoin de reprendre confiance en zone de confort. Après, faut pas non plus leur demander de faire des trucs répétitifs où ils n’apprennent rien, mais ils peuvent parfaitement se contenter de rester sur un langage bien maîtrisé.
Sur le point 2, je serais plus nuancée aussi. Si on reprend les devs bien installés et en fin de carrière, ou des débutants un peu naïfs, la veille ils s’en moquent. Donc ça les fera pas partir de pas faire de veille au boulot. Mais en fait, c’est encore pire : ils voudront bien rester, et toi, tu voudras plus les garder ! C’est donc surtout bénéfique pour la boîte de leur laisser faire leur veille sur le temps de travail.
Pour le reste, je pense que c’est un peu plus universel, même si bien sûr les priorités vont changer d’une personne à l’autre.