Trải nghiệm làm việc tại GitLab

Trải nghiệm tại GitLab

• Đã làm việc tại GitLab trong khoảng 6 năm, từ tháng 10 năm 2015 đến tháng 12 năm 2021.
• Đã quyết định rời GitLab để tập trung toàn thời gian vào Inko, nhưng chưa từng chia sẻ về trải nghiệm tại GitLab.
• Do NDA (thỏa thuận bảo mật) đã hết hiệu lực, nay mới có đủ năng lượng để nhìn lại quãng thời gian ở GitLab.

Trước GitLab

• Làm việc tại một startup nhỏ có trụ sở ở Amsterdam, đồng thời tham gia phát triển Rubinius và Oga, một thư viện phân tích cú pháp XML/HTML.
• Do thiếu vốn và các vấn đề kỹ thuật, việc tiếp tục theo đuổi sử dụng Rubinius không còn được thúc đẩy nữa.
• Gia nhập GitLab sau khi hỏi liệu có thể dành một ngày mỗi tuần để tiếp tục làm việc trên Rubinius hay không.

2015-2017

• Ngày đầu tiên ở GitLab là ngay sau ngày làm việc cuối cùng ở công ty trước, và cũng là lúc chuyển sang làm việc từ xa.
• GitLab là một công ty làm việc từ xa nhưng có tính xã hội cao, với nhiều buổi gặp mặt và sự kiện.
• GitLab gặp nhiều khó khăn như vấn đề hiệu năng, máy chủ thường xuyên bị sập và các vấn đề quản lý.
• Hạ tầng giám sát hiệu năng còn thiếu nên rất khó cải thiện hiệu năng.
• Đã cố gắng thay đổi văn hóa và thái độ tại GitLab, nhưng gặp khó khăn vì công ty không hài lòng với tiến độ cải thiện hiệu năng.

2017-2018

• Hiệu năng được cải thiện đáng kể và GitLab bắt đầu nghiêm túc hơn với vấn đề này.
• Chuyển sang 'đội cơ sở dữ liệu', tập trung vào hiệu năng cơ sở dữ liệu.
• Xây dựng bộ cân bằng tải cơ sở dữ liệu cho GitLab, tạo tác động tích cực tới hiệu năng.
• Phản đối nhu cầu phân mảnh cơ sở dữ liệu của GitLab dựa trên dữ liệu thực tế.

2019-2021

• Chuyển sang đội 'phân phối', tập trung cải thiện quy trình và công cụ phát hành của GitLab.
• Từ lúc commit đến nhánh chính cho đến khi được triển khai lên GitLab.com mất trung bình vài ngày, tệ nhất có thể lên tới 3 tuần.
• Dẫn dắt công việc hợp nhất GitLab Community Edition và GitLab Enterprise Edition thành một.
• Các vấn đề liên quan đến quản lý laptop và những thay đổi văn hóa khiến động lực và năng suất giảm sút.
• Xung đột với người quản lý mới dẫn đến việc lập một 'kế hoạch cải thiện hiệu suất'.

Những điều rút ra

• Khả năng mở rộng phải là một phần của văn hóa công ty: GitLab đã không quan tâm đầy đủ đến khả năng mở rộng.
• Cần xây dựng đội ngũ theo hướng dữ liệu và nhà phát triển hơn: GitLab có cấu trúc quá thiên về quản lý sản phẩm.
• Không có dữ liệu thì không thể xác định 'sản phẩm khả dụng tối thiểu': GitLab lấy 'thay đổi chức năng tối thiểu' làm nguyên tắc cốt lõi, nhưng trên thực tế lại tạo ra nhiều tính năng không hữu ích.
• SaaS và tự lưu trữ không thực sự hợp nhau: GitLab đồng thời cung cấp cài đặt tự lưu trữ và dịch vụ SaaS, nhưng điều này không hiệu quả.
• Nhiều người hơn không đồng nghĩa với kết quả tốt hơn: GitLab đã tuyển rất nhiều người qua nhiều năm, nhưng thêm lập trình viên không có nghĩa là năng suất tăng lên.
• Mâu thuẫn quanh việc sử dụng Ruby on Rails: GitLab đã thành công với Ruby và Ruby on Rails, nhưng đây cũng là thách thức với các dự án lớn.
• Thời gian triển khai mã là yếu tố cực kỳ quan trọng đối với thành công của tổ chức: Ở GitLab, rút ngắn thời gian triển khai mã là một mục tiêu quan trọng.
• Lương theo vị trí là phân biệt đối xử: GitLab trả lương khác nhau theo vị trí địa lý, và đây là một hành vi mang tính phân biệt.

Ý kiến của GN⁺

• Trải nghiệm làm việc tại GitLab giúp hiểu rõ hơn về ưu và nhược điểm của môi trường làm việc từ xa cũng như nhiều vấn đề phát sinh trong quá trình startup tăng trưởng.
• Bài viết nhấn mạnh tầm quan trọng của việc cải thiện hiệu năng, khả năng mở rộng và biến chúng thành một phần của văn hóa.
• Việc chỉ ra vấn đề của lương theo vị trí là một ví dụ quan trọng cho thảo luận về cơ chế đãi ngộ công bằng trong môi trường làm việc từ xa.

[GN⁺]

Ý kiến trên Hacker News

• Lập luận cho rằng trả lương theo vị trí là phân biệt đối xử

  • So sánh trả lương theo vị trí với phân biệt đối xử do màu da hay giới tính là không phù hợp. Màu da và giới tính là những thứ không thể thay đổi, trong khi nơi cư trú thì có thể thay đổi.
  • Nơi cư trú gắn với các vấn đề thực tế liên quan đến công việc như pháp lý, thuế, múi giờ và chi phí đi lại mà công ty phải đối mặt.
  • Có thể thảo luận về sự bất công của việc trả lương theo vị trí, nhưng đồng nhất nó với phân biệt chủng tộc hay giới tính có thể khiến cuộc thảo luận bị khép lại.

• Bắt đầu với số nhân viên 28 rồi dần có thêm nhiều quản lý được xếp lên trên

  • Một nhân viên ban đầu báo cáo trực tiếp cho CEO về sau dần nằm dưới nhiều tầng quản lý hơn, cuối cùng bị đánh giá hiệu suất và rời công ty.
  • Đây là tình huống khá phổ biến ở các công ty lớn, và chính kiểu cấu trúc này thường khiến việc tạo ra thành tựu vĩ đại ở doanh nghiệp lớn trở nên khó khăn.

• Ý kiến về việc nhân viên sử dụng máy tính cá nhân

  • Bất kể quy mô tổ chức ra sao, nhân viên nên sử dụng máy tính do công ty cấp.
  • Điều này mang lại lợi ích lớn trong việc kiểm soát tài sản trí tuệ của công ty, tách biệt công việc với thời gian cá nhân, và chi phí cũng không quá cao.

• Ý kiến về quản lý tồi

  • Quản lý tồi là tác nhân gây hại cho ngành của chúng ta, nhưng nhiều startup cũng được sinh ra nhờ việc các nhà sáng lập từng trải qua những quản lý tồi ở công việc trước đó.
  • Chính tác giả cũng từng gặp một quản lý tồi, không có chuyên môn kỹ thuật và nặng tính chính trị, từ đó có động lực để khởi nghiệp.

• Sự thay đổi trong quan điểm về trả lương theo vị trí

  • Từ chỗ cho rằng trả lương theo vị trí là phân biệt đối xử, quan điểm này chuyển sang thấy rằng việc mỗi người nhận mức lương đủ để sống phù hợp tại khu vực của mình là hợp lý.
  • Nếu muốn lương cao hơn thì phải chuyển chỗ ở, và nếu không chuyển thì cũng có lý do của nó.

• Ý kiến về việc sử dụng Ruby/Rails

  • Ruby được thiết kế dựa trên tiền đề rằng tốc độ của ngôn ngữ không quan trọng, nhưng hiện nay Node.js và JVM có mô hình lập trình cho phép xử lý công việc khác trong lúc chờ IO/mạng thông qua xử lý bất đồng bộ.
  • Ruby/Rails vẫn có thể hữu ích trong một số tình huống nhất định, nhưng theo thời gian có thể trở nên khó bảo trì.

• Ý kiến về chính sách lương tại công ty toàn cầu

  • Nếu một lập trình viên ở Amsterdam mang lại giá trị tương đương với một lập trình viên ở Bay Area, thì họ nên được trả mức lương như nhau.
  • Với tư cách là một công ty toàn cầu đang cạnh tranh với các công ty toàn cầu khác, về lâu dài việc trả lương cho nhân tài tương xứng với giá trị họ tạo ra bất kể địa điểm là điều quan trọng.

• Câu hỏi về chính sách giá của GitLab

  • Câu hỏi về cách chọn mức giá theo vị trí trên trang giá của GitLab.

• Vấn đề trong quản lý khả năng mở rộng của GitLab

  • GitLab chủ yếu tạo doanh thu từ GitLab Enterprise Edition tự host, còn GitLab.com thì tốn kém nhưng mang lại ít doanh thu.
  • Việc công ty đầu tư vào phần tạo ra doanh thu là hợp lý, nhưng cũng cần cân nhắc rằng cải thiện hiệu năng của GitLab.com có thể thu hút thêm khách hàng và xây dựng danh tiếng mạnh hơn.

• Ý kiến về sự phát triển của công ty và vai trò của nhân viên ban đầu

  • Không phải tất cả những người cùng phát triển từ thời công ty nhỏ đều sẽ tiếp tục làm tốt khi công ty lớn lên.
  • Trách nhiệm của lãnh đạo là tưởng thưởng xứng đáng cho những nhân viên từng giữ vai trò quan trọng ở giai đoạn đầu, đồng thời quản lý để họ không cản trở sự phát triển cá nhân hoặc sự tăng trưởng của công ty.
  • Có những trường hợp các thành viên đóng góp ban đầu khó duy trì đồng thời cả giá trị của bản thân lẫn sức khỏe tinh thần, nên либо chờ một sự kiện thanh khoản sớm hoặc chấp nhận từ bỏ khoản lợi ích tài chính lớn.
  • Để giảm thiểu xung đột văn hóa và nghỉ việc, cần kéo dài đáng kể thời hạn thực hiện stock option, ưu tiên tuyển người vào vai trò chồng lấn với những cá nhân có dấu hiệu sớm của xung đột văn hóa hoặc rời đi, đồng thời cung cấp coaching đồng cảm, chỉ rõ vấn đề và kèm theo nguồn lực về đội nhóm hoặc công ty phù hợp hơn.