Les développeurs, éternels insatisfaits ou éternels incompris

“J’arrives pas à retenir mes développeurs ! rien ne les motive ! j’ai tout essayé…”. Cette phrase devenue emblématique dénote de l’ampleur de la frustration éprouvée par nos startuppers face à la complexité inouïe que représente la rétention des développeurs.

Cet énigme constitue, sans l’ombre d’un doute, l’une des préoccupations majeures des CEOs de nos startups, au vu des conséquences dévastatrices de l’instabilité de l’équipe technique surtout en early stage.

Cela dit, je crois que ce problème structurel n’avait jamais été abordé à sa racine et qu’une ébauche de solution devrait commencer par une meilleure compréhension de la frustration des développeurs.

Pour ce faire, je me suis entretenu avec des amis développeurs s’adossant principalement sur la théorie de la dissonance cognitive pour comprendre et analyser leur malaise.

En gros selon cette théorie, lorsque les circonstances amènent une personne à agir contre ses croyances / idées (cognitions), cette personne éprouvera un état de tension inconfortable appelé dissonance, qui tendra à être réduit par : un changement de cognition, un changement de comportement ou même un ajout de cognition supplémentaire.

Pour simplifier les choses, prenant l’exemple d’un développeur qui aspire à faire partie de l’équipe d’une future unicorne tout en travaillant pour une SSII. Le concerné tendra à réduire cette dissonance par :

• Un changement de cognition : Il se dit qu’après tout il a une bonne situation et qu’il est inopportun de la troquer contre la précarité du travail pour une startup.
• Un changement de comportement : Il entame les démarches nécessaires pour intégrer une startup ou pour créer la sienne.
• Un ajout de cognition : Il se dit qu’il continuera à travailler pour la SSII car cela lui permettrait de faire des économies et de préparer sereinement le lancement de sa propre startup.

Commençons alors par l’identification des cognitions des développeurs pour mieux appréhender la dissonance à l’origine de leur frustration.

1. Les expectations :

En intégrant une startup en early stage, le développeur choisit de troquer la stabilité et le confort d’une grande boîte IT ou d’une SSII de moyenne taille pour les promesses suivantes :

• Vivre une sucess story : le choix du développeur est aiguillé principalement par le potentiel de la startup, notamment, son produit et la qualité de ses fondateurs. Et là on voit clairement que l’approche est assez atypique par rapport aux critères classiques de choix d’un emploi (stabilité, salaire, avantages…). On peut même dire, que cela se rapproche plutôt d’une démarche d’investisseur.
• Entamer une aventure entrepreneuriale : dans la continuité du premier point, un développeur ne choisit pas un employeur mais plutôt son futur propre projet. Ceci devrait se traduire naturellement par un intéressement dans le capital de la startup (même à terme), une implication à minima dans le management et surtout une visibilité sur tous les challenges à relever.
• Relever des défis technologiques : un développeur désirant intégrer une startup en early stage, est généralement un développeur qui éprouve une forte appétence pour les défis, du coup, il s’attend à être confronté continuellement à des challenges techniques (nouvelles technologies, nouvelles problématiques…).
• Travailler dans un environnement de startup : ceci pourrait paraître anodin mais la startup est aussi le fantasme du cadre de travail jeune, cool, casual… Conscient que le rythme de travail est assez soutenu, le développeur estime que pour tenir le coup, il est primordial d’évoluer dans l’espace de travail de ses rêves.

Les principales cognitions étant identifiées, passons maintenant à la réalité du travail dans beaucoup de startups tunisiennes.

2. La réalité :

Pour des raisons tant endogènes qu’exogènes, la réalité du travail dans la majorité des startups tunisiennes en early stage se présente comme suit :

• Le service au détriment du produit : beaucoup de startups, surtout celles qui n’ont pas eu la chance de décrocher un financement ou celle qui ont pris du retard sur le plan business, font de l’outsourcing pour arrondir leurs fins de mois. Ceci constitue une double peine pour le développeur qui se retrouve, non seulement, affecté sur des projets de sous-traitance peu intéressants à son goût mais avec un salaire/situation de startup, par dessus le marché.
• Le manque d’implication : ce manque d’implication se manifeste aussi bien au niveau du capital qu’au niveau du management. Soyons honnête, très peu de startups prévoient des plans d’intéressement en equity au profit de leurs développeurs. Pour ce qui est du management, on est généralement plus dans une configuration top down que dans un style participatif et surtout transparent d’une startup. Culturellement, ce style de management est assimilé à une faiblesse managériale…
• La désillusion des challenges technologiques : la majorité de nos startups démarrent avec une roadmap produit très ambitieuse, mais la réalité du terrain (marché, finances…) les somme à revoir leur copie et reléguer au second plan les gros chantiers technologiques pour proposer un MVP répondant à l’essentiel du besoin du client. Ce twist est perçu généralement par les développeurs comme un désenchantement.
• Un environnement de travail austère : pointage, bureaux en rosace, caméras de surveillance, ambiance morose, séparation entre l’espace de travail des managers et celui du reste de l’équipe… Tout cela n’a rien à voir avec un cadre de travail de startup, du moins celui dont rêve les développeurs ayant fait le choix de travailler pour ce type de sociétés.

On voit très bien que la réalité et les expectations sont aux antipodes, ce qui engendre une situation de dissonance et par conséquent une frustration du développeur. Cette dissonance cognitive manifeste est réduite dans la majorité des cas par le développeur lui même via :

• Un changement de comportement : démission dans l’objectif de lancer sa propre startup ou d’intégrer une nouvelle qui répondrait peut-être à ses attentes.
• Un changement de cognition : Entamer les démarches pour intégrer une grande SSII, idéalement française, switchant ainsi vers une logique de plan de carrière.
• Un ajout de cognition : Demander une augmentation salariale (généralement exorbitante) pour pouvoir continuer et mieux accepter sa situation.

3. Les bonnes pratiques de rétention pour une startup :

La racine du problème étant identifiée, le challenge pour nos startuppers est maintenant de réduire cette situation de dissonance criante avant que cela ne soit fait par leurs développeurs. Ceci passerait par des bonnes pratiques de rétention notamment :

• Ne pas perdre le focus produit : idéalement, il faudrait se doter des moyens financiers nécessaires pour ne pas perdre ce focus. Cela dit, je sais parfaitement qu’il n’est pas toujours évident de lever des fonds et que la startup se trouve parfois dans l’obligation de faire du service pour subsister. Le cas échéant, il faudrait relayer les développeurs sur le service et prévoir des bonus spécifique pour cette activité (pas mal de startups tunisiennes avaient réussi à implémenter cette démarche).
• Entretenir le sex-appeal de la startup : il ne faut jamais oublier qu’au même titre qu’un investisseur, le développeur avait choisi la startup principalement pour son potentiel, du coup, il est extrêmement important pour lui de voir le progress. En d’autres termes, il est primordial d’avoir en permanence une excellente communication interne et externe (PR) sur les achievements afin d'entretenir l’estime du développeur pour la startup.
• Prévoir des incentive plans en equity : Là on parle de la clef de voûte de la politique de rétention. Faut pas se leurrer, il est quasiment impossible de retenir les bons développeurs sans plan d’intéressement en capital. Bien évidemment, pour préserver les droits de toutes les parties, cet intéressement devrait être indexé sur des KPIs.
• Opter pour un style de management participatif et transparent : soyons clair, il ne s’agit nullement de perdre le leadership ou le contrôle de la situation, mais plutôt de solliciter l’équipe pour feedback ou encore pour prendre part aux grandes décisions. L’expérience a montré que cela pourrait s’avérer plus que healthy tant sur le plan managérial que sur le plan rétention.
• Sortir les développeurs de leur délire technologique : il est primordial d’aider les développeurs à s’affranchir de leur autisme technologique, les pousser petit à petit à s'inscrire dans une approche lean plutôt fonctionnelle/business et avoir ainsi de l’estime pour un produit répondant, tout simplement, au besoin du client.
• Accorder une attention particulière à l’environnement de travail : pour les startups qui en ont les moyens, ceci ne présente pas de complexité particulière, c’est juste une question de volonté. Par contre, cela pourrait s’avérer moins simple pour les petits poucets, même si les plus ingénieux d’entre eux avaient réussi à résoudre cette problématique en s’implantant dans des coworking spaces, bénéficiant ainsi d’un cadre de travail de startup à petit prix.

Pour conclure sur note factuelle, je me suis penché sur le cas de la startup ayant le plus faible turnover du portefeuille que je gère :

• Premier constat : la startup applique, bel et bien, la totalité des bonnes pratiques de rétention sus-citées.
• Deuxième constat : la startup offre un niveau de salaires en dessous de la moyenne du portefeuille…