What it was like working for Gitlab

Location-Based Pay and “Discrimination”

• Large, contentious subthread on whether location-based salaries are discriminatory.
• One side:
  • Pay should reflect value delivered, not location.
  • Paying less solely due to geography feels akin to other unfair differentials (gender, race), even if not legally the same.
  • Companies don’t regionally discount their own revenue; they’re arbitraging cheaper labor while invoking “fairness” or “cost of living” as PR.
• Other side:
  • Wages follow supply and demand and cost of labor, not abstract fairness.
  • CoL, local markets, taxes, legal overhead, and hiring difficulty differ drastically; ignoring this would either kill hiring in expensive hubs or be economically unsustainable.
  • “Equal pay for equal work” is interpreted by some as equal purchasing power, not equal nominal salary.
• Meta-points: moving is often not a free choice (visas, family), but others argue it’s still more “changeable” than race/sex.
• Some note companies with near-uniform global bands exist, but roles are highly competitive and often pay below top Bay Area levels.

Remote Work and Global Market Effects

• Remote work lets companies tap global talent and also intensifies global wage competition.
• Fears: race to the bottom, offshoring all jobs, local firms unable to compete with foreign remote salaries, and internal inequities (remote workers in cheap regions becoming local “elites”).
• Counterpoints: higher-paid remote workers in poorer regions can significantly boost their local economies; taxes and spending stay local.

GitLab’s Stack, Performance, and Scaling

• Mixed views on Ruby/Rails:
  • Critics: poor raw performance, higher memory use, complex large codebases, weak tooling vs static typing.
  • Defenders: still extremely productive; scaling pain is mostly DB and architecture, not Rails per se; big products have scaled with it.
• Debate on sharding:
  • Some argue sharding is eventually unavoidable for large, user-generated platforms, mainly for DB size and blast radius.
  • Others stress operational and product complexity (cross-shard joins, on‑prem support) and say read replicas + simpler patterns often suffice longer.
• Several note GitLab.com performance reportedly degraded over time; some see under-investment in SaaS scalability as a strategic mistake, others say it followed revenue (self‑hosted EE).

Management, Burnout, and Early-Employee Trajectory

• Many readers resonate with burnout driven more by management, politics, and misaligned expectations than by raw workload.
• Advice themes: don’t give “your all” as an employee; keep boundaries, side projects, and awareness of “the meta” (org politics).
• Discussion that early startup employees often struggle as companies professionalize; they may be seen as hard to manage or unable to adapt, and new layers of management can sideline them.
• Counterpoint: anecdotes are one-sided; some early employees genuinely don’t grow with the org, and performance plans aren’t always pure politics.

Operational Discipline: Backups, Devices, and Process

• Several are struck that backups and backup monitoring at a major dev‑tools company were broken; others say this is sadly common in startups.
• Strong emphasis on regularly testing restores, not just taking backups.
• Debate over bring‑your‑own‑device vs company hardware: security, IP control, and legal discovery vs developer convenience and preference for personal setups.

Product, Features, and Focus

• Some see GitLab’s many half‑baked or abandoned features as evidence of poor product discipline and chasing fads.
• Others argue failed experiments are normal and preferable to stagnation; the real problem is leaving unfinished features in place instead of pruning them.
• Skepticism toward product‑manager‑heavy models; some argue technical leads interfacing directly with users can produce better product decisions.