- Le quotidien et la trajectoire de carrière des ingénieurs dépendent fortement du budget dont provient leur salaire parmi vente/marketing, R&D et maintenance
- L’ingénierie financée par le budget vente/marketing est proche de l’argent et ses résultats sont faciles à mesurer, mais elle peut déboucher sur une culture de stack ranking et de compétition interne
- Le budget R&D emploie le plus grand nombre d’ingénieurs sous l’organisation produit et privilégie la valeur de long terme et la création d’actifs sur un trimestre ou plus plutôt que les expérimentations de court terme
- Le budget maintenance est traité comme une cible d’optimisation des coûts ; les sysadmins, l’exploitation de systèmes anciens, une partie de la platform engineering et le travail sur les outils internes peuvent relever de cette catégorie
- Savoir à quel budget appartient son travail aide à intégrer dans ses choix de carrière les changements fréquents des postes orientés croissance, les investissements de long terme de la R&D et la faible priorité accordée à la maintenance
Trois budgets se partagent le travail d’ingénierie
- Les salaires en ingénierie logicielle proviennent en général de trois budgets
- vente/marketing
- R&D
- maintenance
- La nature du budget influence le mode de travail au quotidien des ingénieurs ainsi que l’orientation de leur carrière
- Cette distinction peut être utile pour réfléchir à sa vision de carrière ou à son positionnement
Budget vente/marketing : des résultats immédiats et mesurables
- L’ingénierie rattachée aux équipes de croissance est plus facile à quantifier en termes de résultats
- Il est relativement clair de voir quelles actions font monter les chiffres
- Cette catégorie inclut des rôles comme growth engineer, sales engineer ou devrel
- faire en sorte qu’un produit existant se vende mieux
- faire connaître ses fonctionnalités
- aider les acheteurs à adopter l’outil dans leur flux de travail
- Ce que l’entreprise attend, c’est un impact immédiat
- L’avantage, c’est qu’il est facile d’évaluer le retour sur investissement et que le travail est directement lié au chiffre d’affaires
- Comme la mesure est simple, la comparaison entre personnes l’est aussi
- un stack ranking des employés peut apparaître
- une culture de compétition interne peut se renforcer au détriment d’une culture de résolution collective des problèmes
- Le rythme de travail est généralement centré sur le court terme
- la prochaine expérimentation
- le prochain client
- la prochaine tendance marketing à suivre
- L’entreprise juge la valeur de ce budget à l’aune du multiple généré par l’argent investi, et la recherche d’optimisation peut créer un effet porte tournante
Budget R&D : des actifs qui s’accumulent avec le temps
- La recherche et développement, ou R&D, est le domaine qui emploie le plus d’ingénieurs
- il se situe généralement sous l’organisation produit
- dans les plus grandes entreprises, il peut exister de véritables équipes de recherche ou scientifiques
- Cette catégorie comprend des rôles comme product engineer, researcher ou architect
- construire ce que l’entreprise vend
- ou explorer ce que l’entreprise pourrait vendre si cela fonctionne bien
- Ce que l’entreprise attend, c’est de la croissance dans la durée
- L’environnement est relativement plus calme
- on cherche l’équilibre entre les fonctionnalités qui retiennent les utilisateurs existants et celles qui attirent de nouveaux utilisateurs
- on peut pencher vers la croissance en créant des fonctionnalités qui augmentent l’activation après l’inscription jusqu’à l’usage réel
- ou pencher vers la recherche en explorant de nouvelles lignes de produit
- Dans les entreprises qui disposent d’un véritable département de recherche, certaines personnes travaillent sur des idées qui ne seront pas transformées en produit avant plusieurs années
- La R&D est en réalité une catégorie qui regroupe deux budgets différents
- développement et recherche sont distincts
- mais ils ont en commun de se concentrer sur des résultats de long terme
- L’horizon temporel le plus court qui compte est le trimestre
- Le travail des ingénieurs est conçu pour devenir un actif et produire de la valeur pendant des années
- les expérimentations plus courtes ne sont que des étapes intermédiaires dans ce processus
- Les performances sont difficiles à mesurer, mais l’entreprise considère ce travail comme un investissement
- avec l’idée qu’un meilleur produit améliore aussi les ventes et la rétention
Budget maintenance : un coût qu’on veut réduire
- La maintenance a généralement été absorbée dans les activités de développement
- Ce que veut ce budget, c’est l’optimisation des coûts
- Les sysadmins, les personnes qui maintiennent des systèmes anciens en fonctionnement, et parfois les platform engineers relèvent de cette catégorie
- L’entreprise considère ce travail comme un coût pur et cherche à le minimiser
- Dans beaucoup d’entreprises, les rôles de maintenance sont disséminés dans le développement produit
- c’est un travail important mais peu valorisé
- qui finit par être traité seulement quand quelqu’un en souffre suffisamment
- L’entreprise présente parfois le temps accordé aux ingénieurs pour traiter les NFR, c’est-à-dire les exigences non fonctionnelles, comme un avantage exceptionnel
- par exemple quand on accorde 2 jours par sprint pour traiter des tâches pénibles
- La construction d’outils internes peut aussi relever de cette catégorie
- comme les tableaux de bord d’administration qui permettent à l’entreprise de fonctionner
- mais qui ne reçoivent jamais vraiment une priorité suffisante
Ce que la place dans le budget signale pour la carrière
- Le budget auquel appartient un poste détermine l’expérience quotidienne d’un ingénieur
- Le travail orienté croissance est mesurable et change souvent
- Le travail de recherche est plus calme mais ses résultats sont flous
- Le travail de développement est valorisé et s’accumule dans le temps
- Le travail de maintenance est traité comme quelque chose qu’on peut supprimer à tout moment
1 commentaires
Commentaires sur Hacker News
L’impact sur une carrière ne dépend pas seulement de la ligne budgétaire qui finance le salaire, mais aussi de la manière dont l’organisation valorise le développement logiciel
Si l’entreprise est une société de conseil qui vend du temps de développement, ce sont les compétences relationnelles avec les clients et la capacité à produire rapidement un logiciel convenable qui seront valorisées ; si c’est une entreprise produit qui vend des logiciels, ce sont les capacités à concevoir et à exploiter des logiciels qui seront valorisées
Si le logiciel n’est qu’un composant d’une autre activité, ou un moyen de la rendre possible, c’est la capacité à livrer dans le budget qui sera valorisée, mais il sera difficile d’être au centre de l’attention
Fait intéressant, cette distinction correspond très bien aux trois catégories évoquées par l’auteur : le conseil relève des ventes/du marketing, le produit de la R&D, et le reste de la maintenance
Quand j’étais senior engineer dans une startup logicielle, j’étais traité comme une star, avec des stock-options et la culture de bureau qu’on peut imaginer ; et quand j’étais senior consultant dans une société de conseil IT, il fallait être plus proche d’un commercial qui maîtrise bien PowerPoint
Il fallait maximiser les heures facturables, et il ne fallait surtout pas finir les projets trop vite ni avec le minimum de code
Vous pouvez sans doute deviner où je me trouve aujourd’hui
Ce n’est pas quelque chose qu’on peut acheter sous forme de produit en boîte ; en général, c’est un assemblage bricolé de plusieurs systèmes lourdement personnalisés, souvent pas du tout conçus pour fonctionner ensemble à l’origine
Chaque entreprise a sa propre façon de faire
J’aime ce travail et je suis doué pour penser le système dans son ensemble à travers plusieurs départements
Pour se frayer un chemin dans les problèmes, il faut aussi comprendre la politique interne, et c’est précisément là que réside ma valeur
Je suis un programmeur correct, mais je n’ai pas le niveau d’expertise de quelqu’un qui a fait de la programmation sa carrière
Dans les deux autres cas, on est un coût qu’il faut minimiser ou éliminer
On ne devient un actif qui génère du revenu que lorsqu’on construit le produit cœur de l’entreprise
J’ai fait cette erreur moi aussi : convoqué en réunion, on m’a demandé « où en est-on ? », avant d’ajouter presque aussitôt « ne rentrez pas dans les détails »
Travailler dans le cas n°3, c’est produire des solutions ennuyeuses et oubliables, et l’on peut en venir à construire des solutions techniquement valides mais politiquement suicidaires
Par exemple, si vous travaillez chez un fabricant de matériel, non seulement vous n’êtes pas la vedette, mais il est même difficile d’être respecté
Les effectifs logiciels sont un coût, un coût qu’on préférerait ne pas avoir à supporter
Même si vous livrez à l’heure et en dessous du budget, cela ne vous rend pas visible ; au contraire, vous disparaissez encore plus du radar
J’ai du mal à comprendre l’idée, très répandue dans la culture tech actuelle, selon laquelle la maintenance serait toujours tout en bas de la liste, verrait son budget coupé et ne recevrait jamais un budget correct
En 20 ans passés dans plusieurs entreprises, j’ai souvent entendu ça, mais je n’ai presque jamais été d’accord
Une entreprise veut certes de nouvelles fonctionnalités à mettre sur le marché, mais elle veut aussi que le service fonctionne correctement
Même lors de licenciements ou de gels des embauches, j’ai vu des organisations de type SRE mieux résister que les organisations de R&D
Cela dit, dans une entreprise, la culture a évolué vers une logique où l’on récompensait la création permanente de nouveautés sans récompenser le maintien de l’existant, ce qui a conduit à des migrations continues d’outils internes, à des abandons à répétition et à des migrations à moitié terminées
Une fois promus, les gens qui avaient construit le produit partaient vers le travail suivant de leur portfolio, et ce qui était nouveau et brillant se retrouvait vite délaissé, pendant qu’une nouvelle équipe construisait encore un remplaçant
En 6 ans, un outil interne a ainsi été remplacé quatre fois par un nouvel outil interne, et les utilisateurs se sont retrouvés dispersés sur quatre outils
On pourrait parler d’un simple échec d’exécution, mais une culture qui affirme que le business ne valorise pas la maintenance est profondément nocive et mène à l’autodestruction
Imaginons qu’à chaque fois qu’un développeur ajoute une nouvelle fonctionnalité, il consomme 1 000 dollars d’espace disque et génère 10 000 dollars de nouveaux revenus
Imaginons qu’un administrateur système achète un gros serveur de fichiers, et qu’un nouveau serveur coûte 500 000 dollars
Dans une organisation bureaucratique, l’administrateur système refacture en interne le coût de l’espace disque au développeur, et lorsque vient le moment d’acheter un nouveau serveur de fichiers, l’argent est déjà prévu
Dans une organisation bien gérée et moins bureaucratique, la direction comprend qu’une facture de 500 000 dollars permet un projet qui rapportera 5 millions de dollars, et la paie volontiers
Dans une organisation mal gérée, la direction panique parce que 500 000 dollars, c’est cher et que ce n’est lié à aucun projet précis ; l’administrateur système dit alors à la prochaine personne qui a besoin de 1 000 dollars d’espace disque de payer 500 000 dollars, et cette personne refuse
Au bout du compte, l’administrateur système rejette la demande et convainc le développeur de réduire la conservation des logs de 7 jours à 3 jours, puis la direction finit par entendre de mauvais retours sur l’administrateur système
L’environnement décrit ressemble plutôt à une réalité où le business ne valorisait pas la maintenance
Dire que « la maintenance est tout en bas » n’est pas une prescription sur ce qu’il faudrait faire, mais plutôt une description de ce qui se passe réellement
L’auteur n’est pas allé jusqu’à analyser pourquoi il en est ainsi ni pourquoi une autre approche serait meilleure pour l’entreprise, mais si l’on valorise le bon fonctionnement et la qualité, on souhaite évidemment un autre résultat
Cela dit, si très peu d’entreprises agissent ainsi, il y a probablement des raisons liées à l’alignement des intérêts
Parce qu’on ne peut pas vendre de la maintenance aux clients ; on ne peut vendre que des fonctionnalités
Et du point de vue des développeurs aussi, la maintenance est un travail qu’on préfère éviter
Il est difficile de présenter la maintenance comme un élément brillant sur un CV, et tout le monde veut voir des résultats, des projets livrés et des technologies modernes
Faire tourner le service en continu au niveau attendu par les clients est une priorité élevée pour tout le monde
Aucune entreprise ne veut réduire le SRE au point de perdre des clients à cause d’incidents
Mais le SRE se rapproche davantage des opérations d’une entreprise traditionnelle, c’est-à-dire d’une fonction inévitable pour fournir le service, et c’est différent de la maintenance qu’on essaie de repousser autant que possible
Sous cet angle, la maintenance, c’est la réduction de la dette technique, l’amélioration des outils internes, la réduction du temps d’itération des expérimentations, et ce type de travail est souvent sous-évalué par rapport à son impact produit
Le texte parle de la seconde, et dit qu’aller dans la catégorie 3 relève du suicide de carrière
Si vous n’êtes pas du genre « promotion ou sortie », cela peut valoir la peine d’envisager de passer du temps dans la catégorie 3
Bien sûr, comme le logiciel se dégrade dès qu’il est utilisé, même ceux qui pensent être dans la catégorie 2 passent en réalité probablement l’essentiel de leur temps dans la catégorie 3, avec seulement une toute petite part en catégorie 2
Malgré tout, comme les budgets ne sont alloués qu’une fois par an, ou au mieux quelques fois, être classé en catégorie 2 à ce moment-là reste une meilleure position
« Ventes/marketing » et « R&D » sont des catégories qu’on peut voir dans le rapport annuel d’une entreprise, mais la maintenance n’y apparaît pas de cette façon
Cela vaut la peine de lire les états financiers d’une entreprise
Vous y verrez le « coût des ventes » ou COGS, les « frais généraux et administratifs », ainsi que des postes de coûts ponctuels comme les fusions-acquisitions, et chaque poste obéit à des dynamiques différentes qui varient aussi selon les entreprises
Il est aussi important de comprendre la structure business du secteur dans lequel on travaille
Même dans ce fil, beaucoup jugent qu’une entreprise ne « valorise pas » l’ingénierie logicielle, mais comparer une entreprise de réseaux sociaux avec 70 % de marge brute à une entreprise automobile ou aéronautique à 15–20 % est naïf
Il est naturel qu’un secteur puisse recruter plus d’ingénieurs, mieux les payer et offrir davantage de goodies et d’avantages
Même au sein d’une même entreprise, certaines lignes de produits et certaines fonctions reçoivent des investissements de long terme, et certaines lignes de produits ont des marges plus élevées que d’autres
Selon le budget, l’argent disponible pour un produit logiciel peut énormément varier
Les ingénieurs devraient réfléchir à leur travail en regardant aussi les finances de l’entreprise
Une entreprise n’est ni une association caritative ni une église ; c’est une activité économique qui doit équilibrer cash-flow, revenus, stratégie de long terme et coûts de développement produit
Ce texte est bon, mais celui de patio11 l’explique aussi très bien avec la distinction entre centre de coûts et centre de profit
Il explique de façon convaincante pourquoi il faut être rattaché à un centre de profit, et si vous ne l’avez pas lu, il contient aussi beaucoup d’autres bonnes choses
https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pr...
La règle n°2 consiste à occuper, au sein de ce centre de profit, un rôle relié de manière durable et fiable à la rentabilité
Il n’est pas nécessaire de gagner directement de l’argent, mais il doit être clair que si j’arrête de travailler, cela a un impact direct sur l’argent
C’est un peu différent, mais j’ai trouvé le Serverless Handbook de Swizec, écrit il y a quelques années, extrêmement utile, et j’apprécie depuis longtemps sa newsletter par e-mail, réfléchie et pleine de discernement
Il est résolument du côté du « apprendre en faisant / apprendre en public » et il excelle à partager son processus d’apprentissage
Je recommande vivement de le suivre ou de s’y abonner
Historiquement, l’ingénierie logicielle faisait partie de la fonction IT, et l’IT est issue de la comptabilité
Avant que les machines ne le fassent, un « computer » était littéralement le poste de quelqu’un
Encore aujourd’hui, dans beaucoup d’entreprises, la comptabilité reste le principal moteur du logiciel et la source du budget
En réalité, il existe quatre catégories de budget
La n°1 est la R&D, qui bénéficie généralement d’un traitement fiscal particulier et de crédits d’impôt
La n°2 est le commercial/marketing, qui inclut les ingénieurs avant-vente et parfois le travail d’implémentation
La n°3 est la maintenance, c’est-à-dire les développeurs qui corrigent des bugs et effectuent du travail sur du code non R&D, généralement sans traitement fiscal particulier ni crédit d’impôt
La n°4 est l’exploitation dans les services d’hébergement, le PaaS et le SaaS, où les salaires des ingénieurs logiciels sont généralement inclus dans une certaine mesure
Il est très important de comprendre les implications fiscales selon le budget d’où vient l’argent et le type de travail effectué, et cela devient bien plus complexe à mesure qu’on grandit
Je pense que le modèle centre de profit vs centre de coût est meilleur
Dans l’idéal, chaque département est responsable à la fois du chiffre d’affaires et des coûts
Si on ne peut pas le mesurer, c’est un problème de KPI
Les KPI peuvent être définis de manière trop centrée sur les coûts et donc mal alignés, mais cela ne fait pas pour autant de ce département un centre de coût
Cela dit, j’aime bien l’ajout de la distinction R&D
Même une équipe centrée sur la maintenance devrait faire de la R&D pour réduire les coûts de maintenance, tout comme une bonne équipe commerciale fait de la R&D pour augmenter le bénéfice commercial
Ils apportent des éclairages différents et peuvent se compléter
Dans aucune des entreprises où j’ai travaillé, les salaires de l’ingénierie de croissance ne venaient du budget marketing
Il n’y avait pas non plus de « budget maintenance » distinct, tout était simplement classé en R&D/ingénierie
Les attentes peuvent être très différentes selon l’équipe ou le rôle, mais ce n’est pas une question de budget : cela dépend de la manière dont l’entreprise suit ses objectifs
Soit on gagne de l’argent maintenant, soit on crée de la valeur à long terme, soit on est en train de lentement sombrer avec un produit existant