Je ne comprends pas pourquoi on continue à économiser des bouts de chandelles dans les équipes techniques.
« La version gratuite suffit bien », « As-tu vraiment besoin de l’option 16 Go de RAM ? », « On ne peut pas se permettre de payer ça pour tout le monde, ça ferait une grosse somme »
Ok, mais quel est le coût réel ? À chaque fois j’ai privilégié les versions haut de gamme, les offres « entreprise » avec SSO, et j’ai choisi des périodes de renouvellement au plus court. Bref, je suis très au-dessus de la réalité.
Type
Annuel HT
Gestion projet
300 €
Asana, Atlassian, etc.
Code source
250 €
Github, Gitlab, etc.
Email et agenda
125 €
Google suite, Office 365, etc.
IDE
130 €
Jetbrains, etc.
Autres logiciels
100 €
divers softs (coût annuel)
Visio
230 €
Zoom, …
Laptop
750 €
2700 € TTC amorti sur 3 ans
Garantie étendue
80 €
300 € TTC amorti sur 3 ans
Accessoires
80 €
400 € TTC amorti sur 4 ans
Ecran(s)
200 €
1000 € TTC amorti sur 4 ans
Casque anti-bruit
90 €
450 € TTC amorti sur 4 ans
Chaise ergonomique
170 €
1000 € TTC amorti sur 5 ans
Bref, j’ai de l’ordre de 2 500 € HT annuels en étant très au-dessus de la réalité.
Un ingénieur en développement à 45 000 € brut coûte entre environ 65 et 70 000 euros annuels tout compris à l’entreprise. Ces frais très haut de gamme représentent quelque chose comme 3,7 % du coût total.
Ok, ce n’est pas rien, pas négligeable, mais pas mortel non plus si on met en rapport le temps épargné, le confort et le bien être associé.
Oui, on peut faire sans (heureusement), mais pas certain que ce soit plus rentable. Rien qu’en temps, ça représente 1/4 h par jour travaillé. Ce n’est pas rien, mais la fatigue, la frustration et les différents contournements nécessaire à se passer de ces frais, ça peut vite représenter ça annuellement aussi : 5 minutes de perdues à relancer zoom, 10 fois 30 secondes de perdues à attendre des build ou des suites de tests qui tournent un peu plus lentement, 100 fois 5 secondes de perdues à basculer entre les tâches et les applications fautes d’avoir un écran supplémentaire, 2 fois 5 minutes de pause parce qu’on n’est pas si bien assis, 10 minutes de perte de concentration parce qu’une conversation à côté nous a perturbé, etc.
Toutes ces petites économies coûtent un pognon de dingue.
Et si on devenait un peu plus rationnels ? Payer chaque mois des milliers d’euros des ingénieurs pour ensuite refuser de leur donner les 200 € mensuels qui leur permettent de travailler efficacement, c’est un peu crétin, non ?
Pendant que vous y êtes : Investissez aussi dans des espaces cloisonnés plutôt que de grands open space, et ajoutez-y des petites salles de réunion en assez grand nombre pour passer un coup de fil ou discuter à deux de façon impromptue. Ça coûte très cher, mais l’investissement se rembourse facilement plusieurs fois.
J’entends trop souvent des développeurs se plaindre d’être forcés de passer dans le management pour progresser en salaire.
Déjà ça ne reflète pas la réalité. On est dans un métier où le salaire peut doubler avec l’ancienneté. Je doute que ce soit vrai pour tant de métiers que ça dans le privé, pas sans changer totalement de rôle voire de métier.
L’enjeu est cependant que, effectivement, la productivité individuelle n’est pas proportionnelle avec l’ancienneté. On progresse souvent bien plus les premières années que les suivantes.
À périmètre identique, on voit plus facilement la différence entre deux développeurs avec 2 et 5 ans d’expérience qu’entre deux développeurs avec 10 et 13 ans d’expérience.
Rien d’anormal, donc, que la progression salariale le reflète.
Ce n’est pas « la France qui est en retard sur ces questions », c’est juste l’application du système de marché. Le salaire dépend de ce que vous apportez, pas de votre ancienneté.
L’avantage c’est qu’avec l’expérience, normalement, vous pouvez apporter plus que votre code. Le périmètre n’a aucune raison d’être identique avec les années.
Vous pouvez former les plus jeunes et les faire progresser. Vous pouvez communiquer avec le business, avec la communication, avec le légal, faire l’interface, comprendre les enjeux de chacun et proposer des solutions. Vous pouvez parler coût, maintenance et stratégie. Vous pouvez identifier les problèmes et les solutions, améliorer l’organisation de l’équipe. Etc.
L’idée c’est de lever la tête de son code et commencer à embrasser un périmètre plus large. Vous avez de la chance : Contrairement à beaucoup d’autres domaines, vous pouvez faire ça sans changer de métier (et sans forcément devenir manager).
Pour ma part j’utilise ces termes :
Senior : Il va guider, organiser, former, servir de mentor ou de sage. Ce n’est pas forcément le plus expert, ni même celui qui a le plus d’ancienneté, mais c’est lui qui va faire progresser tout le monde ou s’assurer qu’on ne parte pas n’importe où. Il est souvent manager mais pas forcément, par contre il y a toujours un aspect de mentor et donc donc pas très loin de l’encadrement.
Expert : C’est lui le plus pointu mais pas forcément le plus expérimenté. Parfois il est même relativement jeune par rapport aux autres. Il n’y a pas forcément besoin d’expert dans toutes les équipes donc ce n’est pas forcément un débouché facile.
Lead : Souvent avec du bagage technique significatif mais pas forcément un expert. Souvent assez expérimenté mais pas forcément le senior non plus. Souvent avec une dose d’encadrement mais pas forcément non plus. J’attends de lui qu’il dirige l’équipe, l’organise, donne l’impulsion, comprenne et appréhende les enjeux, y compris les équilibres business, planning, maintenance, etc. C’est souvent lui qui s’engage et prend les responsabilités, et qui sait parler avec tout le monde et a tendance a être suivi par tout le monde.
Les étiquettes sont forcément limitatives. Ce ne sont pas les seules façons de voir les choses mais ça permet de mettre des nom sur des rôles et des attentes.
Un développeur avec beaucoup d’ancienneté est juste un développeur avec beaucoup d’ancienneté. S’il n’agit pas comme tel, son ancienneté ne le transforme pas de fait en senior, en expert ou en lead.
Se contenter de ne se préoccuper que de son code personnel tout en ayant 5 ou 10 ans d’expérience est tout à fait respectable, mais si on ne progresse que peu le salaire en fera autant.
Ce qui précède est démultiplié par un effet de levier.
Si vous impactez plusieurs personnes, vous pouvez générer une valeur supérieure à ce que vous pourriez obtenir isolément. Améliorez les conditions de travail d’une équipe, les dix personnes concernées n’augmenteront peut-être leur productivité que 5 % chacun, mais cumulé c’est aussi pertinent qu’augmenter votre efficacité personnelle de 50 %… et bien plus facile.
Quand l’amélioration de productivité individuelle baisse, agir sur le collectif a un meilleur retour sur investissement. Dans mes rôles plus haut, c’est ce que font le senior et le lead.
L’expert, non seulement plus rare, est aussi un rôle plus difficile parce que son effet de levier est beaucoup plus complexe à obtenir (et à quantifier). Or, quand les développeurs parlent d’une progression de carrière « sans management », ils ont tendance à imaginer un expert.
Je pense que le mythe du « il faut faire manager » vient en partie de là. Un développeur avec beaucoup d’expérience qui ne perçoit pas son rôle collectif a besoin de faire une sacré différence de production individuelle par rapport aux plus jeunes pour justifier son salaire. Au bout d’un moment ça n’est plus viable et le salaire stagne. Le problème n’est pas de faire du management ou pas, mais de lever un peu la tête pour voir ce qu’on peut apporter, où et comment.
Post-scriptum : On vous intronisera parfois explicitement comme lead alors que vous ne l’étiez pas auparavant, plus rarement comme expert. Ça n’arrivera quasiment jamais comme senior. De mon expérience dire à quelqu’un « désormais tu es senior » n’a jamais fonctionné. C’est quand on l’est et qu’on agit comme tel qu’on peut ensuite s’y faire reconnaître.
J’en avais fait un après trois mois. En voici un autre au bout de deux ans et quelques.
Le fond n’a pas beaucoup changé alors je vous incite à d’abord lire le billet précédent. On y gagne en temps de trajet, en place. On change les interactions sociales et les temps de respiration. Ça joue autant sur le professionnel que sur le personnel.
Le résumé décideur après deux ans : Oui ça fonctionne. Non ce n’est pas pour autant toujours aussi idéal que certaines lectures le laissent penser. Rien d’étonnant cependant, le monde idéal n’existe pas. Après, savoir si c’est une bonne chose pour vous, ça va dépendre de vous.
Le confort local
Essentiellement j’ai changé mon bureau l’année dernière. J’ai un bureau assis-debout, essentiel pour les trop longues visio-conférences ou pour réfléchir sans clavier. J’ai eu une vraie chaise de bureau pour remplacer ma chaise de cuisine droite en bois. J’ai aussi une enceinte de bonne qualité avec de la musique derrière moi quand j’en ai besoin pour me concentrer. J’ai aussi pu brancher une configuration à trois écrans, et on y prend goût.
Enfin, le télétravail c’est la capacité à faire une sieste de 20 minutes quand c’est nécessaire, ou de prendre 1h30 sur la pause de midi quand je ne tiens pas. À une période l’année dernière, je pense que j’aurais dû me mettre en arrêt maladie longue durée si je ne l’avais pas pu. À la place je l’ai relativement bien vécu et ça a été relativement transparent pour mon employeur. Gagnant pour les deux.
Bref, je suis encore et toujours convaincu que le télétravail doit s’accompagner de confort. C’est d’ailleurs une des motivations que j’entends fréquemment sur le télétravail : Avoir un vrai bureau et pas une place de poulailler dans l’open-space. À vous d’y donner corps, et ça peut faire toute la différence.
Les entreprises qui veulent fonctionner en télétravail feraient bien de financer du matériel de façon massive (poste informatique et écran, mais aussi bureau, chaise de travail, lampe, webcam additionnelle, tableau blanc, etc.) plutôt que chercher à économiser sur ces postes budgétaires.
Peut-être que si les entreprises présentielles travaillaient sur le confort local dans leurs bureaux, les questions de télétravail se poseraient différemment.
L’isolement
L’isolement joue très fort pour moi. Si j’avais un premier ressenti au bout de trois mois, ça prend toute son ampleur avec le temps.
Je suis très introverti dans ma vie personnelle. Je sors peu pour autre chose que de l’utilitaire, et encore moins depuis que j’ai un enfant à la maison. J’apprécie quand ça arrive mais je ne sais pas maintenir correctement les liens pour le montrer, ou m’organiser pour prendre ces initiatives. Avec le télétravail, désormais mes interactions sociales de la semaine se limitent trop souvent à quelques bonjour quand j’amène mon fils à l’école.
Ne voir que ma chambre, mon bureau, les tâches ménagères et éducatives, ma femme et mon fils, ça pèse. Beaucoup. Les trajets professionnels à Paris une fois tous les deux mois sont presque une respiration. Ils me permettent de voir les collègues mais sont aussi le prétexte à revoir les amis de là bas.
Vous pouvez dire que c’est lié à mon organisation et à ma façon de vivre (*). C’est certainement vrai mais il n’en reste pas moins que, dans ce contexte, l’isolement généré est difficile à vivre. Le fait d’avoir un bureau avec des collègues en face à face, des pauses voire des jeux ou des discussions locales au détour du bureau, ça m’apportait quelque chose que je n’ai plus.
Est-ce que le confort contrebalance l’isolement ? La réponse est loin d’être tranchée pour moi — et ne concerne que moi et ma situation particulière, vous aurez votre propre réponse en fonction de votre propre contexte.
Mon idéal serait probablement un système de télétravail partiel une semaine sur deux ou plusieurs jours par semaine, avec quelques moments de rendez-vous fixes pour tout un ensemble de collègues.
Le management
Je vois beaucoup de retours faire porter la responsabilité de la réussite ou de l’échec du télétravail sur le management. J’adhère à beaucoup de ce qui s’y dit sur la confiance, l’autonomie et la responsabilisation mais je trouve la conclusion un peu facile, et ne reflétant que rarement une expérience de manager.
Le télétravail me demande de repenser mon rôle, la façon dont je le mène. Factuellement, mon boulot en tant que manager change beaucoup, mais s’il change ce n’est pas sur les questions d’autonomie et de responsabilisation (qui sont dans mes organisations cibles qu’il y ait télétravail ou pas).
Si ça change c’est qu’il est bien plus difficile de sentir des signaux quand quelqu’un commence à ne plus être à l’aise. Il est de même difficile de se rendre compte que telle ou telle remarque (de moi ou d’un autre) a été mal reçue et qu’il me faut intervenir. Il est tout autant difficile de voir si tel ou tel changement est positif ou négatif tant qu’il n’y a pas de forte douleur.
Non seulement on ne voit que le formel, l’écrit et le résultat, mais en plus on agit par ces mêmes canaux. La petite discussion à la machine à café ne prend pas forme aussi facilement : C’est soit de l’écrit soit de la visio. Les rendez-vous 1–1 sont d’autant plus essentiels avec le télétravail.
Je parle de ma position de manager mais ça fonctionne dans les deux sens : Vu que je conçois mon rôle de manager comme au service des autres, si c’est plus difficile pour moi alors ça a aussi des impacts négatifs sur l’aide que je peux apporter, et donc sur les tiers non-managers. J’imagine plus facile de perdre quelqu’un et de s’en rendre compte trop tard, et plus difficile de résoudre un désalignement (*).
Quand tout va bien c’est parfait et le télétravail ne génère aucune problématique significative. Quand quelque chose n’est pas idéal, le télétravail à temps plein complexifie l’humain, des deux côtés, et peut démultiplier les problèmes ou les difficultés (*).
Organisation d’entreprise
Je ne l’ai pas abordé mais je n’ai d’expérience que pour des équipes techniques de bon niveau et impliquées. Tel que je le vois, le télétravail n’est adapté que pour des gens dirigés à la tâche d’exécution sans aucune latitude ni aucun aléas (on peut donc simplement mesurer l’avancement) soit des gens en totale responsabilité et autonomie (individuellement ou collectivement).
Quand je parle de responsabilité et d’autonomie je le prends avec un sens très étendu. Côté organisation, l’essentiel des problèmes ressentis viennent de situations où les opérationnels n’étaient (ou ne se sentaient) pas libres de prendre les décisions qu’ils pensaient pertinentes, ou qu’ils devaient justifier leur travail après-coup (le temps passé, les décisions prises, les aléas, la qualité obtenue).
La position intermédiaire, à la fois donner des responsabilités et de la liberté mais pas toute l’autonomie pour faire les choix ou les comprendre, est une source de frustration permanente. C’est déjà vrai sur une organisation locale (ne faites pas ça) mais ça s’y rattrape en partie par la proximité. En télétravail les problèmes induits m’y semblent démultipliés (*).
Le quotidien
Ce n’est pas un vrai problème mais c’est quand même une surprise pour moi alors je le signale : Même dans une entreprise totalement en télétravail depuis sa naissance il y a une demie-douzaine d’année, on perd encore du temps significatif avec les problèmes de son et de vidéo, on oublie parfois de faire de l’écrit, etc.
De même, si on est plus au calme, il est plus fréquent que au moins un des intervenants ait des travaux chez lui, ses voisins ou dans la rue, une connexion qui tombe, un wifi taquin, un matériel en panne sans pièce de rechange, un démarcheur qui sonne à la porte, un espace de coworking trop bruyant et aucune cabine d’isolement de disponible, etc.
Bref, les petits soucis du quotidien sont tout autant là en télétravail.
Enfin, certains aiment bien l’asynchrone et l’écrit (moi le premier), mais je n’ai pas trouvé de solution efficace pour remplacer les discussions autour d’un tableau blanc. Il existe des logiciels pour ça, mais sauf à payer à chacun une tablette avec stylet, ça ne sera jamais la même chose. Les réunions d’architecture sont clairement un point où on perd très nettement en efficacité.
Encore une fois : Ça fonctionne mais rien n’est magique. Certains vous diront que c’est toujours mieux qu’une entreprise qui n’a pas assez de salle de réunion. Savoir si c’est mieux qu’une entreprise qui a des espaces adéquats, ça va être un choix plus personnel.
(*) Oui, moi aussi j’aimerais une situation idéale, où tout est parfait, où tout le monde est aligné, où la culture est parfaitement partagée, où les désaccords sont déminés, où il y a bienveillance et collaboration à chaque instant de la vie, où moi-même j’ai une hygiène de vie parfaite, pas de problème de santé ni de freins sociaux.
Les retours qui disent que le télétravail ne pose aucun problème tant que le contexte est idéal et que sinon c’est la faute des problèmes autour, j’ai l’impression d’y lire un « quand ça ne fonctionne pas c’est la faute des autres ».
En pratique tout n’est pas toujours parfait. Parfois c’est la faute de l’organisation, parfois de la culture, parfois d’un contexte non maitrisé ou d’une personne particulière. Parfois on y peut quelque chose, parfois nos leviers d’action sont plus restreints ou plus long terme. Peu importe. Ça arrive et ça doit être pris en compte. Une organisation qui ne fonctionnerait que dans un contexte idéal est une mauvaise organisation.
Du coup oui, je me permets de signaler ce qui est plus difficile même si le problème n’existerait pas dans une situation totalement idéale par ailleurs. J’ai tendance à dire qu’en tant que manager c’est même mon boulot de penser à ça et d’y travailler.
Je suis plutôt agréablement surpris des résultats du sondage mais j’ai plein de choses à dire sur les réponses qui m’ont été faites.
Je fais des réponses ici parce que ça me permet d’être plus posé et d’avoir plus d’espace que sur Twitter mais aussi parce que ces réponses vont évoluer en fonction des commentaires que vous me ferez.
Tout ceci n’est qu’un immense brouillon : J’espère bien que les discussions ici ou là bas seront assez riches pour me faire changer d’avis sur plusieurs points. Si c’est le cas, les contenus évolueront donc en conséquence.
Continuer la discussion, chercher le consensus
Je commence par mettre de côté tous les appels à discussion et à consensus. Bien évidemment que ma question ne vaut qu’après discussion éclairée et recherche d’un consensus. Parfois il y a quand même des avis divergents.
J’irais même plus loin : Il doit y avoir régulièrement des avis divergents. Quand la recherche du consensus va trop loin, on a juste des gens qui s’auto-censurent et abandonnent. C’est sain et sage de leur part parce que ça permet d’avancer mais ça reste un échec collectif.
Au final c’est celui qui a le pouvoir qui gagne. Ce peut-être le pouvoir hiérarchique, le pouvoir d’influence par le charisme, le pouvoir de nuisance de celui qui ne lâche pas son avis ou qui sera pénible si on ne lui donne pas raison, ou même le pouvoir de celui qui rendra mal à l’aise l’équipe par une position victimaire.
Le pouvoir est un très mauvais indicateur de stratégie. Pourquoi lui donner ce poids ?
Il faut espérer le consensus et le favoriser par des discussions ouvertes où chacun est à l’écoute. Il faut cependant savoir prendre une décision avant que ce consensus ne soit forcé.
L’absence de consensus n’est pas un problème, il est le signe d’une richesse. Le problème est dans l’impossibilité de dégager un choix en l’absence de consensus. Mon scénario présuppose d’ailleurs un consensus de l’équipe. C’est déjà une situation plus que confortable.
Vous avez choisi le consensus à mon petit jeu ? Considérez que vous ne l’avez pas et rejouez.
Déléguer au consultant
J’ai proposé l’option parce que je l’ai vécue dans les grands groupes. J’étais le consultant.
Pour moi c’est la pire des réponses.
On fait intervenir le consultant dans la phase d’étude. Le consultant permet d’apporter des connaissances, des compétences ou des expériences qu’on n’a pas. Il établit une grille d’analyse, pousse de l’information et propose des recommandations. Il devrait s’arrêter là.
Le consultant est le pire acteur pour prendre la décision elle-même une fois l’étude bouclée. Il n’a qu’une vue partielle du contexte, généralement peu de l’historique de la boite, une compréhension biaisé des enjeux, et des motivations propres potentiellement différentes des intérêts internes.
Au final il n’a aucune raison de prendre une meilleure décision que vous (manager et équipe) qui pourrez vous baser aussi sur son expérience et ses recommandations (et les suivre le cas échéant si c’est l’élément le plus important).
Le point majeur est surtout que le consultant n’est engagé en rien par sa recommandation. Ce n’est pas lui qui en assumera les conséquences. Pire, il peut être incité à travailler dans son intérêt (valoriser son travail, ou déclencher de nouvelles prestations) au lieu de travailler à l’intérêt du projet.
Faites intervenir des consultants, prenez en compte leurs recommandations (vraiment, surtout si vous avez embauché quelqu’un de compétent qui a le recul nécessaire, n’écartez pas trop facilement ce qu’il vous dira) mais ne leur déléguez pas la décision.
Les conséquences de l’erreur
Ça dépend, quelles sont les conséquences de l’erreur ?
Je n’avais pas anticipé cette réponse. Elle me gêne énormément et c’est peut-être la plus révélatrice de mon approche des choses.
Parler de conséquences de l’erreur part du préjugé que l’avis d’en face est une erreur, que nous on a raison (peu importe si celui qui parle est dans la position du manager ou de son équipe). Pourquoi ce préjugé ? Il y a deux avis différents. J’ai autant de chances de faire une erreur que d’avoir raison. En fait si ça se trouve aucune des deux solutions n’est une erreur, ou les deux le sont.
J’ai bien évidemment en mémoire tous les cas où je regrette de ne pas avoir imposé ma solution mais il y a un gros biais du survivant. Combien d’autres décisions se seraient révélées aussi catastrophiques si je m’imposais ? Je suis bien incapable de le savoir. En fait même là où j’ai des regrets, si ça se trouve ma solution aurait été encore pire.
Donc oui, parfois j’ai le sentiment que les autres sont dans l’erreur et qu’on va en payer les conséquences de façon très grave. Quand c’est le cas je le dis, j’explique les conséquences que j’entrevois. Ces risques sont pris en compte, parfois les autres demandent des explications. Ça fait partie des éléments sur lesquels chacun va baser sa décision mais ça n’emporte pas décision en soi.
Principe de la prise de décision : Avancer tout ce qu’on pense, donner la mesure de notre conviction. Pour autant, une fois exposée, partagée et prise en compte par tous, cette intime conviction ne doit pas inciter à imposer quoi que ce soit.
N’oublions pas que les personnes en face ont potentiellement aussi ce même sentiment de grosse erreur, mais à l’encontre de ce qu’on pense nous.
Celui qui a l’expérience
On est ici dans un dérivé du cas précédent. Invoquer l’expérience n’est ni plus ni moins un prétexte pour dire que mon intime conviction devrait l’emporter.
Si j’ai plus d’expérience je l’ai mis sur la table, j’ai expliqué et explicité ce que je pouvais, affirmé que mon intuition n’est pas forcément explicable mais se base sur plusieurs années derrière moi. Cela a déjà été pris en compte par les personne en face de moi dans leur analyse. Ce n’est pas suffisant pour m’imposer.
L’historique de l’équipe et du manager
Le manager a-t-il habitude de prendre des bonnes décisions ? L’équipe ?
Peu importe en fait, à partir du moment où cet historique est partagé, connu au moment où la décision est prise. Si l’équipe a l’habitude de se planter et le manager l’habitude d’avoir raison, alors l’équipe prendra probablement d’elle-même l’avis du manager le temps qu’elle progresse. Si ce n’est pas le cas c’est que le fondement du refus est plus fort que ce critère historique.
Comme l’expérience, l’historique n’a de poids sur « qui prend la décision » que s’il n’est pas partagé en amont au moment de chercher le consensus, ou que l’un des deux est fondamentalement incompétent au point de ne pas savoir prendre en compte cet élément dans sa prise de décision (et on parle alors d’un niveau d’incompétence assez grave).
Une fois l’historique partagé, il a fait partie des éléments source de la décision de chacun, et ne doit pas emporter la décision collective pour lui-même
Ceux qui assument les conséquences
J’ai vu cet argument employé pour étayer de choix opposés. On laisse la décision à ceux qui en assument les conséquences. Certains pensent que c’est l’équipe, d’autres que c’est le manager.
Les deux me gênent parce qu’ils présupposent que tout le monde n’est pas de la même bonne volonté et dans le même bateau. Si mes équipes souffrent c’est un problème pour moi. Si je souffre ou si je ne suis plus en capacité de les protéger ou de les aider, c’est un problème pour eux. Si la décision prise ne va pas dans l’intérêt de l’entreprise, c’est un problème pour tous.
Vouloir distinguer une personne qui serait plus responsable ou qui subirait le plus les conséquences, c’est présupposer qu’il y a intérêts divergents et ça me pose problème. C’est vrai si on parle de fondateurs, actionnaires et dirigeants — et c’est pour ça que je les ai explicitement exclu de mon petit jeu — mais c’est plus gênant si on parle de management intermédiaire.
Je ne suis pas bisounours. Je sais bien que dans beaucoup de structures il y a ces intérêts divergents, mais c’est bien un problème d’organisation ou de culture à résoudre. Que des organisations dysfonctionnelles engagent des réponses différentes pour éviter ou compenser des problèmes par ailleurs, c’est certain mais ça m’intéresse moins.
Si le manager emporte les décisions parce qu’il craint de subir les conséquences d’une erreur auprès de son N+1, il y a un problème organisationnel à résoudre bien plus important que de savoir comment sont réalisés les choix.
Dans l’idéal ou dans la réalité ?
C’est la réponse qui m’a fait le plus réfléchir. Parle-je d’un idéal ou de vécu ?
Je n’ai pas la réponse. Le fait qu’il y ait un décalage entre les deux est forcément inconfortable, mais la réalité a aussi ses contraintes.
Je me suis imposé plus que je ne l’aurais aimé par le passé. Peut-être pour compenser d’autres erreurs, peut-être parfois aussi par lâcheté parce que je savais que c’est la conception du management que la direction attendait de moi. Parfois j’ai regretté de ne pas l’avoir fait, mais penser que les conséquences aurait forcément été meilleures ne relève que de la croyance.
Le passé permet d’apprendre, mais je sais aussi que le futur me réservera d’autres cas de conscience et que je ne respecterai pas toujours mes conclusions — parfois a raison à cause d’autres dysfonctions à prendre en compte, peut-être parfois pour de mauvaises raisons. Je n’ai pas dit que c’était facile.
Oui mais alors ?
Je ne donne que ma réponse de principe. J’espère qu’elle transparait suffisamment dans ma position précédente et dans les réponses ci-dessus.
Je me base sur le supposés suivants :
1. Je travaille avec une équipe responsable, compétente, impliquée, qui cherche à bien faire, qui prendra en compte les éléments de business d’organisation et de stratégie que je poserai sur la table de la même façon que je prendrai en compte les éléments pratiques qu’ils remonteront.
J’ai plus souvent rencontré ce cas que le contraire, quoi que les légendes urbaines en disent.
Je conçois que ce ne soit pas toujours le cas, mais vous avez alors d’abord ce problème à régler. Le reste en découle.
2. Une fois que chacun a explicité ses motivations, ses expériences, ses connaissances, que les compétences respectives sont connues de tous, je n’ai pas de raison de considérer que ma synthèse est moins juste que celle des autres, mais pas meilleur non plus, sauf à me considérer fondamentalement plus intelligent que mon équipe.
Avec un tel supposé, si tout le monde a la même implication et que les éléments sources comme les raisonnements de chacun ont été explicitement partagés, autant jouer à pile ou face.
Je suis là pour faire que l’équipe tourne, autonome, responsable. Mieux : Je suis là pour qu’elle s’améliore, par l’expérience et la prise en responsabilité.
Retirer à l’équipe la capacité de prendre elle-même sa décision irait à l’encontre de cet objectif.
Certes, ça ne dit rien sur le choix pris, s’il est bon ou pas, mais ne pas leur laisser ce choix aura des conséquences sur l’autonomie, l’implication et la prise de responsabilité.
Oui. La décision doit être celle de l’équipe, pas la mienne, quelles que soient mon expérience et ma position hiérarchique.
Il y a plein de bonnes raison pour s’imposer. Parfois il faut le faire, mais en général c’est à cause de dysfonctions à compenser : Des éléments stratégiques qu’on ne peut pas partager, une organisation qui fonctionne mal et à compenser, une culture pas encore en place, des membres de l’équipe qui ne sont pas à leur place. Ça doit rester l’exception et ça doit interroger.
Manager, directeur, responsable, Pourquoi prends-tu la décision à la place de ton équipe ? Pourquoi penses-tu que ton avis doit primer ?
Non, ce n’est pas ton rôle.
Ton rôle c’est de permettre à cette équipe de travailler au mieux. C’est de les mettre en capacité, de leur donner les moyens, d’instaurer la bonne culture, d’organiser, de trancher les différents et cas problématiques quand il y en a, de pousser à l’amélioration, de t’assurer que rien n’est oublié ou mal compris, d’informer de ce qu’ils ne savent pas, de définir puis déployer un cap et une stratégie, de gérer le budget, l’administratif, d’apporter soutien personnel.
Pfiou, c’est déjà énorme et j’en oublie.
Ton rôle est immense mais non, il n’est pas de prendre des décisions à la place de ceux qui savent et qui sont au jour le jour sur le sujet. Ton rôle n’est pas tant de diriger que de donner la direction.
S’il y a besoin d’imposer c’est qu’on est dans l’échec.
Ce peut-être un échec de recrutement (les personnes ne veulent pas s’impliquer), un échec de culture (les personnes ne veulent plus s’impliquer ou le font mal), un échec d’organisation ou d’autonomie (les personnes ne peuvent pas s’impliquer), un échec de formation ou d’information (les personnes n’ont pas les connaissances ou compétences pour s’impliquer), un échec de moyens (les personnes n’ont pas le temps ou les ressources nécessaires à s’impliquer), ou encore plein d’autres choses, mais un échec.
Et ces échecs, tous ceux que j’ai listé, sont liés à votre rôle de manager, votre responsabilité.
Votre rôle est majeur, et c’est tout ça.
Il n’est pas de prendre la décision mais de permettre qu’elle soit prise, puis de l’appuyer. Si vous la prenez, c’est que vous avez échoué à votre vrai rôle.
J’en ai déjà parlé il y a deux semaines, je recrute pour des gens que je connais.
J’ai désormais deux nouvelles offres, toutes deux très tech, pour des seniors.
La première est pour une petite équipe sur Lyon, plutôt orientée back-end mais il faut avoir envie de toucher de l’infra jusqu’à la webapp en React.
La seconde est à Paris, rôle dédié front-end dans une équipe d’une dizaine et pour une boite qui ne devrait pas laisser indifférent.
L’offre de recrutement d’une équipe complète est toujours ouverte et il n’est jamais trop tard pour faire un signe mais, si ça vous intéresse, ne tardez pas.
Comme ce sera toujours le cas, je publie tous les détails, sur l’organisation interne, les locaux, le nom de la société, la fourchette de salaire. L’idée c’est de trouver la bonne personne pour le bon poste, pas de jouer à colin-maillard.
Vous recrutez et on se connait, au moins de loin ? Je peux vous proposer quelque chose de complémentaire aux offres habituelles.
La précédente grille datait de 2013. Elle tourne encore mais elle me gêne. Certains chiffres étaient estimés à la hache. Rien que la fiscalité était approchée avec un 46% non justifié.
Depuis j’ai refait mes grilles quand je me suis lancé, puis les ai améliorées suite à mon bilan l’année dernière. Je ne peux pas les partager vu la quantité d’informations personnelles mais j’ai tenté d’en extraire une version plus neutre.
Il y a trop de paramètres pour pouvoir tout résumer mais voici quelques points notables :
Le freelance ne compte pas toujours son logement mais c’est un point significatif dans le calcul. Un espace de co-working peut vite monter à 250 ou 300 € par mois. Ceux qui travaillent de chez eux occupent une pièce. Au début on pense que ça ne coûte rien mais quand on déménage on compte bien une pièce dédiée en plus pour ça, à laquelle il faut ajouter la quote-part de charges, d’électricité et de chauffage.
Le statut d’auto-entrepreneur est vite super intéressant même quand on se paye du matériel et du mobilier. Sur les autres statuts il faut facturer bien plus cher pour avoir la même chose à la fin du mois.
Rogner sur le matériel et les frais ne change pas la donne. Même 1 000 € , quand c’est amorti sur plusieurs années et donc dans les 500 jours facturés, ça n’est pas significatif. Ne mégotez pas sur votre confort.
Le pire est le « on rembourse la moitié de votre abonnement de transport ». Presque éliminatoire. Si respecter le minimum légal est vu comme un avantage propre à être mentionné, je ne suis pas certain d’avoir envie d’entendre le reste. […]
Ce billet a deux ans et je n’ai pas grand chose à y changer. C’est lui qui guide mes offres aujourd’hui, le fait de décrire le travail et le contexte plutôt qu’une liste de technos.
Le milieu a lui un peu changé. On trouve toujours ses mêmes recruteurs qui cherchent « un développeur pour un éditeur logiciel » mais qui refusent de te dire qui avant de te faire dérouler ton CV, et qui à la place se vantent d’avoir un babyfoot une mutuelle ou une sortie annuelle.
Les espaces communautaires commencent par contre à mettre des règles un peu plus strictes. Précision obligatoire du salaire, de l’entreprise, de la présence ou non de télétravail, etc.
On a aussi quelques recruteurs qui fonctionnent différemment. J’ai au moins Shirley Almosni Chiche en tête. On y voit des annonces claires avec des noms et des chiffres, sans détours, du détail sur le fonctionnement interne des équipes et sur les conditions de travail. J’aimerais bien que d’autres prennent exemple.
C’est probablement elle qui m’a décidé à mettre moi aussi en avant le nom de l’entreprise d’accueil. Je suis agacé quand les autres ne le font pas, il est normal que j’en tire moi-même les conséquences. Bref, merci.
J’ai justement une proposition en cours un peu hors des habitudes, avec un « bring your own team ». Profitez-en !
Parfois j’aide au recrutement pour des amis ou des boites que j’apprécie. Ici c’est pour rejoindre un responsable produit avec qui j’ai travaillé par le passé et que j’apprécie je cautionne.
Cette annonce ci j’y tiens aussi parce qu’elle me permet de faire ce que je n’ai pas vu ailleurs : Recruter une équipe et des gens qui se connaissent déjà.
Vous pouvez évidement venir seul·e mais profitez-en si vous avez envie de postuler ensemble avec des anciens collègues avec qui vous vous entendez bien, ou des amis avec qui vous parlez de travailler ensemble un jour depuis longtemps. C’est l’occasion.
Le second point dans la création d’une équipe c’est que c’est à vous de mettre en place les organisations et l’ADN qui vous semble pertinents. Il y a une feuille blanche et si vous savez ce que vous voulez et pourquoi, on vous écoutera. Profitez-en.
📑 : La refonte complète d’un outil de GED existant qui a des utilisateurs dans le public et dans le privé.
🗺 : Lyon sud, sur les transports en commun, mais une équipe en télétravail complet hors de Lyon est aussi envisageable.
🏢 : Une PME de 70 personnes, établie depuis des années sur son domaine.
👥 : Pour constituer une équipe de 5 à 7 avec un responsable produit (personne super avec qui j’ai déjà travaillé), une responsable UX, et potentiellement un alternant dans le futur.
🔧 : Serveur d’API en PHP – Symfony. Application cliente en Typescript – Angular. Hébergement Azure.
💶 : C’est toujours évidemment adaptable suivant qui candidate mais les fourchettes imaginées sont respectivement de 35 à 45 k€ pour un·e dev confirmé·e, environ 3 ans d’expérience, et 45 à 55 k€ pour un·e lead.
Vous m’aideriez en faisant circuler autour de vous (je valorise fortement les personnes dans mon réseau de confiance ou recommandées par quelqu’un de mon réseau de confiance).
N’hésitez pas à me contacter pour plus d’informations.
De ton point de vue, le bien être de l’équipe c’est la responsabilité du tech lead ou c’est une responsabilité partagé ?
Les deux mon capitaine. Ça peut être à la fois le rôle de quelqu’un de précis dans l’équipe ou hors de l’équipe, et la responsabilité collective de l’ensemble de l’équipe.
Le rôle c’est celui du CTO, du VP of Engineering, d’un Engineering Manager ou de l’Office Manager. Ça peut aussi être une personne désignée dans l’équipe elle-même.
Est-ce que ça peut-être le tech lead ? Pourquoi pas. J’ai tendance à réserver cette étiquette pour des rôles liés à l’exécution technique plus qu’à l’organisation et à l’humain mais chacun met bien ce qu’il veut derrière les termes.
L’astuce c’est que j’ai parlé de rôle, pas de responsabilité.
Un rôle c’est quelqu’un qui est chargé de réfléchir, de dédier du temps, de réaliser certaines actions, éventuellement d’avoir ou construire une expertise. Ça s’arrête là.
Ma vision de l’équipe c’est un groupement de personnes avec des rôles différents mais qui collaborent à un objectif.
La responsabilité, quel que soit le sujet, elle est collective.
N’importe quel membre de l’équipe est en droit et même en devoir de contribuer à n’importe quel sujet à partir du moment où il a quelque chose de pertinent à apporter.
C’est aussi vrai concernant le bien-être de l’équipe. C’est surtout vrai concernant le bien-être de l’équipe.
Je ne voudrais certainement pas travailler avec quelqu’un qui pourrait collaborer au bien-être du groupe et qui s’en abstient parce que « ce n’est pas son boulot ».
Au minimum, il lève le sujet à une réunion de synchro ou à une rétrospective et, collectivement, l’équipe considère que son temps est mieux utilisé autrement. En ce cas il y a forcément aussi une discussion de ce qui doit être fait et une autre personne s’est proposé de s’en charger.
Si ça ne fonctionne pas, quelqu’un lèvera la main à une autre réunion de synchro ou une autre rétrospective, et on en tirera les leçons. Probablement qu’on changera de personne pour s’en charger.
Dans tous les cas, même lever la main est une action. Personne ne s’en désintéresse, personne ne se désimplique, personne ne se dit que ce n’est pas sa responsabilité.
Dans une équipe il y a des rôles différents mais la responsabilité est collective.
Pour que ça fonctionne il faut que l’équipe soit autonome. Il faut qu’elle soit libre de son organisation interne, avec des moyens adaptés et un peu de temps libre pour faire ce qui lui semble nécessaire.
Si l’équipe est dépendante de tiers, qu’elle n’a pas les moyens adéquats ou qu’elle n’a aucune liberté d’action, ça ne fonctionnera pas.
Si l’équipe rejette la responsabilité du bien-être sur le tech lead, c’est probablement qu’un de ces points là n’est pas en place, ou n’a pas été explicité avec assez de clarté.
Après il y a aussi des développeurs qui explicitement souhaitent rester dans une posture d’exécution, sans prendre de responsabilités. C’est tout à fait respectable, mais ce n’est pas ce que je cherche dans mes recrutements.
