Eu estava lá, apertando botões de plástico e escrevendo letrinhas coloridas “bibipip bopopo”, quando meu tech manager me chamou pra uma call no fim do dia.
Eu gelei.
Eu sabia que tinha estourado o tempo estimado de uma tarefa naquela sprint. Na minha cabeça, aquilo só podia ser uma conversa sobre prazos. Ou pior.
Aí veio.
“Elton, seu desempenho tem sido excepcional e vc tem recebido muitos elogios dos clientes e POs. Por isso queria saber se vc topa se tornar Tech Lead aqui na Cadastra.”
Eu travei.
Demorou alguns segundos pra ficha cair.
Aí lembrei da minha bio no LinkedIn. Fui olhar e lá estava, escrito por um eu do passado que aparentemente sabia mais: “future Tech Lead”.
O futuro chegou antes do que eu imaginava. E bem antes de eu me sentir pronto.
Porque, na minha cabeça, pra ser Tech Lead precisava “comer muito feijão com arroz”. Muito mais do que codar bem. Muito mais do que ser um bom “apertador de botões”.
Se eu ainda ouvisse minhas inseguranças, minha resposta imediata teria sido puts, não. Muita responsa. Mas ainda bem que eu disse “posso pensar?”.
A síndrome do impostor
Confesso que demorei pra escrever sobre isso. Quase um ano. Eu estava esperando duas coisas: a síndrome do impostor dar uma trégua e eu ter algo de útil pra compartilhar.
E a real é essa: virar líder técnico não é promoção. É mudança de profissão.
Estar preparado é uma decisão
Eu sempre admirei meus líderes: a forma como falam nas reuniões, como conduzem conversas com clientes, como navegam problemas complexos com uma calma quase irritante. As respostas vinham prontas, afiadas, como se fossem óbvias.
Eu não fazia ideia de como eles pensavam daquele jeito, só sabia que eu não descansaria até conseguir também.
Então eu aceitei.
Não porque eu me sentia preparado. Mas porque depois de um dia inteiro pensando nisso eu entendi uma coisa:
Estar preparado não é um sentimento. É uma decisão.
Você nunca vai se “sentir” preparado pra algo que só existe depois que você decide ser. A coragem não vem antes do ato. Ela vem junto.
Eu sabia que tinha um gap. Sabia que teria um caminho longo pela frente. Mas gap nunca deixa de existir, não importa o cargo.
O bug não está no código
Descobri o óbvio: ser Tech Lead não é sobre saber tudo, como eu me cobrava. É sobre ser um facilitador. Uma bússola. Alguém que absorve, aprende e traduz o complexo em simples.
Existe um conceito chamado “organizational debt”. É débito técnico, mas de pessoas e processos. A mesma lógica: se você ignora, acumula juros. Quando algo não funciona no time, o instinto é achar que o problema é alguém. Quase nunca é. O problema é o sistema em volta dessa pessoa. Se o deploy quebrou, o problema não é o calango que fez mer(da)ge. É o sistema que permitiu merge sem review, sem testes, sem rollback automático.
A transição de dev pra líder é como passar de escrever funções pra desenhar como elas se conectam. Uma função brilhante isolada não vira um sistema. Um dev brilhante isolado também não. O valor mora nas pontes: entre pessoas, entre contextos, entre aquilo que o cliente diz e aquilo que a equipe entende.
Não é sobre encontrar bug no PR antes dos testes.
É sobre encontrar bug nos processos. Na comunicação. Na forma como a equipe trabalha. Na forma como as decisões são tomadas.
Um número não é um sistema
Números são bonitos. Números parecem objetivos. Mas número isolado é microscópio: te mostra uma célula e você acha que entendeu o corpo inteiro.
Peter Senge, em “A Quinta Disciplina”, tem um mantra que ficou grudado na minha cabeça:
A estrutura do sistema determina o comportamento.
Não são as pessoas. Não é o empenho individual. É o sistema em volta delas. E sistemas têm propriedades emergentes: coisas que não existem em nenhuma parte isolada, só acontecem no todo.
Qualidade é emergente. Performance é emergente. Cultura é emergente. Nenhuma dessas coisas você encontra olhando pra um dev, pra um commit ou pra uma tarefa. Elas moram nas interações, no que sobra entre as partes.
O exemplo clássico de métrica que ilude é estimado vs realizado. É a métrica mais comum porque é fácil de calcular e cabe bonitinho numa planilha. E é uma das mais inúteis, porque mede só uma sombra do trabalho. Ela não te diz se a arquitetura aguenta o próximo trimestre, se o dev aprendeu algo no caminho, se o cliente confia mais no time agora, se a dívida técnica cresceu ou encolheu. Nada do que importa aparece ali.
Tem até um nome pra essa armadilha: Lei de Goodhart. Quando uma métrica vira meta, ela para de medir a realidade e passa a medir o quanto as pessoas estão dispostas a jogar com ela. As estimativas se moldam à expectativa, não à realidade. O número sobrevive. O trabalho real, não.
Senge fala de três níveis de percepção: eventos, padrões e estrutura. A maioria das reuniões de status mora no nível dos eventos: “a tarefa X atrasou”, “o bug Y apareceu”. Líder maduro sobe um nível e procura o padrão. Depois sobe mais um e olha pra estrutura que gera o padrão. É ali, no nível da estrutura, que a intervenção real acontece. Mexer em evento é enxugar gelo.
Quando isso funciona de verdade, ninguém decide olhando número isolado. Olha pra conjunto. Olha pra tendência. Olha pra sinais fracos. E sabe que a parte mais importante do trabalho (confiança, segurança psicológica, aprendizado coletivo) não cabe em célula de Excel.
Silos não são bug de comunicação
Outro lugar onde systems thinking me pegou de jeito foi na gestão de conhecimento. Silos de conhecimento não são falha de comunicação. São o sistema funcionando exatamente como foi (não) desenhado. Se não existe caminho pro conhecimento do time de VTEX IO chegar ao time de FastStore, o silo não é um bug: é o comportamento esperado.
Conhecimento não é artefato. É fluxo. Gente sai, tecnologia muda, memória se degrada. Isso é automático. Documentar é esforço deliberado. Se você não constrói estrutura pra isso, a organização paga pra reaprender o que já sabia.
Na Cadastra eu vi isso acontecendo e decidi intervir na estrutura. Construí uma base de conhecimento centralizada que mudou o “pergunta pro calango” pra “olha na docs”. Falo sobre isso em detalhes nesse case.
O 1:1 fora do planejado
Uma das coisas que mais me pegou de surpresa foi perceber que liderança tem muito mais a ver com percepção do que com técnica.
É perceber que o tom de voz de alguém mudou de ontem pra hoje, e, por causa disso, antecipar um 1:1.
E nessa conversa, descobrir que a pessoa está passando por um momento difícil e não sabia como falar.
E então você ajusta a rota. Conversa com os POs. Reorganiza a sprint. Redistribui carga.
Não só pra entregar, mas pra cuidar de quem está entregando.
E tem uma coisa que eu aprendi na marra: “ajudar” não é chegar e resolver. Ajudar é primeiro entender o contexto. Ir lá resolver pontualmente sem entender o que está em volta pode até piorar as coisas.
Quando você entende, fica muito mais fácil ser um facilitador pra que a pessoa resolva por conta própria. E se não for possível, no mínimo garantir que ela entenda o processo e consiga se virar na próxima.
Isso vale pra código e vale pra gente. O instinto quando alguém traz um problema é resolver. Mostrar que você sabe. Mas o papel do líder não é ser o que resolve. É ensinar a olhar em camadas. Porque a solução real quase nunca mora na superfície.
Quando você lidera, você descobre que muita gente na equipe tem um “Grande Outro” gritando na cabeça deles. Aquele juiz interno invisível que nos paralisa. E parte do seu papel é criar um ambiente onde esse Outro perde força. Onde as pessoas se sentem seguras pra errar, perguntar, admitir que não sabem.
Tem um nome bonito pra isso: segurança psicológica. Não é ser legal. Não é evitar conflito. É o oposto: criar um espaço onde discordância produtiva é possível. O Google estudou centenas de times internos e descobriu que esse é o fator número 1 de alta performance. Não é senioridade, não é stack, não é processo. É a permissão de ser honesto sem medo de retaliação.
E construir isso começa por você. Antes de dar feedback pra alguém, peça feedback sobre você. “O que eu poderia fazer ou parar de fazer que facilitaria trabalhar comigo?” Se você não faz essa pergunta, você está pedindo uma coragem que você mesmo não demonstra.
Porque se eu tivesse deixado o meu Grande Outro vencer naquela call, eu teria dito “não” e continuado apertando botões confortavelmente pelo resto da vida.
Firmeza não é rigidez
Ser Tech Lead é equilibrar projeto, cliente e, principalmente, pessoas.
É cobrar, mas com consciência da realidade. É cuidar, sem perder direção.
É tomar decisões difíceis. Decisões que impactam diretamente a vida e a carreira de outras pessoas. E uma vez tomada, ser firme nela. Firme, não inflexível. São coisas muito diferentes. Firme é não abandonar a decisão na primeira resistência. Inflexível é não ouvir quando a realidade muda.
Existe uma armadilha que pega muitos líderes novos: a empatia que destrói. Você se importa com a pessoa, então evita dizer coisas difíceis pra não magoar. Parece bondade. Mas o resultado é que a pessoa nunca sabe onde está pisando. Recebe só “bom trabalho” genérico. Sabe que errou em algo, mas não sabe exatamente o que. Não tem chance de crescer. A gentileza que omite é pior que a sinceridade que incomoda.
E tem a discordância. Aprendi que na grande maioria das vezes em que há discordância, todas as partes na verdade querem a mesma coisa. O objetivo final é o mesmo. O que muda é o caminho. Então antes de defender meu ponto, eu primeiro me esforço pra entender o do outro. Porque sempre existe a possibilidade de eu estar errado. E quase sempre as opiniões são complementares, não opostas. A melhor solução costuma sair justamente do atrito.
Tem uma frase que ficou na minha cabeça: “Don’t move information to authority; move authority to information.” O calango que está com a mão no código sabe mais sobre aquele contexto do que você. Seu papel não é decidir por ele. É garantir que ele tenha contexto suficiente pra decidir bem.
E no fim, a maior alavancagem quase nunca é técnica. É humana. É aquela conversa de 15 minutos que evita 3 sprints de retrabalho. É perceber que o dev mais quieto da equipe não está “de boa”, está travado e com vergonha de pedir ajuda.
A maior otimização de performance que você pode fazer não está no código. Está nas pessoas que escrevem o código.
O primeiro a levantar a mão
Uma coisa que levo desde a infância: meus pais me ensinaram que, quando a gente erra, o primeiro a levantar a mão tem que ser a gente.
Se você não olha pra si e não reconhece o próprio erro, começa a parecer que nunca errou na vida. Aí vem a tendência de levar tudo pro pessoal e gastar tempo e energia apontando dedos, quando era muito mais simples assumir o erro, identificar o gap e se corrigir.
Sabe por quê? Porque a única coisa sobre a qual você tem controle absoluto é você mesmo. As outras pessoas, o máximo que você pode fazer é criar as condições e mostrar o caminho. O único que você muda de verdade é você.
E a partir daí, você ensina. Mas ensina pela demonstração, não pela fala.
Se você quer um time mais comunicativo, seja mais comunicativo. Se você quer um time mais técnico, traga soluções técnicas. Se quer que o time estude, estude junto. Lidere pelo exemplo, não com discurso bonitinho e vazio.
E tem uma coisa que sustenta tudo isso: estar em constante estado de reflexão. Absorver o que puder e processar pra melhorar. Cada conversa, cada 1:1, cada daily é matéria-prima se você decide olhar pra isso como input.
Um dia um liderado me mandou essa mensagem:
Mano, queria passar pra te agradecer por toda essa honestidade que você tem colocado em todas as oportunidades. Espero que os colegas entendam o que você diz kkkkk. Isso é realmente muito valioso e não estou te falando isso como colega de trabalho mas como pessoa mesmo.
Eu não esperava isso. E foi uma das coisas que mais me confirmou que o caminho da honestidade, mesmo quando é desconfortável, é o certo. Nem todo mundo vai entender na hora. Mas quem entende, valoriza de verdade.
O que aprendi (até agora)
Aquelas listinhas de “10 dicas pra ser um líder melhor” são uma merda, e nem tô em posição disso. Mas se eu tivesse que resumir o que mudou na minha cabeça nesses meses, seria mais ou menos assim:
Liderança é tradução. Você traduz demanda de cliente pra linguagem técnica. Traduz frustração do dev pra linguagem de gestão. Traduz risco técnico pra linguagem de negócio. Se você não sabe traduzir, ninguém se entende.
O silêncio fala mais que o código. Quando alguém para de falar nas dailies, para de participar, para de questionar, isso não é “estar focado”. É um alerta. E é gradual. Retros cada vez mais vazias, perguntas que somem dos code reviews, aquela pessoa que sempre tinha opinião e agora só acena. É como aquecer água devagar: quando você percebe que está fervendo, já queimou.
Vulnerabilidade é força. Dizer “eu não sei” na frente da equipe foi uma das coisas mais difíceis que fiz. E uma das mais poderosas. Porque quando o líder admite que não sabe, ele dá permissão pra todo mundo fazer o mesmo. E aí o aprendizado real começa. A forma como você reage quando recebe crítica define se as pessoas vão te dar feedback de novo ou se vão calar pra sempre.
Saber que sabe é saber e saber que não sabe também é saber!
“Não sei muito sobre esse assunto, mas já conversei bastante com umas 10 pessoas aqui na empresa que sabem isso aí a fundo e conseguem te ajudar em 2 segundos”. Melhor do que a gente ficar aqui 2h quebrando a cabeça ou pior: dar uma orientação incompleta. Faz sentido?
Não existe “fracasso”, apenas “curso intensivo”. Caro pra dedéu, mas intensivo. Todo “fracasso” é na verdade uma aula sobre como não fazer alguma coisa. O problema é que a gente trata erro como fim quando na verdade é feedback. É o sistema te dizendo onde ajustar. Testar até acertar é literalmente a raiz do método científico e, por algum motivo, a gente esquece disso quando a sprint aperta.
O gap nunca fecha. E tudo bem. Gödel provou que todo sistema consistente tem verdades que ele não consegue provar dentro de si mesmo. Com pessoas é igual: por mais que você evolua, sempre vai existir algo que escapa do seu domínio atual. Eu entrei achando que um dia ia “chegar lá”. Hoje eu sei que “lá” não existe. É uma espiral. Cada volta você está num nível diferente, mas nunca para de girar. (Se quiser saber como eu estudo pra tentar acompanhar essa espiral, falo sobre isso aqui.)
No fim, ser Tech Lead não é sobre ter as respostas. É sobre criar o espaço onde as respostas aparecem.
PS: se tbm já pensou “será que estou pronto?”, não está. Ninguém está. Vai assim mesmo e se agradeça depois.