Dois anos de empresa global: o que mudou, o que não mudou, o que eu não esperava
Dois anos trabalhando em empresa global de tecnologia — não como dev de produto, mas como Staff Platform Engineer. O que a escala muda, o que a distância cria, e o que só se aprende de dentro.
Dois anos. É tempo suficiente para as primeiras impressões acabarem e a realidade começar. O que eu achava que ia ser diferente do mercado brasileiro e o que de fato é diferente, o que permanece igual, e o que eu simplesmente não sabia antes de estar dentro.
O que muda mais do que eu esperava: a escala de impacto como fonte de responsabilidade. No mercado brasileiro, quando você toma uma decisão de plataforma, ela afeta um time, um produto. Em escala global, a mesma decisão afeta dezenas de times, centenas de engenheiros, sistemas que rodam em múltiplas regiões com regulações diferentes. A responsabilidade não é dez vezes maior — é qualitativamente diferente.
Isso cria um filtro de decisão diferente. Antes, eu avaliava: isso vai funcionar? Hoje, eu avalio: isso vai funcionar em escala, para times com práticas diferentes, em contextos regulatórios variados, e vai ser mantível por quem não fez a decisão original? A segunda pergunta é muito mais difícil de responder.
O que não muda: as pessoas têm as mesmas motivações, os mesmos medos, os mesmos padrões de colaboração e de conflito que em qualquer empresa. Reuniões difíceis existem em inglês também. Decisões políticas existem em empresa global também. A resistência a mudança existe em empresa global também.
Às vezes eu esperava que a sofisticação organizacional fosse mais alta por default. Em algumas dimensões é — processos de revisão de segurança, práticas de incident management, maturidade de SRE. Em outras não é diferente do que eu já tinha visto antes.
O que eu não esperava: a importância de documentar o raciocínio. Em time presencial em português, parte do contexto existe na conversa informal — você entende o que ficou combinado sem precisar escrever. Em time distribuído em inglês, isso não funciona. Se não foi escrito, não existe. Decisões que não têm um RFC, um ADR, um resumo em Slack — evaporam.
Isso criou um hábito que mudou como eu trabalho: antes de qualquer conversa importante, eu documento o que vou decidir e os critérios de decisão. Após a conversa, documento o que foi decidido e por quê. Esse hábito de documentação não é overhead — é como o trabalho acontece de forma que sobrevive além da memória individual.
A barreira de idioma é mais sutil do que parece. Não é o inglês falado — com prática, fluência oral fica natural. É o inglês escrito no tom certo. O que é direto o suficiente para ser eficiente, mas não soa indelicado? O que é formal o suficiente para um RFC que vai ser lido por diretores, mas não pomposo? Esse calibre de tom é aprendido por observação ao longo do tempo, e no início você erra para os dois lados.
O que ajuda: ler muito o que os colegas escrevem. Não para copiar o estilo, mas para entender o espectro de tom que funciona na cultura específica da empresa. Cada empresa tem seus tics de linguagem, suas formas de suavizar crítica, suas formas de escalar urgência. Isso não está no dicionário.
O que mais me surpreendeu positivamente: o acesso a problemas de escala que eu não teria acesso de outra forma. Implementar rate limiting para 10 requests/segundo é um exercício. Implementar rate limiting que funciona de forma consistente em uma arquitetura distribuída com 6 regiões e padrões de tráfego diferentes é outro problema. Eu não teria aprendido o segundo sem ter esse contexto de escala disponível.
Isso vale por si mesmo: se você tem ambição de resolver problemas de escala, estar em um contexto de escala real é irreplaceable. Você pode ler sobre distributed systems — e deve. Mas tem uma diferença entre saber a teoria e ter vivido um incidente causado por ela.
Essa semana: Se você está pensando em fazer a transição para empresa global — ou se já está no processo — identifique uma área onde você sente que falta contexto para a escala: pode ser inglês técnico escrito, pode ser distributed systems, pode ser incident management em time distribuído. Uma área. Invista ali por 3 meses antes de expandir o escopo.