Ep. 17 - A cultura do Gitlab

Que problema o GitLab tenta resolver? No fim das contas, o problema que o GitLab tenta resolver é reduzir o lead time, o cycle time, reduzir todas as complexidades, o custo, tudo aquilo que é bloqueio entre levar uma ideia à produção e iterar sobre aquilo, participando da melhoria constante de um produto. Do próprio Git até monitoração, usando uma gama de produtos open source que são a base da plataforma.

O GitLab como organização entrou para o Y Combinator em 2015, vindo de uma galera que veio da Europa, e se oficializou como companhia nos Estados Unidos. Inicialmente, montaram um escritório, mas ninguém ia. O CEO então decidiu: eu não estou nem aí com horas, com as tarefas que as pessoas estão fazendo, eu me importo com o resultado. A partir daí, a empresa começou todo um processo de abraçar seus valores e se adaptar como organização para prover o melhor resultado possível. Parte disso é ser uma companhia extremamente transparente, e hoje ela é a maior organização totalmente remota que existe, com mais de 1.200 pessoas em 65 países, sem escritório: o endereço legal da companhia é uma caixa postal em São Francisco.

A gente não fala home office, a gente fala all remote. A diferença: home office implica que você tem uma casa com espaço para trabalhar. All remote não, tem gente trabalhando de motorhome, em parques nacionais pelo mundo afora. Desde que você tenha conexão com a internet e consiga executar seu trabalho de forma eficiente e prover resultado, não importa de onde você trabalha.

Para mim, enquanto usuário, o GitLab consegue ser a fonte singular de verdade de uma interação. No passado, toda vez que eu tentava interagir com código, acabava indo para uma outra ferramenta, porque não conseguia centralizar a verdade num só lugar. No GitLab, a documentação está ali, o código está ali, está tudo ali. O ponto focal de verdade é a ferramenta. E se você tem uma interação onde isso acontece, você vai ter uma interação de qualidade extremamente alta, porque todo mundo está no mesmo lugar. A gente tem esse problema constantemente com e-mail, Slack, onde é meu ponto principal de verdade? Isso casa com a redução de lead time: se você não precisa ficar caçando coisas aqui e ali, seu lead time é automaticamente reduzido. E casa com a descentralização física: tanto faz onde você está, o que importa é que o trabalho está organizado o suficiente para você trabalhar de onde quiser.

O onboarding é todo feito dentro do próprio produto GitLab. No primeiro dia, você recebe um usuário na plataforma e já começa com o seu issue, a tarefa que vai trabalhar nas próximas semanas. Sem pressão: é importante que você tome seu tempo e faça de forma correta, porque para muita gente é uma mudança de paradigma grande. Você tem um onboarding buddy, uma pessoa que não é necessariamente do seu departamento, ali para te familiarizar e reforçar a cultura da organização. E como a empresa é totalmente remota, existe o que chamamos de coffee chat, convidar alguém, de qualquer área da organização, para bater um papo de 15 minutos.

A primeira coisa que me chamou atenção, quando fiz meu primeiro merge request para o GitLab em 2013, foi a gentileza e a ausência de pressão. No open source clássico, o ambiente era extremamente hostil, tinha figuras chamadas de 'ditador benevolente', termos como RTFM (read the fucking manual). Você fazia uma pergunta tranquila, e o dono do projeto, a pessoa mais admirada da comunidade, respondia só 'RTFM': leia a porra do manual e pare de fazer perguntas idiotas. É um ambiente que você aprende, mas é um cooperativo hostil, com brigas entre comunidades, muita pressão e agressividade. No GitLab, a primeira coisa que aconteceu foi alguém dizer: a gente não faz dessa forma, aqui o modelo é diferente, experimente seguir isso aqui. Levei um tempo para o meu merge request ser aprovado, mas aprendi um monte de coisa e nunca me senti intimidado: tinha alguém do outro lado me ajudando o tempo inteiro.

O open source conta muito com a benevolência das pessoas, que doam o seu maior bem, que é o tempo delas, por puro amor. A GitLab faz um grande investimento nessa comunidade. E contribuição não é só código: todo o roadmap de produto é público, você nem precisa fazer login para ler e discutir os issues, dizer 'eu como cliente não vejo dessa forma'. Você não precisa escrever código para contribuir.

A cultura vai ser reflexo do que as pessoas tentam fazer com a empresa? Na verdade, é o contrário: a empresa é reflexo da cultura das pessoas que estão ali. Isso fica muito explícito no GitLab. A gente está falando bastante de cultura, mas também de domínio organizacional, quando fala de melhoria de lead time, e de domínio de negócios, quando fala da satisfação do consumidor e de como a cultura influencia no produto final. Isso é notável.

Se fosse impresso, o handbook teria algo como 5 mil páginas, mas é importante deixar claro: não é um livro que você lê inteiro, é um site onde a gente documenta tudo o que é relevante. Por que documentar tudo? Justamente por ser all remote, as pessoas trabalham em todo tipo de fuso horário, então ser 100% remoto está totalmente alinhado com ser assíncrono; as formas de comunicação não podem requerer que as pessoas estejam disponíveis o tempo todo. Tem desde as falhas do CEO até como a gente pensa em marketing, o fluxo de trabalho de engenharia, as personas de UX. Se você visita o handbook de qualquer time, ele te conta todo o fluxo de como fazem o trabalho. E o mais importante, na minha opinião, são os valores, públicos, e em constante mudança.

Todo novo funcionário tem que fazer um merge request, mesmo alguém que nunca fez um commit na vida, de marketing, jurídico, vendas. Imagina o medo. Mas editar um documento no GitLab é bem diferente de editar um documento normal, não é como editar um Confluence. É divertido de fazer, então as pessoas gostam do processo. Isso não funciona só para código: tudo que dá para versionar, dá para colocar ali, com o mesmo fluxo de revisão, aprovação e publicação automatizada usado no desenvolvimento.

Isso tem muito a ver com eat your own dog food, prove sua própria comida. Se você cozinha, você também come aquela comida. Nos valores do GitLab, que são hierarquizados, no topo está resultado, e resultado envolve uma pessoa qualquer conseguir fazer um commit e um merge request. A missão da GitLab é uma frase: everyone can contribute, todos podem contribuir. Tudo que a gente faz, pensamos com essa mentalidade, como reduzir a barreira de contribuição das pessoas.

Projetos tradicionais de código aberto têm um monte de fricção para você ser contribuidor. Tem uma história antiga de um projeto em que só o fundador tinha tudo na cabeça, nada documentado, era tão agressivo que ninguém conseguia contribuir, e quando ele morreu (foi preso por matar a própria esposa), o projeto morreu junto, porque era só ele. Imagina esse nível de fricção. No GitLab existe uma intencionalidade em diminuir a fricção ao máximo: uma pessoa de vendas que nunca mexeu com código consegue editar a própria foto e biografia no site da empresa.

Não tem essa de 'é fácil para quem já conhece', tem que ser fácil para quem está chegando. Uma boa provocação: você consome o serviço que a sua empresa presta? Se você trabalha num banco e tem conta em outro banco, tem alguma coisa muito errada nisso.

Como a nossa missão é todos podem contribuir, a gente está sempre usando empatia para desenvolver um produto que não só uma pessoa técnica consiga usar. Tentamos reduzir ao máximo o vocabulário que exclui outras pessoas. A gente tem valores de iteração, transparência, resultado, eficiência. Não fala 'a gente usa Scrum'. O próprio termo Scrum já é excludente, já separa dois grupos: você precisa entender de Scrum para saber do que está falando. É diferente de falar 'vamos evoluir com experimentos', 'vamos trabalhar entregando a cada semana', a mesma coisa, numa linguagem muito mais inclusiva.

A vantagem de trabalhar de forma síncrona é poder simplesmente chamar alguém no Zoom e perguntar. Mas se você está assíncrono, sem saber se a pessoa está trabalhando, num fuso horário diferente, você precisa de uma fonte única de verdade, que não pode ser excludente, não pode usar termos que você não conhece. Senão, você fica perdido, e 'leia o manual' não vai adiantar nada. Muitos projetos perdem contribuidores ou morrem por causa dessa fricção alta. Você não está recebendo dinheiro para contribuir, e se sente inútil, porque o processo não te faz se sentir inteligente no início. Nem todo mundo tem tanto tempo: você não pode criar um processo difícil de entrar por diversão. É por isso que, pessoalmente, não gosto de trote, por que eu deveria dar uma experiência ruim para alguém que está entrando?

Onde mora a intersecção entre gostar do produto e gostar da organização? Com uma visão interna, eu não consigo separar uma coisa da outra, porque o produto é uma reflexão da organização, dos seus valores, a forma como criamos os fluxos de desenvolvimento, como encorajamos os funcionários a participar, dada a missão 'everyone can contribute'. Só que, com uma visão externa, às vezes vejo pessoas recebendo essa mensagem meio indiferentes, 'o que me importa que a GitLab é 100% remota, eu só quero um produto para desenvolver meu software'. E eu respeito essa visão: nem todo mundo vai ser só fã do produto ou só da organização, existe um mix. Como todo produto tem bug, tem espaço para melhorar.

Quando meu contrato de três anos representando a América Latina para outra empresa estava acabando, refleti sobre o que fazer da vida, e decidi que não ia comprometer meus valores na próxima empresa. Comecei a ouvir falar do GitLab no mercado por volta de 2015, 2016, e no início ignorei, achei que era só mais um Git qualquer. Quando finalmente olhei o produto, me apaixonei primeiro por ele, depois fui pesquisar a organização, e quando vi o handbook, decidi que precisava trabalhar para essa empresa.

No open source, as pessoas se aproximam dos projetos porque se identificam com as ideologias, a filosofia por trás. O legal do GitLab é que, além do viés de código aberto, tem viés de produto: conecta a ideologia hacker do open source com a ideologia ágil. A velocidade com que entrega funcionalidade é fantástica, mais de 100 meses fazendo deploy todo dia 22, sem ficar ruim.

A gente tá vendo o impacto da cultura nos demais domínios. A gente tem três pessoas aqui que tiveram uma bela impressão do GitLab: uma hospedando um programa gratuito falando sobre a empresa, outra contribuindo desde 2013 gratuitamente, e outra trabalhando lá apaixonada. Tudo isso é consequência do que a empresa valoriza, do que prega, do que acredita de fato: é a missão e os valores que unem essas pessoas.

Até hoje eu não faço ideia de como o GitLab ganha dinheiro: tudo que usei até hoje foi de graça. E quando falo para a galera que dá para usar de graça por muito tempo sem dor, ninguém acredita, mas é fato. O modelo de negócio do século 21 não é tentar tirar dinheiro do consumidor, é fazer o consumidor se apaixonar por você, num modelo financeiramente sustentável. A cultura open source às vezes é mal entendida: as pessoas pensam que é gratuito, mas não é. Alguém está pagando, com dinheiro ou com o próprio tempo, e para dedicar tempo você precisou ter expertise, estudado para aquilo. O produto gratuito e o Community Edition são código puro open source: qualquer um pode copiar e criar sua própria versão. A ideia por trás é que todo mundo ganha com isso, se alguém fizer uma versão melhor, é celebrado. Até a estratégia de aquisição de empresas está pública no handbook, com um processo que começa com um issue no GitLab.

Quando a gente incorpora a filosofia do código aberto, incorpora coisas muito políticas, sobre equilíbrio, espaço econômico, cidadania. Empresas baseadas nessa filosofia acabam trazendo esses vieses políticos para dentro também, sobre contribuição, sobre o que é bem público, sobre licenciamento de software. Isso torna as pessoas mais politizadas, no bom sentido, dentro do meio de código aberto.

Uma mensagem final: seja protagonista da mudança que você quer ver no mundo. Não espere dos outros a saída da inércia, crie esse movimento, por menor que seja. Use sua voz, seu conhecimento, sua experiência, com muita empatia e respeito ao próximo, mas seja o protagonista. Isso conecta com o livro Reinventando as Organizações: o protagonismo individual é fundamental para a evolução de qualquer empresa, de qualquer organização e do mundo como um todo. Essa mensagem é basicamente: seja hacker, tentar entender como as coisas funcionam e como interagir com elas de um modo que fiquem melhores. A partir do momento que a gente aprende uma língua, seja português, seja programação, a gente consegue interagir. Use esse poder para proporcionar as mudanças que você quer.