Artigo · Blog
Você conseguiu o trabalho internacional. E aí percebeu que o problema era outro.
A maioria dos engenheiros que entram no mercado internacional resolve o problema errado por anos. O obstáculo não era o idioma, nem o currículo, nem o fuso. Era entender onde, de fato, se produz valor num time distribuído.
Você conseguiu o trabalho internacional. E aí percebeu que o problema era outro.
A primeira vez que trabalhei num projeto com time fora do Brasil, achei que o maior desafio seria comunicação. Inglês técnico, sotaque, fuso horário. Preparei apresentações mais detalhadas. Escrevi mensagens mais longas. Revisava tudo antes de mandar.
Funcionou. Mas não pelo motivo que eu pensava.
O que eu estava fazendo, sem perceber, era compensar uma ausência de contexto compartilhado com volume de texto. E isso tem um custo que só aparece mais tarde, quando o time cresce e a cadência aumenta.
O que a maioria resolve primeiro, e por quê isso é o problema errado
Existe uma trajetória comum entre engenheiros que buscam mercado internacional. O foco vai, nessa ordem, para: inglês técnico, LinkedIn, currículo em inglês, entrevistas, leetcode, system design.
Tudo isso importa. Nenhum disso é o problema central.
O problema aparece depois que você entra. Quando o contexto deixa de ser explícito e começa a existir em conversas que você não estava, em decisões que foram tomadas antes de você chegar, em padrões não escritos que todo mundo segue e ninguém explicou.
Num time local, você compensa isso com presença. Almoço, corredor, reuniões informais. No distribuído, não tem compensação passiva. Você ou constrói o contexto ativamente, ou trabalha cego.
Fui aprender isso da forma mais lenta possível: entregando código que estava certo tecnicamente e errado contextualmente.
O que "trabalhar num time distribuído" realmente significa
Quando entrei na Joyjet, em 2013, era minha primeira experiência com um time entre Brasil e França. Achei que o desafio era o fuso. E o fuso era real, sim. Mas o problema de fundo era outro.
O time francês tomava decisões de produto durante o dia deles. Quando eu acordava, as decisões já tinham sido tomadas. Eu chegava com código pronto para uma direção que havia mudado durante a noite.
Levei um tempo para entender que o problema não era fuso. Era ausência de visibilidade assíncrona. Ninguém sabia, em tempo real, o que eu estava construindo ou por quê. E eu não sabia o que havia mudado enquanto eu dormia.
A solução não foi acordar mais cedo. Foi mudar como eu documentava intenção, não só resultado. Comecei a escrever não apenas "o que fiz", mas "o que estou assumindo" e "onde preciso de confirmação antes de continuar". Isso cortou retrabalho pela metade.
A ilusão do sênior invisível
Tem um padrão que vejo repetir em engenheiros que entram em times internacionais com boa senioridade técnica. Eles entregam bem. Código limpo, PR no prazo, sem ruído. E ficam invisíveis.
Invisível não é problema num time local onde você está fisicamente presente. No distribuído, invisível significa que você não existe nas decisões que importam.
Senioridade técnica, num time distribuído, não se traduz automaticamente em influência. Influência requer presença assíncrona. Comentário em PR que vai além do código. Documento de ADR que ninguém pediu, mas que resolve uma ambiguidade que estava atrapalhando. Pergunta no canal certo no momento certo.
Eu passei tempo demais sendo tecnicamente bom e estrategicamente ausente.
O que realmente diferencia quem escala carreira em times globais
Não é inglês. Não é fuso. Não é nem arquitetura.
É a capacidade de produzir clareza para pessoas que não estão no mesmo contexto que você.
Isso soa simples. Não é.
Produzir clareza significa saber o que o outro precisa entender para tomar uma decisão, e entregar exatamente isso. Sem excesso de detalhe técnico onde não é necessário. Sem abstração vaga onde é necessário precisão. Sem pressupor que o outro tem o mesmo background que você.
Quando trabalhei em São Francisco, na Photozig, o time era pequeno e cross-funcional. Seis pessoas. iOS, Android, QA, lead. As decisões de arquitetura que eu propunha precisavam ser compreensíveis para o lead de produto em dois parágrafos, e defensáveis tecnicamente para o outro iOS em dez minutos de conversa.
Aprendi a calibrar profundidade de acordo com quem precisa decidir, não com quanto eu sei sobre o assunto.
Essa calibragem é uma habilidade. E a maioria dos engenheiros nunca a desenvolve porque em times locais ela é menos crítica.
O erro que cometi por mais tempo do que gostaria de admitir
Tratei a carreira internacional como um problema de acesso. Achar a oportunidade, passar a entrevista, entrar.
Acesso é a menor barreira.
O que sustenta uma carreira internacional de longo prazo é bem diferente. É consistência de entrega em contexto ambíguo. É capacidade de influenciar sem autoridade formal. É construir reputação num ambiente onde você não está fisicamente presente para corrigi-la em tempo real.
Reputação num time distribuído é construída em texto. Em como você escreve uma issue. Em como você responde um PR com discordância técnica sem criar atrito desnecessário. Em como você escalona um problema sem fazer parecer que está reclamando.
Eu subestimei isso por anos. E o custo foi crescer mais devagar do que poderia.
Trade-offs reais de uma carreira distribuída
Não vou romantizar. Trabalhar em time distribuído tem custos concretos.
Decisões demoram mais. O que seria resolvido em dez minutos de conversa vira uma thread de dois dias. Você perde nuances de relacionamento que só existem em presença física. A sensação de pertencimento ao time é mais difícil de construir e mais fácil de perder.
E existe um custo que ninguém menciona: a carga cognitiva de estar sempre "on" em texto. Cada mensagem que você escreve carrega mais peso do que numa conversa ao vivo. Tom errado num momento ruim cria uma narrativa que persiste.
Isso cansa de um jeito diferente do trabalho técnico.
O que eu faria diferente
Investiria muito mais cedo em comunicação assíncrona como habilidade técnica. Não como soft skill. Como disciplina com práticas concretas.
Escreveria ADRs antes de me pedirem. Documentaria decisões que ainda não foram tomadas para provocar alinhamento antes de executar. Pediria feedback sobre clareza, não só sobre qualidade técnica.
E pararia de medir minha presença em reuniões síncronas. No distribuído, quem mais aparece nas calls raramente é quem mais influencia. Quem mais influencia é quem produz os documentos que a call vai discutir.
Uma coisa que levou tempo demais para perceber
Carreira internacional não é uma versão mais difícil de carreira local. É um modelo diferente, com regras diferentes, onde habilidades diferentes determinam progressão.
O engenheiro que mais entrega código nem sempre é o que mais avança. O que mais avança é o que mais reduz incerteza para o time inteiro.
Num time distribuído, reduzir incerteza é o produto mais valioso que você pode entregar. Mais do que qualquer feature.