L’expérience de travailler chez GitLab

Mon expérience chez GitLab

• J’ai travaillé chez GitLab pendant environ six ans, d’octobre 2015 à décembre 2021.
• J’ai décidé de quitter GitLab pour me consacrer pleinement à Inko, mais je n’avais jamais partagé mon expérience chez GitLab.
• Mon NDA (accord de confidentialité) a expiré, et j’ai enfin eu l’énergie de revenir sur mon passage chez GitLab.

Avant GitLab

• Je travaillais dans une petite startup basée à Amsterdam, où je participais à Rubinius ainsi qu’à Oga, une bibliothèque d’analyse XML/HTML.
• Faute de financement et en raison de problèmes techniques, nous avons cessé de poursuivre l’usage de Rubinius.
• J’ai rejoint GitLab en demandant si je pouvais consacrer un jour par semaine à travailler sur Rubinius.

2015-2017

• Mon premier jour chez GitLab a eu lieu le lendemain de mon dernier jour dans mon entreprise précédente, marquant mon passage au travail à distance.
• GitLab était une entreprise en remote, mais aussi une entreprise sociable, avec de nombreuses rencontres et événements.
• GitLab traversait des difficultés : problèmes de performance, pannes fréquentes des serveurs et problèmes de gestion.
• L’infrastructure de monitoring des performances faisait défaut, ce qui rendait les améliorations difficiles.
• J’ai essayé de faire évoluer la culture et l’état d’esprit chez GitLab, mais cela a été difficile en raison de l’insatisfaction de l’entreprise face aux progrès sur les performances.

2017-2018

• Les performances se sont nettement améliorées et GitLab a commencé à prendre le sujet beaucoup plus au sérieux.
• J’ai rejoint l’« équipe base de données », centrée sur les performances de la base de données.
• J’ai construit le load balancer de base de données de GitLab, avec un impact positif sur les performances.
• Je me suis opposé, sur la base de données concrètes, au besoin de sharding avancé par GitLab.

2019-2021

• J’ai rejoint l’équipe « Delivery » pour me concentrer sur l’amélioration du processus de release et des outils de GitLab.
• En moyenne, il fallait plusieurs jours, et dans le pire des cas jusqu’à trois semaines, entre l’arrivée d’un commit sur la branche principale et son déploiement sur GitLab.com.
• J’ai piloté le travail de fusion de GitLab Community Edition et GitLab Enterprise Edition en un seul produit.
• Des problèmes liés à la gestion des ordinateurs portables et des changements culturels ont fait baisser ma motivation et ma productivité.
• Des conflits avec un nouveau manager ont conduit à la mise en place d’un « plan d’amélioration de la performance ».

Ce que j’ai appris

• La scalabilité doit faire partie de la culture d’entreprise : GitLab n’accordait pas assez d’attention à la scalabilité.
• Les équipes doivent être davantage centrées sur les données et les développeurs : GitLab avait une structure centrée sur les product managers.
• Sans données, il est impossible de définir un “produit minimum viable” : GitLab faisait du « changement fonctionnel minimal » un principe central, mais a en pratique créé beaucoup de fonctionnalités peu utiles.
• Le SaaS et l’auto-hébergement se marient mal : GitLab proposait à la fois des installations self-hosted et une offre SaaS, mais cela ne fonctionnait pas efficacement.
• Plus de personnes ne signifie pas de meilleurs résultats : GitLab a beaucoup recruté au fil des années, mais davantage de développeurs n’améliorent pas nécessairement la productivité.
• Les tensions autour de l’usage de Ruby on Rails : GitLab a réussi avec Ruby et Ruby on Rails, mais cela devient un défi sur des projets de grande taille.
• Le temps de déploiement du code est crucial pour la réussite d’une organisation : chez GitLab, réduire ce délai était un objectif important.
• Les salaires basés sur la localisation sont discriminatoires : GitLab payait différemment selon le lieu de résidence, ce qui constitue une pratique discriminatoire.

L’avis de GN⁺

• Cette expérience chez GitLab aide à comprendre les avantages et les inconvénients du travail à distance, ainsi que les divers problèmes rencontrés pendant la croissance d’une startup.
• Elle souligne l’importance de l’amélioration des performances et de la scalabilité, ainsi que la nécessité d’en faire un élément culturel durable.
• Elle met en lumière le problème des salaires basés sur la localisation, un cas important dans les discussions sur une rémunération équitable dans les environnements de travail à distance.

[GN⁺]

Discussion sur Hacker News

• L’affirmation selon laquelle les salaires basés sur la localisation sont discriminatoires

  • Comparer la discrimination fondée sur la localisation à celle fondée sur la couleur de peau ou le genre n’est pas approprié. La couleur de peau et le genre ne peuvent pas être changés, alors que le lieu de résidence peut l’être.
  • Le lieu de résidence est lié à des questions concrètes en rapport avec le travail, comme les contraintes juridiques et fiscales auxquelles l’entreprise fait face, le décalage horaire et les coûts de déplacement.
  • On peut débattre de la discrimination liée aux salaires basés sur la localisation, mais l’assimiler à la discrimination raciale ou sexiste risque de clore la discussion.

• A commencé avec le matricule employé n° 28, puis de plus en plus de managers ont été placés au-dessus

  • Un employé qui reportait directement au CEO au début s’est retrouvé progressivement sous davantage de managers, a fini par être évalué sur ses performances, puis a quitté l’entreprise.
  • C’est une situation courante dans les grandes entreprises, et ce type de structure rend souvent les grandes réussites difficiles à accomplir.

• Avis sur l’utilisation d’un ordinateur personnel par un employé

  • Quelle que soit la taille de l’organisation, il faut imposer l’usage d’un ordinateur fourni par l’entreprise.
  • Cela présente de gros avantages pour contrôler la propriété intellectuelle de l’entreprise, séparer le temps de travail de la vie personnelle, et cela ne coûte pas très cher.

• Avis sur les mauvais managers

  • Les mauvais managers sont un fléau pour notre secteur, mais beaucoup de startups existent parce que leurs fondateurs ont subi de mauvais managers dans leur emploi précédent.
  • L’auteur lui-même a trouvé la motivation de lancer une startup après avoir eu affaire à un mauvais manager, non technique et très politique.

• Évolution de l’opinion sur les salaires basés sur la localisation

  • Après avoir pensé que les salaires basés sur la localisation étaient discriminatoires, l’idée qu’il est raisonnable de recevoir une rémunération permettant de vivre correctement dans sa région paraît désormais plus convaincante.
  • Si l’on veut gagner davantage, il faut déménager, et si l’on ne déménage pas, c’est qu’il y a une raison.

• Avis sur l’utilisation de Ruby/Rails

  • Ruby a été conçu avec l’idée que la vitesse du langage n’avait pas d’importance, mais aujourd’hui Node.js et la JVM offrent un modèle de programmation asynchrone qui permet d’exécuter d’autres tâches pendant l’attente des IO/réseau.
  • Ruby/Rails peut encore être utile dans certains cas, mais la maintenance peut devenir plus difficile avec le temps.

• Avis sur la politique salariale dans une entreprise mondiale

  • Si un développeur à Amsterdam apporte la même valeur qu’un développeur dans la baie de San Francisco, il devrait recevoir le même salaire.
  • En tant qu’entreprise mondiale, on est en concurrence avec d’autres entreprises mondiales ; à long terme, il est donc important de rémunérer les talents à la hauteur de leur valeur, indépendamment de leur localisation.

• Question sur la politique tarifaire de GitLab

  • Question sur la manière de choisir une tarification basée sur la localisation sur la page des prix de GitLab.

• Problèmes de gestion concernant la scalabilité de GitLab

  • GitLab tire principalement ses revenus de GitLab Enterprise Edition auto-hébergé, tandis que GitLab.com coûte cher et rapporte peu.
  • Il est rationnel pour l’entreprise d’investir dans la partie qui génère des revenus, mais il faut aussi considérer qu’améliorer les performances de GitLab.com pourrait attirer davantage de clients et construire une réputation plus solide.

• Avis sur la croissance de l’entreprise et le rôle des premiers employés

  • Après la croissance d’une petite entreprise, il n’est pas garanti que les mêmes personnes continuent toutes à bien s’en sortir.
  • Il relève de la responsabilité du leadership de récompenser correctement les employés qui ont joué un rôle important au début, et de gérer la situation sans freiner leur développement personnel ni celui de l’entreprise.
  • Il arrive que les premiers contributeurs attendent un événement de liquidité anticipé ou renoncent à un gain financier important, parce qu’il leur est difficile de préserver à la fois leur valeur et leur santé mentale.
  • Pour limiter les conflits culturels et le turnover, il faut allonger considérablement la période d’exercice des stock-options, recruter en priorité des rôles redondants pour les personnes montrant des signes précoces de conflit culturel ou de départ, et mettre en place un coaching empathique qui identifie clairement les problèmes et inclut des ressources vers l’équipe ou l’entreprise plus adaptée.