Wie es war, bei GitLab zu arbeiten

Erfahrungen bei GitLab

• Von Oktober 2015 bis Dezember 2021 etwa sechs Jahre bei GitLab gearbeitet.
• Entschied sich, GitLab zu verlassen, um sich ganz auf die Arbeit an Inko zu konzentrieren, hatte aber bisher nie über die Erfahrungen bei GitLab gesprochen.
• Da die NDA (Geheimhaltungsvereinbarung) abgelaufen ist, gibt es nun die Energie, auf die Zeit bei GitLab zurückzublicken.

Vor GitLab

• Arbeitete bei einem kleinen Startup mit Sitz in Amsterdam und entwickelte dort unter anderem an den XML/HTML-Parsing-Bibliotheken Rubinius und Oga.
• Wegen Geldmangel und technischer Probleme wurde die Nutzung von Rubinius nicht weiterverfolgt.
• Trat GitLab bei, nachdem gefragt wurde, ob ein Tag pro Woche für die Arbeit an Rubinius aufgewendet werden könne.

2015-2017

• Der erste Tag bei GitLab war der Tag nach dem letzten Arbeitstag bei der vorherigen Firma, womit der Wechsel zur Remote-Arbeit begann.
• GitLab war zwar ein Remote-Unternehmen, aber zugleich ein soziales Unternehmen mit vielen Treffen und Veranstaltungen.
• GitLab hatte mit Performance-Problemen, häufigen Serverausfällen und Management-Problemen zu kämpfen.
• Es fehlte an Infrastruktur für Performance-Monitoring, was Verbesserungen erschwerte.
• Es wurde versucht, Kultur und Haltung bei GitLab zu verändern, doch die Unzufriedenheit des Unternehmens mit den Fortschritten bei der Performance machte das schwierig.

2017-2018

• Die Performance verbesserte sich deutlich, und GitLab begann, das Thema ernster zu nehmen.
• Der Fokus wechselte zu einem „Datenbank-Team“, das sich auf Datenbank-Performance konzentrierte.
• Der Aufbau des Datenbank-Load-Balancers von GitLab hatte einen positiven Einfluss auf die Performance.
• Den Anforderungen von GitLab in Bezug auf Datenbank-Sharding wurde auf Basis von Daten widersprochen.

2019-2021

• Wechsel ins „Delivery“-Team mit dem Schwerpunkt, den Release-Prozess und die Tools von GitLab zu verbessern.
• Nachdem ein Commit den Main-Branch erreicht hatte, dauerte es im Durchschnitt mehrere Tage und im schlimmsten Fall bis zu drei Wochen, bis er auf GitLab.com ausgerollt wurde.
• Leitete die Arbeit zur Zusammenführung von GitLab Community Edition und GitLab Enterprise Edition in ein einziges Produkt.
• Probleme rund um das Laptop-Management und kulturelle Veränderungen führten zu sinkender Motivation und Produktivität.
• Konflikte mit einer neuen Führungskraft führten zur Aufstellung eines „Performance Improvement Plan“.

Erkenntnisse

• Skalierbarkeit muss Teil der Unternehmenskultur sein: GitLab hat sich nicht ausreichend um Skalierbarkeit gekümmert.
• Teams sollten stärker daten- und entwicklerzentriert sein: GitLab hatte eine produktmanagerzentrierte Struktur.
• Ohne Daten lässt sich kein „Minimum Viable Product“ bestimmen: GitLab machte „minimal changes“ zum Kernprinzip, entwickelte in der Praxis aber viele wenig nützliche Funktionen.
• SaaS und Self-Hosting passen nicht gut zusammen: GitLab bot sowohl Self-Hosting-Installationen als auch SaaS an, was nicht effektiv war.
• Mehr Menschen bedeuten nicht automatisch bessere Ergebnisse: GitLab stellte über Jahre viele Menschen ein, doch mehr Entwickler steigern die Produktivität nicht automatisch.
• Konflikte rund um den Einsatz von Ruby on Rails: GitLab war mit Ruby und Ruby on Rails erfolgreich, doch bei großen Projekten wird das zur Herausforderung.
• Die Zeit bis zur Code-Auslieferung ist entscheidend für den Erfolg einer Organisation: Die Verkürzung der Deployment-Zeit war bei GitLab ein wichtiges Ziel.
• Standortbasierte Gehälter sind diskriminierend: GitLab zahlte je nach Standort unterschiedlich, was als diskriminierende Praxis bewertet wird.

Meinung von GN⁺

• Die Erfahrungen bei GitLab helfen dabei, Vor- und Nachteile von Remote-Arbeit sowie die verschiedenen Probleme im Wachstumsprozess eines Startups besser zu verstehen.
• Es wird die Bedeutung von Performance-Verbesserungen und Skalierbarkeit betont sowie wie wichtig es ist, dies kulturell zu verankern.
• Auf die Probleme standortbasierter Gehälter wird hingewiesen; das ist ein wichtiges Beispiel für die Diskussion über faire Vergütung im Remote-Arbeitsumfeld.

[GN⁺]

Hacker-News-Kommentare

• Behauptung, standortbasierte Gehälter seien diskriminierend

  • Es ist nicht angemessen, Diskriminierung aufgrund von Hautfarbe oder Geschlecht mit standortbasierten Gehältern zu vergleichen. Hautfarbe und Geschlecht sind unveränderlich, der Wohnort hingegen kann geändert werden.
  • Der Wohnort hängt mit praktischen arbeitsbezogenen Fragen zusammen, etwa rechtlichen und steuerlichen Themen, mit denen das Unternehmen konfrontiert ist, Zeitzonen und Reisekosten.
  • Man kann über Diskriminierung durch standortbasierte Gehälter diskutieren, aber sie mit Diskriminierung aufgrund von Ethnie oder Geschlecht gleichzusetzen, kann die Debatte abwürgen.

• Begann als Mitarbeiter mit der Nummer 28, dann wurden nach und nach immer mehr Manager über ihm platziert

  • Ein Mitarbeiter, der anfangs direkt an den CEO berichtete, landete nach und nach unter immer mehr Managern, bekam schließlich Leistungsbeurteilungen und verließ das Unternehmen.
  • Das ist eine typische Situation, die in Großunternehmen oft vorkommt; wegen solcher Strukturen ist es dort häufig schwer, wirklich Großes zu erreichen.

• Meinung zur Nutzung privater Computer durch Mitarbeitende

  • Unabhängig von der Größe der Organisation sollte man Computer verwenden, die vom Unternehmen bereitgestellt werden.
  • Das bringt große Vorteile bei der Kontrolle des geistigen Eigentums des Unternehmens und bei der Trennung von Arbeit und Privatleben, und die Kosten sind nicht besonders hoch.

• Meinung zu schlechten Managern

  • Schlechte Manager sind ein Übel unserer Branche, aber viele Startups entstehen auch deshalb, weil Gründer in früheren Jobs schlechte Manager erlebt haben.
  • Auch der Autor selbst traf auf einen untechnischen und politischen schlechten Manager und gewann dadurch die Motivation, ein Startup zu gründen.

• Veränderung der Meinung zu standortbasierten Gehältern

  • Weg von der Ansicht, dass standortbasierte Gehälter diskriminierend seien, hin zu der Auffassung, dass es vernünftig ist, ein Gehalt zu erhalten, mit dem man in der jeweiligen Region angemessen leben kann.
  • Wer mehr Gehalt will, muss umziehen, und wenn man nicht umzieht, gibt es dafür Gründe.

• Meinung zur Nutzung von Ruby/Rails

  • Ruby wurde unter der Annahme entworfen, dass die Geschwindigkeit der Sprache nicht entscheidend ist, aber heute gibt es auf Node.js und der JVM Programmiermodelle, die durch asynchrone Verarbeitung während IO-/Netzwerk-Wartezeiten andere Aufgaben erledigen können.
  • Ruby/Rails kann in bestimmten Situationen weiterhin nützlich sein, mit der Zeit kann die Wartung jedoch schwierig werden.

• Meinung zur Gehaltspolitik in globalen Unternehmen

  • Wenn ein Entwickler in Amsterdam denselben Wert liefert wie ein Entwickler in der Bay Area, sollte er auch dasselbe Gehalt bekommen.
  • Als globales Unternehmen konkurriert man mit anderen globalen Unternehmen; deshalb ist es langfristig wichtig, Talente unabhängig vom Standort entsprechend ihrem Wert zu bezahlen.

• Frage zur Preisstrategie von GitLab

  • Frage, wie man auf der Preisseite von GitLab eine standortbasierte Preisgestaltung auswählt.

• Managementprobleme bei der Skalierung von GitLab

  • GitLab erzielt seine Einnahmen hauptsächlich mit selbst gehostetem GitLab Enterprise Edition, während GitLab.com teuer im Betrieb ist, aber wenig Umsatz bringt.
  • Es ist sinnvoll, in den Teil zu investieren, der Einnahmen generiert, aber man sollte auch berücksichtigen, dass Leistungsverbesserungen bei GitLab.com mehr Kunden anziehen und einen stärkeren Ruf aufbauen könnten.

• Meinung zum Unternehmenswachstum und zur Rolle früher Mitarbeiter

  • Nicht alle Menschen, die in einem kleinen Unternehmen stark waren, werden nach dem Wachstum des Unternehmens in gleicher Weise weiterhin erfolgreich sein.
  • Es ist Aufgabe der Führung, Mitarbeitende, die in der Anfangsphase wichtige Rollen gespielt haben, angemessen zu belohnen und darauf zu achten, dass weder ihre persönliche Entwicklung noch das Wachstum des Unternehmens behindert wird.
  • Es kommt vor, dass frühe Mitwirkende entweder auf ein frühes Liquiditätsereignis warten oder auf große finanzielle Gewinne verzichten, weil es schwierig ist, zugleich ihren Wert und ihre psychische Gesundheit zu bewahren.
  • Um Kulturkonflikte und Fluktuation zu minimieren, braucht es deutlich längere Ausübungsfristen für Stock Options, vorrangige Besetzung überlappender Rollen für Personen, bei denen sich frühe Anzeichen von Kulturkonflikten und Wechselabsichten zeigen, sowie empathisches Coaching, das Probleme klar benennt und Ressourcen für passende Teams oder Unternehmen einschließt.