A luz azul do monitor é a única coisa que me acompanha agora. Faz umas duas horas que o Slack parou de apitar. É sempre assim, no final do dia, que as coisas se ajeitam um pouco na cabeça. No meio daquela confusão, na daily das 10h, parecia que não ia.
O silêncio do remoto é traiçoeiro. Não tem o barulho da cadeira, o “licença” pra passar no corredor. É só o ícone verde, e a gente aqui, tentando interpretar o que o outro não está dizendo. Ser Tech Lead sendo… bem, sendo eu, tem sido uma refatoração constante.
Sempre fui o cara do código, da análise fria. Se o bug estava lá, a gente resolvia. Preto no branco. Mas aí vem a gestão de pessoas, e zoom… tudo fica em escala de cinza. A parte mais difícil é não ter o feedback imediato, aquele olhar que diz “entendi” ou “não entendi nada”. No presencial, eu podia ver o ombro encolher quando eu jogava uma tarefa maior. No remoto, é só um “OK” no chat, e aí a ansiedade começa a rodar em background, tipo um processo que não termina.
Lembro de uma vez que passei uma feature grande para o João. Um pedaço complexo do backlog. Na minha cabeça, eu tinha detalhado tudo no Confluence. Os critérios, as dependências, até alguns cenários de falha. A gente se falou por uns dez minutos no meet, ele só concordou. Fiquei com aquela sensação: ele entendeu mesmo? Ou só queria sair logo da reunião? Eu, particularmente, odeio reunião. Odeio ter que “vender” o problema. A minha forma de comunicar é o documento, o código bem comentado.
E aí é que está o nó: a forma como eu absorvo e processo informação — escrevendo, analisando sozinho — não é a forma como a maioria das pessoas se sente motivada a trabalhar. Delegar pra mim não é só passar a tarefa; é ter que criar uma ponte que não existe naturalmente na minha cabeça.
O Cansaço das Ambigüidades
A gente se esgota tentando não ser mal interpretado. Eu sei que meu silêncio, a minha preferência pelo texto, o meu ir direto ao ponto (sempre buscando eficiência, claro), é facilmente lido como desinteresse ou arrogância. A Patrícia, uma das desenvolvedoras, uma vez me disse, meio sem querer, que achava que eu não ligava muito para o que eles estavam fazendo, porque eu só aparecia no code review com correções. A facada silenciosa.
Meu jeito de motivar é dar autonomia. Tipo, tá aqui o problema, a gente confia que você vai resolver do seu jeito. Mas percebi que essa “liberdade” para alguns era só mais uma tela branca, mais um prazo mal definido. Eles precisavam de estrutura, de validação no meio do caminho, de um toque que não parecesse uma cobrança. E para mim, cada check-in que eu faço parece invasivo, um incômodo forçado.
Então, comecei a mudar. Sem método, sem ler livro de gestão. Foi na tentativa e erro mesmo, como um deploy que você faz no staging e vê o que quebra.
Passei a usar o feedback por escrito de um jeito diferente. Em vez de só apontar o erro ou a melhoria técnica no pull request, eu comecei a adicionar um parágrafo que era só contextualização. Tipo: “João, boa solução técnica para o timeout. Esse padrão aqui é importante porque evita que a gente tenha que refatorar X lá na frente, como aconteceu no projeto Y.” Eu justificava o porquê, em vez de só dizer o que fazer. Era a minha análise virando algo útil para ele, não só uma imposição.
No backlog, aprendi a não colocar só a tarefa, mas a “dor” que ela resolvia. Não “Corrigir bug no login”, mas “Resolver falha silenciosa que faz 10% dos usuários abandonarem o carrinho na tela de login (prioridade alta)”. A dor do negócio, o impacto real. Isso dava um senso de propósito que ia além da linha de código.
Delegar é Expor o Raciocínio
É um esforço tremendo. A gente, que processa tudo internamente até a solução estar pronta e polida, tem que aprender a externalizar o rascunho. O “segredo”, se é que existe, não é sobre truques de persuasão. É sobre transparência do pensamento. É mostrar o que me levou a achar que aquela tarefa era a mais importante agora, e por que o skillset dele era o ideal.
Nas reuniões (que continuam longas, mas agora eu tento focar nas que eu realmente preciso estar), eu parei de esperar o momento certo para falar. Eu sou péssimo em pegar a palavra. Então, comecei a usar o chat da reunião, tipo uma bengala. Se o assunto desviava, eu colocava lá: “Só para voltar ao ponto inicial: o prazo do deploy está impactando o João?”. Uma intervenção silenciosa, mas cirúrgica.
O time remoto funciona muito em cima dessa confiança. Eles precisam saber que eu estou ali, analisando, mesmo que eu não esteja falando o tempo todo. Meu jeito de motivar é garantir que o trabalho deles importa, que não vai ser jogado no lixo e que eles têm o espaço para fazer do jeito deles, contanto que o critério de sucesso esteja claro.
Acho que o maior erro era achar que a motivação vinha de fora. O meu papel não é ser um animador de torcida. Meu papel é remover os obstáculos e garantir que a complexidade do problema esteja clara. O resto é a satisfação que o engenheiro tem em resolver um problema bem posto. Aquele alívio de um deploy que sobe sem sustos, aquela falha que a gente achou antes de virar uma crise. Isso é real.
Às vezes, penso que essa dificuldade toda de comunicação, essa fricção constante entre o que eu penso e o que eu consigo expressar verbalmente, acaba drenando uma energia que poderia estar no código. Parece que para a gente ter espaço, a gente precisa se adequar a um molde de “líder” que é inerentemente barulhento, extrovertido, que se sai bem em palco. E a gente não é. A gente se vira.
Talvez isso explique por que esse tema continua aparecendo no meu dia a dia. A clareza da técnica é só uma parte. Tem a outra, a que envolve articular essas ideias, se fazer entender sem parecer que está dando uma ordem. Eu fico pensando se não existe um jeito de otimizar essa parte também, de fazer com que a palavra, a fala, seja tão objetiva e eficiente quanto uma boa rotina refatorada.
