Meine Erfahrung bei GitLab
(yorickpeterse.com)- Die sechs Jahre von meinem Einstieg bei GitLab im Oktober 2015 als 28. Mitarbeiter bis Dezember 2021 waren eine Mischung aus vollständiger Remote-Arbeit, dem Chaos eines schnell wachsenden Startups, Problemen mit Performance, Deployments und Unternehmenskultur sowie Burnout
- In der Anfangszeit waren Performance-Einbrüche und häufige Ausfälle die größten Beschwerden der Nutzer über GitLab, doch es fehlte an Infrastruktur für Performance-Monitoring, und zugleich mussten Tools gebaut werden, die auch Self-Hosting-Kunden nutzen konnten
- 2017–2018 entwickelte das Database-Team einen Datenbank-Load-Balancer; im selben Zeitraum kamen das Löschen der Produktionsdatenbank und fehlerhafte Backups zusammen, was zu etwa 6 Stunden Datenverlust und rund 24 Stunden Wiederherstellung führte
- Von 2019 bis 2021 vereinheitlichte das Delivery-Team die getrennte Repository-Struktur von Community Edition und Enterprise Edition und verkürzte den Ablauf vom Commit bis zum Deployment auf GitLab.com von im schlimmsten Fall 3 Wochen auf einige Stunden bis etwa einen Tag
- Die Lehren aus GitLab: Skalierbarkeit muss Teil der Kultur sein, „minimal viable“-Entscheidungen ohne Daten sind riskant, der gleichzeitige Betrieb von SaaS und Self-Hosting erzeugt Anforderungskonflikte, und schnelle Deployments sowie rollenbasierte Vergütung sind wichtig
Vor dem Einstieg bei GitLab und die frühe Rolle
- Vor GitLab arbeitete ich bei einem kleinen Startup in Amsterdam, das wegen Geldmangels in einer so schwierigen Lage war, dass es einen Teil seines Büros untervermietete
- In meiner Freizeit arbeitete ich an Rubinius und wollte es so stabil machen, dass es in Produktionsumgebungen einsetzbar wäre; deshalb begann ich, nach einer Stelle zu suchen, bei der ich daran arbeiten konnte
- Bei einem Ruby-Meetup und einem Rails-Girls-Workshop lernte ich Sytse kennen, entwickelte Interesse an GitLab, schickte im Sommer 2015 eine E-Mail und stieg im Oktober 2015 als Mitarbeiter Nr. 28 ein
- Meine Aufgabe war die Performance-Verbesserung von GitLab, und ich durfte 20 % meiner Arbeitszeit für Rubinius verwenden
- In sechs Jahren durchlief ich mehrere Teams, hatte viel Autonomie, berichtete an 10 verschiedene Manager und erlebte mit, wie GitLab von gut 30 Personen auf rund 2000 Menschen wuchs
2015–2017: Remote-Arbeit und Aufbau von Performance-Tools
- Direkt am Tag nach meinem letzten Arbeitstag bei der vorherigen Firma begann ich bei GitLab und wechselte von fünf Tagen pro Woche im Büro zu fünf Tagen pro Woche Remote-Arbeit
- GitLab war damals bereits ein vollständig remote arbeitendes Unternehmen, hatte aber eine stark soziale Kultur; in Amsterdam, Austin und anderswo fanden häufig Firmenmeetings und Events statt
- In dieser Phase erlebte GitLab seine erste Wachstumsphase: Rund 100 neue Mitarbeitende kamen hinzu, die Unternehmensgröße wuchs von gut 30 auf etwa 130, schrumpfte dann auf rund 80 und wuchs anschließend wieder
- Gleichzeitig traten die typischen Probleme eines schnell wachsenden Startups auf: gravierende Performance-Probleme, Ausfälle fast jede Woche und unerfahrenes Management
- „GitLab is slow“ war die größte Beschwerde der Nutzer
- Auch auf Hacker News tauchten häufig Beschwerden über die Langsamkeit von GitLab auf
- Performance-Verbesserungen waren wegen fehlender Tools noch schwieriger
- Das damalige Performance-Monitoring bestand nur aus einem New-Relic-Trial-Account, und von insgesamt 15–20 Servern konnten nur 1–2 überwacht werden
- Die eingehenden Daten repräsentierten die Gesamtsituation nicht zuverlässig
- GitLab verlangte, dass die verwendeten Tools auch Self-Hosting-Kunden zur Verfügung stehen und möglichst Open Source sind
- Um die Performance zu verbessern, mussten zunächst Tools gebaut werden; daraus entstand später das offizielle Feature GitLab Performance Monitoring
- Auch Sherlock, ein schwergewichtiger Profiler für Entwicklungsumgebungen, wurde in dieser Zeit aufgebaut
- GitLab erkannte, dass Performance-Probleme nicht von einer einzelnen Person gelöst werden konnten, gründete ein Performance-Team und stellte einen dedizierten Manager sowie ein kleines Recruiting-Budget bereit
- Ich versuchte, Rubinius mit GitLab zum Laufen zu bringen, hatte damit aber keinen Erfolg; wegen der Wartungsrichtung und zusätzlicher Kontroversen in der Ruby-Community stellte ich die Arbeit schließlich ein
2017–2018: Database-Team, Load-Balancer und Produktionsdatenbank-Vorfall
- Nach dem Chaos der ersten anderthalb Jahre hatte sich die Performance deutlich verbessert, und GitLab begann, Performance ernster zu nehmen
- Das Performance-Team verlagerte seinen Fokus von allgemeiner Performance-Verbesserung auf Datenbank-Performance und wurde zum Database-Team
- Auch das Recruiting-Budget wurde erhöht, und ein Infrastructure Engineer wurde zugeteilt, um unter anderem bei neuen Datenbank-Setups zu helfen
- Das zentrale Feature, das in dieser Zeit gebaut wurde, war der GitLab database load balancer
- Der zugehörige Vortrag wurde als Scaling the GitLab database veröffentlicht
- Entwickler schreiben DB-Queries wie gewohnt, und der Load-Balancer routet sie an Primary oder Replica
- Nach Schreibvorgängen wurde Sticking eingesetzt, sodass der Primary verwendet wird, bis die Änderungen auf allen Replicas angekommen sind
- Das hatte einen großen positiven Performance-Effekt, und dass die Einführung transparent gelang, ist etwas, worauf ich besonders stolz bin
- Am 31. Januar 2017 kam es zu einem Vorfall, bei dem die Produktionsdatenbank von GitLab.com versehentlich gelöscht wurde
- Der Vorfall wurde als GitLab.com database incident veröffentlicht
- Das Backup-System hatte lange Zeit nicht richtig funktioniert, und auch das System, das über Backup-Fehler informieren sollte, funktionierte nicht
- Die Wiederherstellung war möglich, weil etwa 6 Stunden zuvor Produktionsdaten in die Staging-Umgebung kopiert worden waren
- Die Wiederherstellung dauerte rund 24 Stunden, und es kam zu etwa 6 Stunden Datenverlust
- Im selben Zeitraum wollte GitLab weiterhin Datenbank-Sharding, doch nach damaliger Datenlage und Einschätzung der Engineers passte das nicht zur Problemlösung
- GitLab hatte etwa 10:1 mehr Lese- als Schreibanfragen
- Auch die gespeicherte Datenmenge war nicht groß genug, um die Komplexität von Sharding zu rechtfertigen
- Ein Consultant sagte sinngemäß ebenfalls, dass Sharding selbst für Kunden mit deutlich größerer Last und deutlich größeren Repositories überdimensioniert sei
2019–2021: Delivery-Team und Verbesserung der Deployment-Zeiten
- Um 2018–2019 war ich von Performance- und Reliability-Arbeit erschöpft und wechselte in das neu gegründete Delivery-Team
- Ziel des Delivery-Teams war es, den Release-Prozess und die Tools von GitLab zu verbessern; der damalige Zustand war chaotisch
- Nachdem ein Commit im main-Branch gelandet war, dauerte es im Durchschnitt mehrere Tage, bis er auf GitLab.com deployed war; im schlimmsten Fall dauerte es bis zu 3 Wochen
- Der größte Engpass war, dass GitLab Community Edition und GitLab Enterprise Edition als getrennte Git-Repositories existierten
- Regelmäßig waren manuelle Merges und Conflict Resolution nötig
- Um dieses Problem zu lösen, wurde über mehrere Monate daran gearbeitet, die beiden Projekte zusammenzuführen
- Die Arbeit daran wurde als Merging CE and EE codebases veröffentlicht
- Das Delivery-Team verbesserte den Release-Prozess erheblich und brachte ihn auf ein Niveau, auf dem Änderungen innerhalb weniger Stunden deployed werden konnten
- Die Reduktion von schlimmstenfalls 3 Wochen auf schlimmstenfalls etwa einen Tag war eine große Verbesserung
- Dennoch war auch diese Geschwindigkeit aus idealer Sicht noch nicht ausreichend schnell
Veränderungen der Unternehmenskultur und der Weg zum Austritt
- 2018 war das letzte Jahr des mitarbeiterorientierten GitLab Summit; ab 2019 wandelte sich das Format stärker in Richtung einer traditionellen Konferenz für Kunden
- Da Treffen mit mehr als 2000 Personen sehr teuer sind, war diese Änderung finanziell nachvollziehbar, aber im Hinblick auf die soziale Erfahrung weniger unterhaltsam als zuvor
- Auch das Laptop-Management war ein wiederkehrender Konfliktpunkt
- GitLab verlangte oder erwog von Mitarbeitenden, die mit einem Firmen-Mac oder privater Hardware auf GitLab-Ressourcen zugriffen, die Installation von Remote-Management-Software
- Die vorgeschlagenen Tools hatten einen invasiven Charakter und konnten etwa zur Aufzeichnung von Nutzeraktivitäten verwendet werden; Garantien gegen Missbrauch wirkten unzureichend
- Viel Feedback von Mitarbeitenden wurde häufig ignoriert, bis zentrale Mitarbeitende Druck machten
- GitLab entschied sich schließlich für eine Laptop-Management-Lösung auf Basis von SentinelOne
- Veränderungen in der Unternehmenskultur und persönliche Veränderungen kamen zusammen, wodurch Motivation und Produktivität sanken und Stress zunahm
- Nachdem ein gut bewerteter Manager in eine andere Rolle wechselte und ein neuer Manager das Team übernahm, kam es zu Konflikten, und ein Performance Enablement Plan wurde angewendet
- Ein PEP ist eine Vorstufe zu einem PIP und soll Beziehung und Arbeit wieder in geordnete Bahnen bringen
- Ursprünglich wurde mir gesagt, es sei ein Prozess, in dem sich beide Seiten verbessern sollten; tatsächlich fühlte es sich aber so an, als konzentriere er sich nur auf Änderungen, die von mir verlangt wurden
- Er war ursprünglich für einen Monat vorgesehen, wurde aber um einen Monat verlängert; nach zwei Monaten wurde das Ergebnis als zufriedenstellend bewertet
- Danach hatte ich das Gefühl, dass GitLab und ich in unterschiedliche Richtungen gingen, und begann, über einen Austritt nachzudenken
- Wegen des Börsengangs von GitLab und des Zeitpunkts zur Ausübung von Stock Options wurde ein Austritt im Dezember 2021 möglich
- In den Niederlanden musste man damals bei der Ausübung von Stock Options 52 % Einkommensteuer auf die Differenz zwischen Ausübungspreis und Bewertung zahlen, unabhängig davon, ob die Anteile liquide waren
- Wegen der hohen Steuerlast war eine Ausübung vor dem Börsengang von GitLab schwierig
- Später wurde das Gesetz geändert, sodass man wählen kann, ob die Steuer zum Zeitpunkt der Ausübung oder zum Zeitpunkt der Liquidisierung der Aktien fällig wird
- Im Dezember 2021 verließ ich GitLab und begann, mich Vollzeit auf Inko zu konzentrieren
Lehren aus der GitLab-Erfahrung
-
Skalierbarkeit muss Unternehmenskultur sein
- GitLab priorisierte Skalierbarkeit nicht ausreichend, und meiner Ansicht nach bestand dieses Problem auch zum Zeitpunkt meines Austritts weiter
- GitLabs wichtigste Einnahmen kamen nicht von GitLab.com, sondern von Kunden, die GitLab Enterprise Edition selbst hosteten
- GitLab.com kostete deutlich mehr Geld, als es einbrachte, weshalb der Fokus auf dem Self-Hosting-Markt lag
- Viele Performance-Probleme von GitLab.com ließen sich nicht direkt auf zahlreiche Self-Hosting-Kunden übertragen
- Viele Entwickler wollten die Performance verbessern, erhielten dafür aber nicht die nötige Zeit und die nötigen Ressourcen
-
Teams sollten daten- und entwicklerzentriert arbeiten
- GitLab war stark Product-Manager-getrieben, und welche Features implementiert wurden, entschieden vor allem Product Manager und Directors
- Einige Entscheidungen waren sinnvoll, andere wirkten, als müsse man etwas bauen, weil es auf Hacker News als gute Idee erschien
- Hätte man früher eine einfachere Hierarchie eingeführt, Team Leads mehr Befugnisse gegeben und sie stärker mit Nutzern interagieren lassen, hätten möglicherweise bessere Ergebnisse erzielt werden können
- Die Rolle des Product Managers sollte meiner Ansicht nach darin bestehen, technisch zum Aufbau des Produkts beizutragen und zugleich die Verbindung zwischen Team und Nutzern herzustellen
-
Ohne Daten ist „minimal viable“ schwer zu beurteilen
- Eines der Kernprinzipien von GitLab war, immer mit einer minimal viable change zu beginnen
- Das Problem war, dass jede Person „minimal“ anders definierte
- Manche Teams betrachteten Performance oder gute Usability als Anforderungen an „viable“, andere Teams hielten sie nicht für wichtig
- Dadurch entstanden Features, die für Nutzer nicht nützlich waren
- Eine nicht angeforderte und schließlich eingestellte serverless platform
- Unterstützung für Kubernetes-Cluster-Management, die drei Wochen lang nicht funktionierte, ohne dass es jemand bemerkte
- Eine auf CI aufgebaute ChatOps-Lösung statt bestehender Lösungen
- Ein Requirements-Management-Feature, mit dem man nur erstellen und ansehen, aber nicht bearbeiten oder löschen konnte
- GitLab führte vierteljährlich eine user survey durch, und einige Teams hatten Zugriff auf Nutzungsdaten; meiner Erinnerung nach und nach Gesprächen mit ehemaligen Kollegen wurden diese Daten jedoch eher sporadisch genutzt, statt Kernbestandteil des Team-Workflows zu sein
-
SaaS und Self-Hosting sind schwer gemeinsam zu betreiben
- GitLab bietet sowohl Self-Hosting-Installationen als auch SaaS an
- Die beiden Modelle unterscheiden sich in Erlösstruktur, Anforderungen und der Art, wie Updates eingespielt werden
- SaaS erfordert schnelle Deployments sowie die Verarbeitung großer Datenmengen und Workloads in zentraler Infrastruktur
- Die meisten Self-Hosting-Instanzen sind deutlich kleiner als SaaS, weshalb sich SaaS-Probleme und -Lösungen nicht direkt übertragen lassen
- Infolgedessen mussten in vielen Teilen der Plattform zwei Codepfade berücksichtigt werden: einer für SaaS und einer für Self-Hosting
- Konzentriert man sich entweder auf SaaS oder auf Self-Hosting, kann die gesamte Aufmerksamkeit auf eine Erfahrung gerichtet werden, die zu dieser Betriebsweise passt
-
Mehr Menschen garantieren keine besseren Ergebnisse
- GitLab stellte über die Jahre viele Menschen ein und beschäftigt heute mehr als 2000 Personen
- Die Zahl der Entwickler kenne ich nicht genau, aber beim Durchsehen der Team-Seite schätze ich sie auf mindestens mehrere Hundert
- Mehr Menschen zu einem Projekt hinzuzufügen verbessert Produktivität und Ergebnisse nicht zwangsläufig; das hängt auch mit „The Mythical Man-Month“ zusammen
- Ohne Daten würde ich sagen, dass für die meisten Unternehmen höchstens 20 Entwickler ausreichen, manche 20–50 benötigen und nur sehr wenige 50–100 brauchen
- Wenn die Zahl der Entwickler über 100 steigt, sollte man sich fragen, ob der Produktumfang zu groß wird
- Diese Einschätzung bezieht sich auf Softwareentwickler; Bereiche mit vergleichsweise anderen Synchronisationskosten wie custom hardware, Sales oder Support sehe ich als Ausnahmen
-
Die Bewertung von Ruby on Rails ist zwiespältig
- GitLab wurde mit Ruby und Ruby on Rails gebaut, und diese Kombination trug wesentlich zum Erfolg von GitLab bei
- Gleichzeitig macht Rails es leicht, Code mit schlechter Performance zu schreiben, wenn das Projekt größer wird und viele Beitragende mit unterschiedlicher Erfahrung hinzukommen
- Ein typisches Problem ist das N+1 query problem
- Rails’ ActiveRecord hat Funktionen, um dieses Problem zu lösen, sie sind jedoch opt-in
- Wenn Entwickler das vergessen, entstehen Queries pro Row und damit Performance-Probleme
- Viele der Performance-Probleme, die in den ersten Jahren von GitLab gelöst wurden, waren N+1-Queries
- Auch Ruby selbst war eine großartige Sprache, doch der starke Einsatz von Meta-Programming wirkt sich in großen Projekten schwierig aus
- Go, Rust und Node.js können effizienter sein als Ruby, aber meiner Ansicht nach gibt es kein Framework, das so leistungsfähig ist wie Ruby on Rails
- Python und Django könnten ebenfalls eine Option sein, dürften aber zu einem gewissen Grad ähnliche Probleme wie Ruby und Rails mitbringen
-
Deployment-Zeit ist wichtig für den Erfolg einer Organisation
- Code sollte innerhalb von höchstens einer Stunde deployed werden können, nachdem er in den Ziel-Branch oder Tag gepusht wurde
- GitLab brauchte etwa 4 Jahre, um sich diesem Ziel anzunähern, und hatte weiterhin einen Weg vor sich
- Schnelle Deployments helfen bei der Reaktion auf Ausfälle
- Wenn Deployments mehrere Stunden dauern, können Hot-Patches nötig werden
- Schnelle Deployments beeinflussen auch die Motivation
- Es macht zufrieden, Änderungen, die man gebaut hat, tatsächlich sehen und nutzen zu können
- Wenn eine Änderung, an der man wochenlang gearbeitet hat, erst weitere zwei Wochen später deployed wird, senkt das die Motivation
- Organisationen sollten sehr aggressiv daran arbeiten, Deployment-Zeiten und die Zeit zu reduzieren, die die Test-Suite im Deployment-Prozess benötigt
- Entscheidend ist nicht, dass alle Tests und Deployments unter einer bestimmten Zeit liegen müssen, sondern dass man Deployments im Rahmen der Geschäftsanforderungen so schnell wie möglich priorisiert
-
Standortbasierte Gehälter sind diskriminierend
- GitLab-Gehälter hängen von mehreren Variablen ab, eine davon war der Standort
- Bei Unternehmen mit physischen Büros, die in bestimmten Regionen einstellen müssen, kann eine standortbasierte Anpassung nachvollziehbar sein; bei einem vollständig remote arbeitenden Unternehmen gibt es jedoch keinen legitimen Grund, zwei Personen mit gleicher Erfahrung und Verantwortung nur wegen ihres Wohnorts unterschiedlich zu bezahlen
- Zum Zeitpunkt meines Austritts lag mein Gehalt in den Niederlanden bei etwa 120.000 € brutto pro Jahr bzw. etwa 8.500 € pro Monat
- Hätte ich in der Bay Area gelebt, hätte ich meiner Einschätzung nach mindestens das Doppelte, vielleicht sogar mehr erhalten
- Die Lösung besteht darin, Vergütung nicht am Standort des Bewerbers, sondern an den Anforderungen der Rolle auszurichten
- 0xide Computer Company wird als Unternehmen erwähnt, das nicht standortbasiert, sondern denselben Betrag zahlt
- Der Beitrag Compensation as a Reflection of Values behandelt dieses Thema
Fazit
- Meine Zeit bei GitLab war eine Mischung aus sehr positiven und negativen Erfahrungen
- Ich bin sehr stolz auf die Erfolge in mehreren Teams und auf die Menschen, mit denen ich zusammengearbeitet habe
- Dass das letzte Jahr die gesamte Erfahrung bitterer gemacht hat, bleibt bedauerlich
- Ich bereue es nicht, bei GitLab gearbeitet zu haben, und wenn ich es noch einmal tun könnte, würde ich auf Basis des heutigen Rückblicks manches etwas anders machen
- Trotz seiner Schwächen halte ich GitLab für deutlich besser als viele andere Unternehmen und empfehle es weiterhin als Arbeitgeber
1 Kommentare
Meinungen auf Hacker News
Der Vergleich, dass es ein großes Problem wäre, wenn ein Unternehmen das Gehalt wegen Hautfarbe oder Geschlecht senkt, es aber angeblich in Ordnung ist, es wegen des Wohnorts zu senken, muss genauer betrachtet werden.
Hautfarbe/Geschlecht und Wohnort unterscheiden sich darin, ob sie veränderbar sind und ob sie tatsächlich mit der Arbeit zusammenhängen.
Der Wohnort ist arbeitsrelevant, weil das Unternehmen Dinge wie die Gründung lokaler Niederlassungen, das Verständnis von Rechts- und Steuersystemen, Zeitzonen und Reisekosten stemmen muss.
Ob regionale Vergütung richtig ist, kann man diskutieren; vergleicht man sie aber mit Rassismus oder Sexismus, stellt man GitLab praktisch als rassistische oder sexistische Organisation dar, und die Debatte ist schnell beendet.
Hätte die Person in der Bay Area gelebt, hätte sie mehr als doppelt so viel bekommen; sie sagt, das sei unfair, nur weil der Wohnort anders ist, aber hier scheint es keinen Anlass zu geben, Opferpunkte zu sammeln.
Das wirkt eher wie ein Argument von jemandem, der Wirtschaft nicht besonders gut versteht.
Das Gehalt, das ich jetzt in den USA bekomme, ist ungefähr doppelt so hoch wie damals im Vereinigten Königreich, aber der Lebensstandard ist ähnlich; manches ist schlechter, manches besser.
Auch beim Autor des Originalbeitrags wäre der Lebensstandard womöglich sogar gesunken, wenn er in die Bay Area gezogen wäre, trotz höherer Vergütung.
Man muss nicht nur Einkommen berücksichtigen, sondern auch soziale Absicherung, Steuern und Kultur; ich könnte mir sogar vorstellen, für ein bequemeres Leben nach Europa zurückzugehen und dafür eine deutliche Gehaltskürzung hinzunehmen.
GitLabs Motivation für regionale Vergütung steht unter https://handbook.gitlab.com/handbook/total-rewards/compensat... und wirkt ziemlich plausibel.
Wenn man bis auf die Philippinen oder in die Ukraine Gehälter wie in der Bay Area zahlt, geraten Menschen in goldene Handschellen: Sie können selbst dann nicht gehen, wenn sie gehen müssten, und brennen möglicherweise aus.
Zahlt man umgekehrt ein weltweit mittleres Gehalt, kann man in Kalifornien oder London keine Leute einstellen.
Auch die Behauptung, Produktmanager seien unnötig und ein Produkt dürfe nicht mehr als 100 Entwickler haben, ist umstritten.
Der Autor des Originalbeitrags wirkt wie ein hervorragender Engineer mit großer Autonomie, der in einem vergleichsweise kleinen Startup deutlich glücklicher und erfolgreicher gewesen wäre.
Wenn er nicht auf Änderungen der Steuerregeln hätte warten müssen, wäre er vielleicht früher gegangen und hätte eine positive Erfahrungsgeschichte geschrieben.
Wenn man neben Aktien in Amsterdam auch noch 300.000 $ Vergütung bekommt, ist es ebenfalls bedenkenswert, wie schwer es dann gewesen wäre, das Unternehmen zu verlassen.
Würde man weltweit gleiche Vergütung erzwingen, würden Unternehmen wegen Offsites, gleicher Zeitzonen und Kommunikationsvorteilen wahrscheinlich einfach nur lokal einstellen wollen.
Das gilt besonders in einer Wirtschaftslage, in der es auch in Regionen mit hohen Lebenshaltungskosten viele Bewerber gibt.
Das kann sich künftig ändern, aber es ist nützlich, die realistische Anreizstruktur zu betrachten.
Unternehmen, die in anderen Ländern einstellen, gehen auch Risiken ein; zugleich hinterlässt das vor Ort Wissen und die Keime künftiger Unternehmen.
Büroarbeit gibt Beschäftigten durch die Lebenshaltungskosten der jeweiligen Region Verhandlungsmacht beim Gehalt; in vollständig remote arbeitenden Unternehmen und Kulturen kann das Unternehmen dagegen überall einstellen und Gehälter zahlen, die eher dem kleinsten gemeinsamen Nenner entsprechen.
Remote Work lässt alle wie unabhängige Auftragnehmer mit Talenten aus der ganzen Welt konkurrieren, während Büroarbeit einen vor allem mit Menschen aus derselben Region konkurrieren lässt.
Es wirkt wie die Geschichte eines 28. Mitarbeiters, der zunächst direkt an den CEO berichtete, bis nach und nach Manager über ihm eingeschoben wurden und einer davon ihn auf einen PEP setzte, woraufhin er das Signal verstand und ging.
Das ist ein ziemlich typischer Ablauf und könnte einer der Gründe sein, warum Menschen in großen Unternehmen nur schwer große Dinge zustande bringen.
Selbst wenn man innerhalb des Unternehmens ein Projekt startet und erfolgreich macht, schiebt das Unternehmen Leute darüber ein, und am Ende ist man im eigenen Projekt der n-te Mitarbeiter und bekommt zu hören, die Leistung reiche nicht aus.
Jemand, der nur die interessanten und spannenden Dinge machen will, am Ende starke Meinungen zu Unwichtigem hat, und als mit dem CEO gut vernetzter Individual Contributor zum Albtraum für Manager wird, wenn er deren Entscheidungen nicht akzeptiert.
Ohne Entscheidungsverantwortung zu tragen, kann so jemand hin und her springen und Probleme verursachen.
Endpoint-Security und die Nutzung privater Geräte sind ein Hinweis darauf.
Eine so permissive Kultur skaliert wegen Compliance- und Entwicklerproduktivitätskosten nicht.
Es ist schwer, alte Entwickler von ihrer bevorzugten Linux-Distribution loszueisen, aber für die Arbeit sollte man Arbeitsrechner nutzen und Updates vom Unternehmen verwalten lassen.
Bei der Datenbank-Backup-Geschichte ist es genauso: Wenn man das Datenbankteam ist, sind Backups Aufgabe Nummer eins.
„Es gab keine Backups“ kann man nicht ins Passiv abschieben; es wirkt eher so, als sei das Interesse an Debatten über Sharding-Architektur größer gewesen als daran, die Site im Alltag am Laufen zu halten.
Auch die Schlussfolgerung, GitLab habe nicht genug in die Performance seines gehosteten Produkts investiert, kann schlicht bedeuten: Wenn dieses Produkt ein großes Verlustgeschäft ist, ist es naheliegend, nicht noch mehr Ressourcen hineinzustecken.
Man muss nicht mit spannender Engineering-Arbeit überzeugen, sondern mit einer echten geschäftlichen Begründung, warum diese Arbeit wichtiger ist und Geld verdient.
Ein Manager hat mit mir ein erfolgreiches Projekt gestartet, aber das Management zog gierig Politik und soziale Dilemmata hinein, schob Managementebenen dazwischen und versucht, mich und diesen Manager zu ersetzen.
Ich habe gelernt, warum man sich nicht aufrichtig um die Arbeit kümmern sollte, und deshalb fühlt es sich so an, als werde das Projekt kaputtgehen und aufgelöst werden.
Hier schwingt die Annahme mit, dass dieser Mitarbeiter tatsächlich ein High Performer war, keinen Manager brauchte und keinen PEP verdient hatte, aber das ist keine sichere Annahme.
Ich habe in frühen Startups frühe Mitarbeiter gesehen, die nicht mit dem Tempo wachsen konnten oder wollten, mit dem Unternehmen und Rolle größer wurden.
Wegen Respekts für frühere Beiträge, schwer ersetzbarem historischem Wissen und Beziehungen zu Gründern und frühen Mitarbeitern, die später Führungskräfte wurden, lässt man solche Leute häufig bleiben.
Aber dass jemand ein früher Mitarbeiter war und an wichtigen frühen Projekten beteiligt war, bedeutet nicht, dass er weiterhin der Beste oder Geeignete für diese Aufgabe ist.
Man kann hervorragend darin sein, Dinge mit Workarounds, cron-Jobs und manuellen Eingriffen am Laufen zu halten, aber in einem großen Unternehmen kann eine solche Betriebsweise völlig unpassend sein.
Wenn man sich nicht anpasst oder unzufrieden damit ist, nach den Regeln eines großen Unternehmens arbeiten zu müssen, schadet man mehr, als man hilft.
In jedem frühen Unternehmen gibt es frühe Mitarbeiter, die nicht mitwachsen, aber das ist weder das einzige noch unbedingt das häufigste Ergebnis.
Bei GitLab gibt es auch viele langjährige Mitarbeiter, aber in einem frustrierten Blogpost hört man sie nicht; deshalb sollte man Selection Bias berücksichtigen.
Ich nutze GitLab seit Langem, und das Produkt entwickelt sich weiter, daher stimme ich der Behauptung nicht zu, es sei ein stagnierendes Produkt.
Erst als man drei Jahre später sah, dass Releases weiterhin scheiterten, wurde es zum Problem; aber das wirkte weniger wie mein Einfluss, sondern eher wie das Ergebnis davon, dass jemand bei Google nach „wie verhindert man Release-Fehlschläge“ gesucht hatte.
Ich kenne keine Lösung, und ich erlebe dasselbe gerade wieder mit einem anderen Thema.
Anfangs erledigte man einfach, was nötig war, später aber musste jeder Schritt durch eine neu eingefügte Managerstelle, angeblich um sicherzustellen, dass man nichts Falsches tut.
Das geschieht unabhängig von den frühen Ideen und Beiträgen, die das Wachstum des Unternehmens erst ermöglicht haben.
Ich frage mich, ob das auch damit zusammenhängt, dass rund um GitLab CI seit Jahren alte Issues offen sind.
Von außen wirkt es, als habe GitLab die Fähigkeit, großartige Dinge zu bauen, völlig verloren, und als wolle man jahrealte Bugs, die immer wieder auftreten, nicht beheben.
Dass Mitarbeitende ihre privaten Computer verwenden durften, ist fast schon erstaunlich
Selbst wenn eine Organisation noch so klein ist, sollte sie firmeneigene Geräte bereitstellen und verlangen, dass sämtliche Arbeit für das Unternehmen auf diesen Geräten erledigt wird
Für das Unternehmen hat das große Vorteile bei der Kontrolle des geistigen Eigentums, den Mitarbeitenden hilft es sehr dabei, Arbeitszeit und Privatzeit zu trennen, und die Kosten sind auch nicht besonders hoch
So kann man überall den gewünschten Werkzeugsatz unverändert nutzen, und die Fähigkeit, die Umgebung schnell zu löschen und neu aufzusetzen, ist auch gut zum Debuggen von Problemen der Art „auf meinem Rechner geht/geht es nicht“
Am einen Ende steht der Ansatz, sich auf das Gedächtnis zu verlassen, am anderen Ende, mit https://nixos.org/ überall vollständig reproduzierbare Builds zu erstellen
Dazwischen gibt es viele Optionen, und ich habe auch Leute gesehen, die ein Bündel von Ansible-Dateien pflegen, die mit
host: localhostalles Nötige installierenIch nutze die jeweils aktuelle Ubuntu-Version und pflege ein paar Shell-Skripte [1], die bei einer Neuinstallation 80 % dessen installieren, was ich haben will
Wer wissenschaftlich vorgehen möchte, kann etwas wie https://atuin.sh/ installieren und anhand der langfristigen Shell-Historie Statistiken darüber erstellen, welche Programme er tatsächlich häufig ausführt
[1]: https://github.com/hiAndrewQuinn/shell-bling-ubuntu
Das ist keine perfekte Lösung, aber zumindest ist ein Datenabfluss bei Firmengeräten dann entweder böswilliges Verhalten oder das Ergebnis von Inkompetenz, bei der sensible Daten über nicht genehmigte Wege verschoben wurden
Wenn das Unternehmen verklagt wird, kann auch der Inhalt privater Geräte Gegenstand aller möglichen Vorladungen werden
Ein separates Gerät zu verlangen, bringt Nutzern nicht unbedingt einen Vorteil für die Work-Life-Balance, sondern ist einfach nur unbequem
Das Verhalten, Arbeitszeit und Privatzeit zu trennen, hängt vor allem von den eigenen Gewohnheiten, Fähigkeiten und letztlich Entscheidungen ab
Früher empfand ich regionale Gehälter als Diskriminierung, aber davon bin ich inzwischen weitgehend weg
Am Ende läuft es darauf hinaus, ein SF-Gehalt zu verlangen, und Menschen in Indien verlangen dann Gehälter wie in den Niederlanden oder in SF
Das kann leicht zu einem Wettlauf nach unten führen
Die einfache Tatsache ist, dass jeder genug verdient hat, um in seiner eigenen Region gut zu leben
Wer mehr will, kann umziehen, und wer nicht umzieht, wird dafür wohl Gründe haben
Alle wollen ein SF-Gehalt und Lebenshaltungskosten wie in Indiana oder Indien, aber aus offensichtlichen Gründen ist das schwer haltbar
Wenn man eingestellt wird, bekommt man Gehälter auf US-Niveau, egal ob man in San Francisco, Poland oder Indonesia sitzt
Solche Stellen sind extrem umkämpft
Man hat im Grunde die Tür zur ganzen Welt geöffnet und gesagt: „Zeigt, was ihr könnt“, kann also auf einen viel größeren Pool von Bewerbern und Talenten schauen, darunter viele außergewöhnlich kluge und antriebsstarke Menschen aus armen Ländern
So funktionieren Angebot und Nachfrage
Wenn man mehr zu zahlen bereit ist, stellt man in der Regel Kandidaten auf höherem Niveau ein
Ich kenne ziemlich viele Leute, die aus verschiedenen US-Bundesstaaten remote arbeiten und Gehälter auf SF-Niveau beziehen
Natürlich ist das möglich
Auch SF sollte nicht zu selbstgefällig werden
Detroit war einst die Motor City und Music City sowie ein globales Zentrum für Kultur und Technologie, doch seine Kernkompetenzen wurden durch Arbeitskräfte in anderen Regionen erschüttert, die günstiger und effizienter waren
Gefordert wird gleicher Lohn für gleiche Arbeit
Wenn Teammitglieder dieselbe Arbeit machen, andere den vollen Betrag bekommen und man selbst nur einen Teil, dann ist das gravierend verkehrt
Der Beitrag zum Team hängt nicht davon ab, wo man sich gerade befindet
Auch wie viel Zeit man mit Pendeln verbringt, ändert nicht die Erwartungen an die Arbeitsergebnisse
Wenn ein Bürostandort übermäßig teuer ist, sollte das Unternehmen das Problem lösen, indem es einen günstigeren Standort sucht; Mitarbeitende haben keinen Grund, die schlechte Bürostandortwahl des Unternehmens zu subventionieren
Die 100k, die der Mitarbeiter erhält, und die Kosten für das Unternehmen sind nicht dasselbe
Je nach Land unterscheiden sich zusätzliche Steuern, Sozialversicherung und Benefits, die das Unternehmen tragen muss, und in vielen Fällen braucht es lokale Gesellschaften oder virtuelle Geschäftsstrukturen sowie Ressourcen zur Unterstützung der Einhaltung lokaler Gesetze
Ich bin selbst in einem multinationalen Unternehmen in einer globalen Rolle auf der Seite der Mitarbeitenden mit lokalem Gehaltsniveau, aber es gibt mehr zu bedenken, als es von außen scheint
Im Kern wird nicht nach Einstellungskosten, sondern nach Lebenshaltungskosten angepasst, wobei gleiche Gehälter angestrebt werden
Schlechte Manager sind ein Ärgernis der Branche
Umgekehrt entstehen viele Startups gerade deshalb, weil Gründer in früheren Jobs schlechte Manager erlebt haben
Ich muss an die Geschichte der traitorous eight und Fairchild Semiconductors denken
Auch persönlich hätte ich wohl keine Motivation gehabt, mein Startup zu gründen, wenn ich in meinem vorherigen Job keinen nichttechnischen, politischen und rachsüchtigen Manager erlebt hätte
Rückblickend denke ich sogar, dass ich mir wünschte, einem so schlechten Manager schon früher in meiner Karriere begegnet zu sein
Es wäre auch gut, leichter zu Unternehmen wechseln zu können, die meine Fähigkeiten wirklich brauchen, ohne die Belastung eines HR-Prozesses
Die These lautet, dass Rubys gesamtes Programmiermodell auf der Annahme beruhe, dass die meiste Zeit mit I/O- oder Netzwerk-Wartezeiten verbracht werde und die Geschwindigkeit der Sprache daher nicht wichtig sei.
Heute gibt es aber bei Node.js und in der JVM-Welt Modelle, die während des Wartens auf I/O oder Netzwerk andere Arbeit erledigen oder mehr Requests verarbeiten.
Ruby/Rails im Jahr 2024 zu verwenden, kann Verschwendung sein; für Enterprise-Apps mit begrenzter Nutzerzahl, wenn Entwicklungsgeschwindigkeit absolut entscheidend ist, oder für schnelle Prototypen zur Marktvalidierung kann es aber eine gute Wahl sein.
Rails ist ein hervorragendes Framework und sehr produktiv, aber Rails-Projekte, die 2–3 Jahre alt sind, sind in der Wartung immer schwierig.
Ein Rails-Projekt ist nicht schwieriger als ein Django- oder Express-Projekt.
Jede Codebasis braucht Disziplin und kontinuierliche Gartenpflege, damit kein Unkraut wächst.
Wenn Ruby und Rails Schwächen haben, dann weiterhin die Rohleistung der Sprache sowie ein höherer Speicherbedarf und -verbrauch; für Aufgaben, die niedrige Latenz oder einen kleinen Speicher-Footprint erfordern, sind sie weniger attraktiv.
Nach meiner Erfahrung schmerzt es vor allem, wenn der Traffic plötzlich stark schwankt oder es sehr viele aktive Nutzer mit WebSockets gibt; die WebSocket-Seite wird durch anycable größtenteils gelöst.
Aber nur sehr wenige Produkte erreichen solche Grenzen, und selbst wenn, lassen sie sich lösen.
Stripe, GitHub und Shopify sind prominente Beispiele dafür, dass Rails auf verschiedene Weise problemlos skaliert wurde.
Eine große treibende Kraft hinter Rails war DHHs Vorstellung von Developer Happiness, und die hängt eng mit Entwicklungsgeschwindigkeit zusammen.
Dass es in der Rails-Community Diskussionen über I/O gibt, liegt daran, dass es für den Betrieb von Webservern wichtig ist; es ist aber weder der einzige noch der hauptsächliche Fokus bei der Entscheidung für Sprache oder Framework.
Wenn das Ziel ist, die CPU-Auslastung eines Webservers zu maximieren, konnte man auch bei Rails mehrere Prozesse starten; das wird seit Langem auf ähnliche Weise genutzt wie mehrere Threads in der JVM.
Es mag weniger bequem sein, ist aber ein Modell, das seit den 90ern verwendet wird, und Web-Requests laufen normalerweise unabhängig voneinander, sodass Interprozesskommunikation oft kein großes Problem ist.
„Verschwendung“ zu verallgemeinern, ist grob.
Auch eine App in Rust zu schreiben kann je nach Situation Verschwendung sein; es hängt davon ab, wo der Druck liegt.
In der Frühphase ist es eine viel größere Sorge, nicht auszuliefern, und auch in späteren Phasen gehört Entwicklergeschwindigkeit zu den am schwersten zu skalierenden Faktoren.
Als CTO eines Unternehmens mit Rails-Backend und React-Frontend ist Entwicklungsgeschwindigkeit sehr wichtig, und die Entwicklungsgeschwindigkeit mit Rails bleibt ein großer Vorteil.
Es gibt auch Skalierungsprobleme, aber zu 99 % sind das keine Rails-Probleme, sondern Datenbank-Probleme.
Dass ein Unternehmen Ingenieure nach Standort bezahlen will, halte ich für eine weitere Form von Diskriminierung.
Man sollte nach der Fähigkeit der Mitarbeitenden bezahlen, nicht nach ihrem Standort.
Staatliche Regeln sagen, man solle nicht nach Geschlecht, Religion, sexueller Orientierung usw. diskriminieren – ist Diskriminierung beim Gehalt nach Standort fair?
Ich habe Freunde gesehen, die in derselben Rolle von Europe nach Asia gewechselt sind und weniger bezahlt bekamen, obwohl sie dieselbe Person in derselben Rolle waren und sich nur der Standort geändert hatte.
Wenn man in einen weniger umkämpften Markt zieht und es schwieriger wird, andere Jobs zu finden, steigt die Wahrscheinlichkeit, dass man auch für ein niedrigeres Gehalt zur Arbeit erscheint.
Auch wenn Remote-Arbeit so wirkt, als sei man nicht an den lokalen Markt gebunden, errichten Regierungen oft große Hürden für internationale Einstellungen, sodass manche Länder zu weniger umkämpften Märkten werden können.
Wenn jemand im selben Unternehmen dieselbe Arbeit macht, in ein anderes Land zieht und das Gehalt sinkt, dann hat er diese Kürzung fast sicher genau deshalb akzeptiert.
Meiner Meinung nach sollte ein Unternehmen danach bezahlen, in welchem Maß Mitarbeitende Komfort und Gesundheit genießen können, nicht nach irgendeinem universellen Wertmaßstab.
Ich halte einen solchen universellen Wert für unmöglich.
Das Argument, nur nach Fähigkeit zu bezahlen, zerstört unbeabsichtigt Gemeinschaften und verschärft durch Ungleichheit Gentrifizierung und den Zerfall sozialen Zusammenhalts.
Standort ist wichtig.
Sie sollen die gleiche Lebensqualität, die gleiche Art von Wohnraum, die Möglichkeit, eine Familie zu versorgen, und die Möglichkeit, Kinder auf vergleichbare Schulen zu schicken, ermöglichen.
Die Kosten dafür unterscheiden sich von Land zu Land, also unterscheidet sich auch das dafür nötige Einkommen.
Ein Unternehmen braucht bestimmte Fähigkeiten und zahlt nur so viel, wie der Markt den Wert dieser Fähigkeiten ansetzt – nicht mehr.
Je nach Standort bepreist der Markt dieselbe Fähigkeit unterschiedlich, also unterscheiden sich auch die Gehälter.
Religion ist eine etwas unklare Ausnahme, aber ob fair oder nicht: Das hier ist keine Diskriminierung.
Wenn GitLab.com immer deutlich mehr gekostet hat, als es einbrachte, und das Unternehmen sein Geld vor allem mit Kunden der self-hosted GitLab Enterprise Edition verdient hat, frage ich mich, ob es wirklich ein Fehler war, nicht genug in Skalierbarkeit zu investieren.
In erster Linie sollte ein Unternehmen in Dinge investieren, mit denen es Geld verdient, statt in Dinge, mit denen es Geld verliert.
Man kann auf höherer Ebene argumentieren, dass ein performanteres gitlab.com mehr Kunden und Reputation bringen könnte; wenn das eigentliche Geschäft aber der Verkauf von self-hosted Software ist, ist es plausibel, Entwicklungsressourcen darauf zu konzentrieren.
Wir haben tatsächlich eine GitLab-Lizenz gekauft, und als wir merkten, dass die Seat-Kosten gleich sind, egal ob GitLab das Hosting übernimmt oder wir selbst, fragten wir uns, warum wir die Infrastrukturkosten tragen sollten.
Wenn man GitLab.com nur halbherzig betreibt, wäre es langfristig vielleicht besser, es entweder richtig zu machen oder das Produkt einzustellen und sich nur auf Self-Hosting-Kunden wie bei GitLab Enterprise Edition zu konzentrieren.
Aber niemand in der Geschäftsführung will so eine Entscheidung treffen.
Also betreibt man das Produkt halbgar.
Für Leute, denen das Produkt selbst wichtig ist, kann diese Situation frustrierend sein.
Jedes Mal, wenn neue Entwickler dazukommen, sagen sie: „Wir müssen uns stärker um Skalierbarkeit kümmern“, und die Seniors antworten: „Ja, ja, wissen wir …“
Aus wirtschaftlicher Sicht ist es wahrscheinlich richtig, einem Entwickler in Amsterdam dasselbe Gehalt zu zahlen wie einem Entwickler in der Bay Area, wenn er denselben Wert liefert.
Der lokale Marktpreis eines Entwicklers in Amsterdam ist zwar niedriger, aber man baut ein globales Unternehmen auf und konkurriert mit anderen globalen Unternehmen.
Selbst wenn man Entwickler in Amsterdam derzeit zu einem reduzierten Preis bekommt, werden Wettbewerber am Ende ein Angebot machen, das näher am tatsächlichen Wert liegt, oder die Leute werden gehen, um ihr eigenes Ding zu machen.
Die stärksten Unternehmen werden Talenten vermutlich standortunabhängige Vergütung zahlen.
Am Ende zählt der gelieferte Wert.
Wenn man wie GitLab eine große Ruby-Codebasis hat und an Großunternehmen verkaufen will, denen Performance und Zuverlässigkeit wichtig sind, würde man so jemandem vermutlich mehr als 120.000 € pro Jahr zahlen.
Die meisten Engineers, denen Performance, Typsicherheit und Zuverlässigkeit wichtig sind, interessieren sich nicht für Ruby; daher ist der Marktpreis für diese Kombination aus Fähigkeiten definitiv höher.
Ob das auf dem Niveau von 500.000 $ pro Jahr in der Bay Area liegt, weiß ich nicht, aber starke Unternehmen, die Top-Talente wollen, werden Talente verlieren, wenn sie Vergütung nicht an den gelieferten Wert statt an den Standort koppeln.
Die Zeit, die für das Deployment von Code benötigt wird, ist meiner Ansicht nach eine der wichtigsten Kennzahlen, vielleicht sogar die wichtigste, um die Entwicklungsgeschwindigkeit eines Startups beim Skalieren aufrechtzuerhalten.
Kontextwechsel gehören zu den teuersten Tätigkeiten im Alltag von Entwicklern und werden dennoch am leichtesten übersehen.
Manager planen Teamkalender gern nach ihrem eigenen Zeitplan, doch das stört häufig den „Maker Schedule“ einzelner Contributors.
Viele Organisationen erkennen das und konzentrieren sich auf die Kosten von Kontextwechseln bei der Terminplanung; für Entwickler ist aber auch die Zeit vom Build bis zum Deployment genauso wichtig oder sogar noch wichtiger.