La experiencia de trabajar en GitLab

La experiencia en GitLab

• Trabajé en GitLab durante unos 6 años, desde octubre de 2015 hasta diciembre de 2021.
• Decidí dejar GitLab para dedicarme por completo a trabajar en Inko, pero nunca había compartido mi experiencia en GitLab.
• Como el NDA (acuerdo de confidencialidad) expiró, tuve la energía para mirar atrás y reflexionar sobre mi tiempo en GitLab.

Antes de GitLab

• Trabajaba en una pequeña startup con base en Ámsterdam, donde también trabajaba en Rubinius y en una librería de parsing XML/HTML llamada Oga.
• Dejamos de impulsar el uso de Rubinius por falta de fondos y por problemas técnicos.
• Entré a GitLab preguntando si podía dedicar un día a la semana a trabajar en Rubinius.

2015-2017

• Mi primer día en GitLab fue el día después de mi último día en la empresa anterior, y pasé a trabajar de forma remota.
• GitLab era una empresa remota, pero también muy social, con muchas reuniones y eventos.
• GitLab atravesaba dificultades por problemas de rendimiento, caídas frecuentes de servidores y problemas de gestión.
• Faltaba infraestructura de monitoreo de rendimiento, lo que dificultaba mejorar el desempeño.
• Traté de cambiar la cultura y la actitud en GitLab, pero fue difícil debido a la insatisfacción de la empresa con las mejoras de rendimiento.

2017-2018

• El rendimiento mejoró mucho y GitLab empezó a tomarse el tema más en serio.
• El equipo pasó a convertirse en el “equipo de base de datos”, con foco en el rendimiento de la base de datos.
• Construí el balanceador de carga de base de datos de GitLab, lo que tuvo un impacto positivo en el rendimiento.
• Me opuse, con base en datos, a la necesidad que GitLab planteaba sobre hacer sharding de la base de datos.

2019-2021

• Me cambié al equipo de “Delivery” para enfocarme en mejorar el proceso y las herramientas de release de GitLab.
• Desde que un commit llegaba a la rama principal hasta que se desplegaba en GitLab.com, el promedio era de varios días y, en el peor de los casos, hasta 3 semanas.
• Lideré el trabajo para unificar GitLab Community Edition y GitLab Enterprise Edition en una sola edición.
• Los problemas relacionados con la gestión de laptops y los cambios culturales redujeron mi motivación y productividad.
• Por conflictos con un nuevo gerente, se estableció un “plan de mejora de desempeño”.

Lo que aprendí

• La escalabilidad debe ser parte de la cultura de la empresa: GitLab no prestó suficiente atención a la escalabilidad.
• Hay que hacer que los equipos estén más orientados a los datos y a los desarrolladores: GitLab tenía una estructura centrada en los product managers.
• Sin datos no se puede decidir un “producto mínimo viable”: GitLab tomó el “cambio mínimo viable” como principio central, pero en la práctica construyó muchas funciones que no resultaban útiles.
• SaaS y self-hosting no combinan bien: GitLab ofrecía al mismo tiempo instalaciones autohospedadas y un servicio SaaS, pero eso no funcionó de manera efectiva.
• Más personas no significa mejores resultados: GitLab contrató a mucha gente a lo largo de los años, pero más desarrolladores no necesariamente mejoran la productividad.
• Conflicto por el uso de Ruby on Rails: GitLab tuvo éxito usando Ruby y Ruby on Rails, pero eso se vuelve un reto en proyectos grandes.
• El tiempo de despliegue del código es clave para el éxito organizacional: En GitLab, reducir el tiempo de despliegue del código era un objetivo importante.
• El salario basado en la ubicación es discriminatorio: GitLab pagaba salarios distintos según la ubicación, pero eso es una práctica discriminatoria.

La opinión de GN⁺

• La experiencia en GitLab ayuda a entender las ventajas y desventajas del trabajo remoto, así como los distintos problemas que surgen durante el crecimiento de una startup.
• Destaca la importancia de mejorar el rendimiento y la escalabilidad, y de convertir eso en parte de la cultura.
• Señala el problema del salario basado en la ubicación, un caso importante para debatir sistemas de compensación justos en entornos de trabajo remoto.

[GN⁺]

Comentarios de Hacker News

• La afirmación de que el salario basado en la ubicación es discriminatorio

  • No es apropiado comparar la discriminación por color de piel o género con el salario basado en la ubicación. El color de piel y el género no se pueden cambiar, mientras que el lugar de residencia sí puede cambiarse.
  • El lugar de residencia está relacionado con cuestiones prácticas vinculadas al trabajo, como los problemas legales y fiscales que enfrenta la empresa, la diferencia horaria y los costos de viaje.
  • Se puede debatir sobre la discriminación en el salario basado en la ubicación, pero equipararla con la discriminación racial o de género puede cerrar la discusión.

• Empezó con el número de empleado 28 y poco a poco le fueron poniendo más gerentes encima

  • Un empleado que al principio reportaba directamente al CEO poco a poco queda bajo muchos gerentes y, al final, recibe una evaluación de desempeño y deja la empresa.
  • Es una situación común que suele ocurrir en grandes empresas, y por esta estructura a menudo es difícil lograr grandes cosas en ellas.

• Opinión sobre que los empleados usen computadoras personales

  • Sin importar el tamaño de la organización, se debería exigir el uso de computadoras proporcionadas por la empresa.
  • Hay grandes ventajas para controlar la propiedad intelectual de la empresa y separar el trabajo del tiempo personal, y además no cuesta tanto.

• Opinión sobre los malos gerentes

  • Los malos gerentes son un perjuicio para nuestra industria, pero muchas startups surgen porque sus fundadores pasaron por la experiencia de tener malos gerentes en trabajos anteriores.
  • El propio autor también conoció a un mal gerente, no técnico y muy político, y eso le dio la motivación para iniciar una startup.

• Cambio de opinión sobre el salario basado en la ubicación

  • Dejó de pensar que el salario basado en la ubicación era discriminatorio y ahora considera razonable recibir un salario que permita vivir adecuadamente en la región de cada quien.
  • Si uno quiere ganar más, tiene que mudarse, y si no se muda, es porque tiene sus razones.

• Opinión sobre el uso de Ruby/Rails

  • Ruby fue diseñado bajo la premisa de que la velocidad del lenguaje no era importante, pero hoy existe un modelo de programación en Node.js y la JVM que permite procesar otras tareas durante los tiempos de espera de IO/red mediante manejo asíncrono.
  • Ruby/Rails todavía puede ser útil en ciertas situaciones, pero con el tiempo puede volverse difícil de mantener.

• Opinión sobre la política salarial en una empresa global

  • Si un desarrollador en Ámsterdam aporta el mismo valor que uno del Área de la Bahía, se le debería pagar lo mismo.
  • Como empresa global, compite con otras empresas globales, así que a largo plazo es importante pagar a los talentos de acuerdo con su valor sin importar la ubicación.

• Pregunta sobre la política de precios de GitLab

  • Pregunta sobre cómo seleccionar precios basados en la ubicación en la página de precios de GitLab.

• Problemas de gestión sobre la escalabilidad de GitLab

  • GitLab genera la mayor parte de sus ingresos con GitLab Enterprise Edition autohospedado, mientras que GitLab.com es costoso y genera pocos ingresos.
  • Es razonable que la empresa invierta en la parte que genera ingresos, pero también debería considerar que mejorar el rendimiento de GitLab.com podría atraer a más clientes y construir una reputación más sólida.

• Opinión sobre el crecimiento de la empresa y el papel de los primeros empleados

  • No significa que, después de crecer desde una empresa pequeña, las mismas personas siempre vayan a seguir desempeñándose bien en todos los casos.
  • Es responsabilidad del liderazgo dar una compensación adecuada a los empleados que cumplieron un papel importante al inicio y gestionarlo sin obstaculizar ni el crecimiento personal ni el de la empresa.
  • A veces ocurre que los primeros contribuyentes, al no poder preservar al mismo tiempo su valor y su salud mental, esperan un evento de liquidez temprano o renuncian a una gran ganancia financiera.
  • Para minimizar los choques culturales y la rotación, hace falta ampliar de forma importante el periodo de ejercicio de las stock options, contratar primero roles redundantes para personas que muestren señales tempranas de choque cultural y rotación, y ofrecer una mentoría empática que señale claramente los problemas e incluya recursos sobre el equipo o la empresa adecuados.