Comment atteindre ses objectifs de rémunération avec son CEO quand on est "tech"

Mis à jour : avr. 12

Si vous êtes développeurs, vous trouverez ici une grille de lecture "business" qui vous aidera, je l'espère, à profiter au maximum de votre talent. Cette grille provient des problématiques de CEOs de start-up que j'ai observées.


Objectif : Débloquer les situations à votre profit


A l'heure des Talent.io et des Malt, certains CEO affirment que votre vie professionnelle est devenue facile. Bien au contraire, jamais votre métier n'a été aussi compétitif, vos carrières éventuellement aussi courtes et votre rémunération potentiellement aussi importante.

Trop souvent vous n'obtenez pas ce que vous voulez, que cela soit en terme de liberté ou de rémunération, alors que votre interlocuteur aurait été prêt à vous le donner si vous aviez su le demander dans son mode de pensée.


C'est une histoire de protocole de communication avec système de validation. C'est assez, vous allez le voir, de débloquer les situations à votre profit. Ce sont ces "clés" que ce post cherche à vous apporter.

Quelle légitimité pour vous parler ? Pour que vous puissiez juger qui je suis, j'ai fait de la programmation chez INRIA mais après des études d'économie. J'ai débuté ma carrière en salle des marché, en trading. J'ai programmé un petit automate de trading. J'ai fait de l'objet asynchrone, et, lorsque cela ne marchait pas, je perdais de l'argent. Je comprends certains enjeux de la programmation. J'ai aussi lancé une start-up qui a eu jusqu'à 10 développeurs.

Quelles sources de motivation ?

J'ai identifié trois axes qui intéressaient les développeurs avec qui j'ai échangé :


  1. la maîtrise d'une techno

  2. la liberté de disposer de son temps, de définir ses tâches et de trouver du "sens"

  3. et bien évidemment, l'argent.

En terme d'argent, il y a là aussi deux axes (N'hésitez pas à poser vos questions en commentaires, j'y répondrai) :


  1. le salaire et le variable (le rendement de votre travail)

  2. les parts en dur au capital et les stocks options à la française, les BSPCE


Vous menez donc votre carrière en cherchant à maximiser l'un des ces axes en fonction d'où vous en êtes.


Les risques du métier : au-delà de l'obsolescence, l'épuisement mental


Le métier de développeur exerce particulièrement la force mentale. Un terrassier a le dos cassé en fin de carrière. Vous, développeur, plus qu'un trader ou un marketeur, vous exposez votre force mentale au quotidien.


Si vous gérez bien cet aspect, alors vous obtiendrez facilement ce que vous voulez.


Préserver sa force mentale


Lorsque l'on est développeur, il n'est pas possible de se cacher. Votre travail est jugé en permanence et en temps réel :


  • Un développeur front-end plus qu'un développeur back-end.

  • Un développeur en phase de production plus qu'un développeur en mode projet.


Soit cela marche, soit cela ne marche pas. C'est assez binaire. Et lorsque cela marche, soit c'est beau, soit cela ne l'est pas.


Votre vie professionnelle n'est qu'une succession de problèmes à solutionner.


Lorsque vous avez des responsabilités de production, vous évoluez souvent dans un environnement d'urgence et parfois aussi conflictuel.


Il y a aussi le poids moral lorsque vous avez la responsabilité d'une production dont dépend la vie de vos clients (Boeing 737 max), ou à un degré moindre, leur argent (Robinhood), etc.


Le monde impitoyable de ...


N'importe qui peut juger le résultat de votre travail et pratiquement personne n'a conscience de ce qu'il implique en terme d'engagement, de créativité et de persévérance (opiniâtreté). Et lorsque cela marche et que c'est beau, tout le monde trouve cela normal.


Et parmi vos pairs, l'évaluation de votre travail n'est jamais complaisante. Reprendre le code de quelqu'un revient à entrer dans son esprit. Chaque personne a sa manière de penser la résolution d'un problème.


  • Quelque soit le problème, celui qui "review" votre code aurait probablement fait différemment.

  • Quelques soient les "progamming guidelines" de votre équipe, votre "style" sera toujours personnel.

Et tout cela entraîne l'éternel débat sur ce qu'est (et qui est) un bon développeur ...


La différence entre le stress et l'incertitude

Le stress est une sensation que l'on ressent lorsque notre "to do list", définie consciemment est jugée irréaliste par notre inconscient. Le stress est un problème simple à résoudre. Il suffit de formuler ce que l'on a à faire (notre "to do list") puis d'éliminer des tâches. Lorsqu'il devient impossible de dormir la nuit, c'est une indication claire qu'il faut revoir ses objectifs ou ré-allouer ses ressources. Il suffit d'expliquer à la personne responsable de la définition des objectifs ou de l'allocation des ressources pourquoi, avec des explications rationnelles et factuelles, l'objectif ne sera pas atteint.


L'incertitude décrit un état dans lequel personne n'est capable d'avoir un avis expert sur la conséquence d'une action. Or, l'incertitude est l'état le plus fréquent pour une entreprise et encore plus dans le cadre d'une start-up. Malgré l'incertitude, il faut savoir prendre des décisions. La confiance dans une équipe dirigeante consiste à se dire qu'en moyenne elle prendra les bonnes décisions. Mais aussi que dans le pire des cas, l'entreprise ne sera pas contrainte à un licenciement massif ou à la liquidation.


C'est pourquoi, il faut rejoindre les équipes et les aventures qui savent réduire l'incertitude :


  1. les incertitudes scientifiques, lorsque la solution scientifique n'est même pas encore connue

  2. les incertitudes liées à la conception technologique (architecture, charge, bugs, etc.)

  3. Les incertitudes liées à la capacité à payer les charges, en particulier les salaires. (difficile de se concentrer sur un challenge technique et/ou scientifique lorsque l'on ne croit pas dans la capacité de la start-up à payer le salaire qui permet de payer la crèche ou le loyer)

Il est souvent raisonnable de ne pas accepter de rejoindre une aventure qui subit plus d'une source d'incertitude. En revanche, ne nous trompons pas, sans aucune incertitude, pas de grande aventure entrepreneuriale non plus.

Bien montrer que l'on sait que le développement est une condition nécessaire à la création de valeur mais pas une condition suffisante

Sans un bon marketing, aucune entreprise ne peut prospérer. Aucune. Peu importe la qualité de la technologie développée. Je sais que vous le savez. Ce que je veux vous dire c'est que ce qui compte c'est que vos collègues et vos associés sachent que vous le savez. N'hésitez jamais à les réassurer sur le fait que le savez.


Une technologie réussit à condition qu'à :


  1. long terme, le positionnement soit le bon

  2. court terme, le go-to-market soit intelligent et bon marché


Le génie en marketing s'évalue à la capacité de positionner le produit de manière à ce qu'"even a turkey could fly" (même un dindon pourrait voler).


Votre rapport de force face à un CEO


Dans une entreprise, un CEO ne peut raisonnablement s'appuyer que sur 10% de son staff. Il doit organiser le risque opérationnel pour que 90% de son staff puisse partir à un moment ou un autre. En société de type SaaS (Software as a service), il n'est pas rare de constater un turn over de 40% à 70% par an des équipes de développement.


Lorsque l'on apporte de la sérénité à son CEO, celui-ci est prêt à augmenter le salaire, le bonus et les BSPCE.


Conclusion : la réassurance est la clé de votre succès


Développeur star -> maximiser sa maîtrise

  1. Lorsque vous commencez votre carrière, vous êtes proches d'un sportif professionnel ou d'un instrumentiste en début de carrière. Votre seul objectif est de développer une maîtrise exceptionnelle d'une techno.

  2. Pour cela, vous devez vous concentrer sur une techno et avoir le temps d'explorer les derniers développements et d'exercer votre dextérité. Vous devez convaincre le développeur senior qui vous encadre que vous êtes capable de vous laisser "guider" pour progresser.

  3. Dans ce cas, il aura confiance en votre capacité à progresser et vous laissera apprendre par vous-même. Votre objectif est de gagner la confiance de votre développeur senior pour avoir la liberté d'effectuer de la veille par vous-même. Vous pouvez facilement obtenir une demi-journée par semaine, y compris en période de sprint, si vous avez prouvé que "vous teniez sur vos deux jambes".

Développeur senior -> maximiser son salaire

  1. Vous devez prouver que vous savez acquérir la maîtrise d'une techno sans vous disperser et que vous êtes "on top of things".

  2. Vous devez prouver que vous avez suffisamment d'intelligence émotionnelle pour transmettre votre savoir et votre méthodologie. Vous êtes capable de former des développeurs junior. Vous savez démontrer à votre management qu'il n'y aura pas de risque opérationnel en cas de départ de votre part, parce que vous savez former.

  3. Pour cette sécurité, les start-ups sont prêtes à améliorer votre pouvoir d'achat. Vous pouvez demander un salaire supérieur à celui du marché, et vous obtiendrez facilement ces augmentations.


Lead développeur -> avoir un bon salaire et ses premiers BSPCE

  1. Le lead développeur est un développeur senior, donc anciennement "star", qui est capable d'avoir la responsabilité d'un produit. Il est donc capable de transmettre un savoir technologique comme le développeur senior

  2. En plus, il est capable de prendre la responsabilité de l'agencement de tâches permettant de "Get Things Done". Cela veut dire notamment que le lead développeur est prêt à perdre son "edge" techno pour assurer le succès d'un projet. Plus vous avancez dans votre carrière, plus il est difficile de garder le contact avec l'excellence dans la maîtrise techno.

  3. En contrepartie, vous obtiendrez des BSPCE si vous les demandez. Et surtout, lorsque vous changez de poste ou que vous quittez une entreprise, prenez 1 ou 2 jours par semaines pour vous remettre à niveau sur les dernières avancées techno.


CTO -> maximiser ses parts dans l'entreprise et cash-out

  1. Un CTO est un lead développeur qui est capable de comprendre et de participer à un board stratégique. En plus des enjeux entourant le produit, le CTO est capable de s'approprier les problématiques de l'entreprise à 360° : techno, produit, positionnement et financement.

  2. Encore plus que le lead développeur, le CTO est le garant du "Get Things Done" à tous les niveaux techno de l'entreprise. Un bon CEO s'assure d'avoir une stratégie, un produit et de l'argent. Le CTO, quant à lui, est là pour prendre la responsabilité du fonctionnement du produit et intervient en soutien pour aider le CEO, notamment lors des levées de fonds. Il participe aussi à améliorer l'adéquation du produit avec le marché.

  3. Le CTO doit être prêt à assurer les tâches les moins gratifiantes du développement. Un CEO doit être prêt à passer le balais et la serpillère au besoin pour économiser de la trésorerie. Un CTO doit être prêt à se sacrifier pour que cela marche. Il n'en perd pas pour autant la responsabilité de l'architecture globale. Celle-ci doit assurer l'avantage compétitif de la plateforme technologique.

  4. Parce que c'est un partenaire clé, le CTO obtiendra des parts de l'entreprise en "dur" (lorsqu'il arrive suffisamment tôt dans l'aventure), complétées bien sûr par des BCPCE et un salaire compensant l'intensité de la responsabilité.

PS : Ce qu'il faut savoir sur les différents types de CTO


La fonction de CTO est dans une phase de folle évolution :


  1. Le CTO "absolu". C'est le CTO tel qu'on l'entend traditionnellement. Associé, expert, impliqué à 120%, qui "get-things-done" et qui "make-things-work". Il challenge le CEO, il est écouté du board. C'est la seule solution envisageable pour les grandes aventures

  2. Le CTO "externe". C'est un format qui se développe sur les projets très cadrés, dont les spécifications sont rédigées, précises et parfaitement maîtrisées dès le lancement des développements.

  3. Le CTO "consultant". C'est un CTO non développeur mais maîtrisant les enjeux d'architecture. C'est aussi un expert en spécification.



PS2 : Comment choisir la start-up qui nous convient ?


On ne peut travailler extrêmement durement que lorsque l'on croit que l'on participe à améliorer le monde. La vision de la start-up est l'objectif que l'on se donne en commun. La technologie comme fin n'est pas acceptable. Enrichir dans 5 ans les fondateurs et les fonds d'investissement n'améliore pas non plus suffisamment le monde.


Lorsque vous entrez en profondeur dans des sujets techniques, vous êtes micro-focalisés. Il est alors très difficile, voire impossible, de challenger les orientations "produit" ou stratégiques de la start-up. Une perte de confiance dans la capacité :


  1. du CEO à exécuter la stratégie,

  2. du CTO à concevoir l'architecture,

  3. de votre lead développeur à allouer correctement votre temps


peut raisonnablement justifier d'un départ. En cas d'erreur de jugement, votre entreprise être liquidée (donc pas de bonus, salaires difficiles, pas de valeur pour vos BSPCE, etc.)


Il y a aussi les deux bonnes pratiques qui peuvent rendre la vie du développeur bien plus facile :

  1. la maquette (graphisme)

  2. la spécification (expertise métier / MOA : Maîtrise d'OuvrAge)



C'est pour cela que San Fransisco et la Silicon Valley est si particulière


San Francisco est la ville interface entre le monde du développement et le reste du monde. C'est pour cela que les VC y sont les apôtres du "think big", et des levées record. Il faut le cash pour réduire l'incertitude et assurer la pérennité des projets malgré les "turn over" massifs et aléatoires.

Vous pouvez aussi nous contacter au : 
06 43 76 31 35