Como foi trabalhar na GitLab

Experiência na GitLab

• Trabalhei na GitLab por cerca de 6 anos, de outubro de 2015 a dezembro de 2021.
• Decidi sair da GitLab para me dedicar ao trabalho no Inko, mas nunca havia compartilhado minha experiência na GitLab.
• Como o NDA (acordo de confidencialidade) expirou, ganhei energia para revisitar meu tempo na GitLab.

Antes da GitLab

• Trabalhei em uma pequena startup sediada em Amsterdã e, ao mesmo tempo, desenvolvi o Rubinius e o Oga, uma biblioteca de parsing de XML/HTML.
• Por falta de recursos e problemas técnicos, deixamos de levar adiante o uso do Rubinius.
• Entrei na GitLab perguntando se poderia dedicar um dia por semana ao trabalho no Rubinius.

2015-2017

• Meu primeiro dia na GitLab foi o dia seguinte ao meu último dia na empresa anterior, marcando minha transição para o trabalho remoto.
• A GitLab era uma empresa remota, mas também sociável, com vários encontros e eventos.
• A GitLab enfrentava dificuldades como problemas de performance, quedas frequentes de servidores e problemas de gestão.
• Havia pouca infraestrutura de monitoramento de performance, o que dificultava melhorar o desempenho.
• Tentei mudar a cultura e a atitude da GitLab, mas enfrentei dificuldades devido à insatisfação da empresa com as melhorias de performance.

2017-2018

• A performance melhorou bastante, e a GitLab começou a levar performance mais a sério.
• Houve uma mudança para a "equipe de banco de dados", com foco na performance do banco de dados.
• Construí o balanceador de carga de banco de dados da GitLab, o que teve um impacto positivo na performance.
• Me opus, com base em dados, à necessidade de sharding de banco de dados defendida pela GitLab.

2019-2021

• Fui para a equipe de "delivery", com foco em melhorar o processo e as ferramentas de release da GitLab.
• Depois que um commit chegava à branch principal, levava em média vários dias, e no pior caso até 3 semanas, para ser implantado no GitLab.com.
• Liderei o trabalho de unificar o GitLab Community Edition e o GitLab Enterprise Edition em um só.
• Problemas relacionados à gestão de notebooks e mudanças culturais reduziram minha motivação e produtividade.
• Conflitos com um novo gestor levaram à criação de um "plano de melhoria de desempenho".

Lições aprendidas

• Escalabilidade precisa fazer parte da cultura da empresa: a GitLab não deu atenção suficiente à escalabilidade.
• É preciso tornar as equipes mais orientadas por dados e por desenvolvedores: a GitLab tinha uma estrutura centrada em gerentes de produto.
• Sem dados, não dá para decidir o que é um 'produto mínimo viável': a GitLab adotava a "mudança mínima viável" como princípio central, mas na prática criou muitos recursos pouco úteis.
• SaaS e self-hosted não combinam bem: a GitLab oferecia ao mesmo tempo instalações self-hosted e SaaS, mas isso não funcionava de forma eficaz.
• Mais pessoas não significam resultados melhores: a GitLab contratou muitas pessoas ao longo dos anos, mas mais desenvolvedores não significam mais produtividade.
• Conflitos no uso de Ruby on Rails: a GitLab teve sucesso usando Ruby e Ruby on Rails, mas isso se torna um desafio em projetos grandes.
• O tempo de deploy do código é extremamente importante para o sucesso da organização: na GitLab, reduzir o tempo de deploy era um objetivo importante.
• Salário baseado em localização é discriminatório: a GitLab pagava salários diferentes de acordo com a localização, mas isso é uma prática discriminatória.

Opinião do GN⁺

• A experiência na GitLab ajuda a entender os prós e contras do trabalho remoto e os diversos problemas enfrentados no processo de crescimento de uma startup.
• Destaca a importância da melhoria de performance e da escalabilidade, bem como da importância de consolidar isso como cultura.
• Aponta o problema do salário baseado em localização, um caso importante para discutir sistemas de remuneração justos em ambientes de trabalho remoto.

[GN⁺]

Comentários do Hacker News

• A alegação de que salários baseados em localização são discriminatórios

  • Não é apropriado comparar salários baseados em localização com discriminação por cor da pele ou gênero. Cor da pele e gênero não podem ser mudados, enquanto o local de residência pode.
  • O local de residência está relacionado a questões práticas de trabalho, como problemas legais e tributários enfrentados pela empresa, fuso horário e custos de viagem.
  • É possível discutir a discriminação em salários baseados em localização, mas equipará-la à discriminação racial ou de gênero pode encerrar o debate.

• Começou como funcionário número 28 e, gradualmente, mais gerentes foram colocados acima dele

  • Um funcionário que inicialmente se reportava diretamente ao CEO passa gradualmente a ficar sob vários gerentes e, no fim, recebe uma avaliação de desempenho e sai da empresa.
  • Essa é uma situação comum que costuma acontecer em grandes empresas, e por causa dessa estrutura, nelas muitas vezes é difícil alcançar grandes feitos.

• Opinião sobre funcionários usarem computadores pessoais

  • Independentemente do tamanho da organização, deve-se exigir o uso de computadores fornecidos pela empresa.
  • Isso traz grandes vantagens para controlar a propriedade intelectual da empresa e separar o trabalho do tempo pessoal, além de não ter um custo tão alto.

• Opinião sobre maus gerentes

  • Maus gerentes são um mal para o nosso setor, mas muitas startups surgem porque fundadores passaram por maus gerentes em empregos anteriores.
  • O próprio autor encontrou um gerente ruim, não técnico e político, e isso lhe deu motivação para começar uma startup.

• Mudança de opinião sobre salários baseados em localização

  • Deixou de pensar que salários baseados em localização eram discriminatórios e passou a considerar razoável receber um salário que permita viver adequadamente na própria região.
  • Se quiser ganhar mais, é preciso se mudar; e, se não se muda, há um motivo para isso.

• Opinião sobre o uso de Ruby/Rails

  • Ruby foi projetada com a premissa de que a velocidade da linguagem não era importante, mas hoje Node.js e a JVM têm modelos de programação assíncrona que permitem executar outras tarefas durante tempos de espera de IO/rede.
  • Ruby/Rails ainda pode ser útil em certas situações, mas, com o tempo, pode se tornar difícil de manter.

• Opinião sobre política salarial em empresas globais

  • Se um desenvolvedor em Amsterdã entrega o mesmo valor que um desenvolvedor da Bay Area, deveria receber o mesmo salário.
  • Como empresa global, está competindo com outras empresas globais, então, no longo prazo, é importante pagar aos talentos de acordo com o valor que entregam, independentemente da localização.

• Pergunta sobre a política de preços do GitLab

  • Pergunta sobre como selecionar preços baseados em localização na página de preços do GitLab.

• Problemas de gestão quanto à escalabilidade do GitLab

  • O GitLab obtém a maior parte da sua receita com o GitLab Enterprise Edition hospedado pelos próprios clientes, enquanto o GitLab.com custa caro e gera pouca receita.
  • É razoável que a empresa invista na parte que gera receita, mas também é preciso considerar que melhorar o desempenho do GitLab.com pode atrair mais clientes e construir uma reputação mais forte.

• Opinião sobre o crescimento da empresa e o papel dos primeiros funcionários

  • Nem todas as mesmas pessoas continuarão indo bem depois que uma empresa pequena crescer.
  • É responsabilidade da liderança recompensar adequadamente os funcionários que tiveram papel importante no começo e administrar isso sem impedir o crescimento individual nem o da empresa.
  • Há casos em que os primeiros colaboradores acabam esperando um evento de liquidez antecipado ou abrindo mão de grandes ganhos financeiros, porque é difícil preservar ao mesmo tempo o próprio valor e a saúde mental.
  • Para minimizar choques culturais e saídas, é necessário ampliar bastante o prazo de exercício de stock options, priorizar a contratação de funções redundantes para pessoas que mostram sinais iniciais de choque cultural e rotatividade, e oferecer coaching empático que aponte claramente os problemas e inclua recursos sobre equipes ou empresas mais adequadas.