Liderança no meio da curva: o cuidado que ninguém está tomando com IA

Vários pensamentos vêm martelando na minha cabeça nas últimas semanas e um deles e talvez o principal é: o trabalho de quem lidera engenharia hoje não se parece muito com o trabalho de quem liderava engenharia em 2022. E essa diferença não é cosmética, é estrutural.

Quem está no dia a dia sente. O calendário ainda parece um calendário. As reuniões ainda parecem reuniões. Mas o que se cobra do líder mudou de eixo. A gente está sendo medido por outra régua e, em muitos casos, ainda usando o caderno antigo para anotar.

Quero escrever sobre isso aqui, sem a pressa do post curto de LinkedIn, com tempo de respirar. O que segue é uma tentativa de juntar três conversas que, na prática, são uma só: concepção de produto, liderança técnica e GenAI. E uma quarta, que para mim é a mais importante: como fazer isso sem atropelar pessoas e sendo cuidadoso e gentil com elas.

O surto coletivo do Vale (e o que ele diz sobre nós)

Em maio de 2026, Henrique Calandra publicou um artigo no Substack "IA no RH" que descreve uma cena estranha do Vale do Silício: diretores de big techs pedindo para sair da gestão e voltar a ser IC. Não qualquer IC, um HI-C, High-Impact Individual Contributor, alguém que combina fluência técnica, capacidade comercial e visão de produto.

A minha primeira reação foi a mesma do autor: por que alguém abriria mão de gente reportando, salário maior e status, para "voltar a executar"?

A resposta dele é boa, e vale citar o raciocínio: projetos que antes pediam um PM, um designer, três engenheiros e seis semanas, hoje saem em duas semanas com uma pessoa só, desde que essa pessoa tenha o conjunto certo de habilidades e use as ferramentas certas.

Lembrando que aqui também tem que se levar em conta a complexidade do negócio, produto e arquitetura do sistema. Isso muda muito o cenário.

A McKinsey, no The State of AI 2025, mostra que 88% das empresas globais já usam IA em algum processo, mas só 1% se considera madura no uso. E dentro desse 1%, as estruturas estão encolhendo. Não por austeridade. Por arquitetura.

Esse é o ponto que me incomoda, no bom sentido. A régua de "quantas pessoas se reportam a você" está deixando de ser a régua de senioridade. A nova régua, e que deveria ser sempre, é tamanho do resultado que você consegue entregar.

Eu não acho que isso significa o fim da gestão. Acho que significa uma coisa diferente: a gestão precisa parar de ser confundida com promoção demissão, 1x1 e reunião de alinhamento. Liderar pessoas é uma carreira. Ser especialista de alto impacto é outra. Ambas legítimas, ambas remuneradas no mesmo nível quando bem executadas, algo que já é prática consolidada em empresas maduras, e que ainda engatinha na maioria das empresas brasileiras.

Se você é líder de engenharia hoje, isso te coloca numa posição interessante: você precisa decidir, com calma, se está nesse papel porque escolheu ou porque foi para onde o degrau seguinte apontava. Não é uma pergunta retórica. É uma pergunta de carreira.

Concepção de produto: o que mudou de verdade

Antes de entrar em GenAI, vale parar num ponto que vem antes: a forma como produtos são concebidos hoje.

Por muito tempo, a engenharia foi o "como" depois que o produto definia o "o quê". Eram conversas em sequência: produto descobre, design desenha, engenharia constrói. Cada um defendendo seu pedaço, cada um com sua métrica.

Esse modelo já estava rachando antes da GenAI. O que a IA fez foi acelerar a rachadura.

Hoje, a fronteira entre quem descobre, quem desenha e quem constrói está mais fina. Não porque os papéis sumiram, mas porque o custo de testar uma hipótese caiu tanto que o ciclo "ideia → protótipo → feedback" virou questão de horas, não de semanas. E quem opera nesse ritmo precisa entender as três coisas ao mesmo tempo.

O que isso significa para quem lidera engenharia? Significa que não dá mais para ser um líder técnico que não entende de produto. Não dá para apresentar a entrega só em termos de "funcionalidade pronta". O time precisa, e o negócio precisa, que a entrega venha embrulhada em valor, receita, retenção, custo evitado, NPS, alguma coisa que conecte código com consequência.

O diferencial agora é sobre skills, aprimorar suas skills e saber usar as ferramentas da forma correta.

Para melhorar o fluxo, estamos implementando um modelo onde a tríade Produto+Engenharia+Design decide junta a aposta em uma semana, e a engenharia executa na seguinte. Vira testemunho prático, não tese abstrata. Toda semana tem entrega.

No e-book do meu curso de primeira liderança eu uso uma ferramenta simples para isso: o framework "E daí?". Toda vez que você for reportar uma tarefa, pergunte "E daí?" até chegar no valor de negócio. Refatorei o banco. E daí? Sistema mais rápido. E daí? Suportaremos o dobro de usuários no lançamento sem queda de performance. Aí, sim, virou conversa de produto.

Isso não é firula. É a diferença entre um dev sênior e um líder em formação. E em 2026, com GenAI no meio, virou pré-requisito.

GenAI como amplificador (e o paradoxo que ninguém te conta)

Aqui é onde eu costumo ver mais confusão.

A narrativa pública sobre GenAI tende para dois extremos: ou ela vai substituir todo mundo, ou ela é só uma ferramenta nova. Os dois extremos estão errados, e os dois machucam.

A leitura que me parece mais honesta é a do MIT Sloan, publicada em 2023 e reforçada por dados posteriores: GenAI amplifica capacidade dentro de uma fronteira de competência. Quando usada dentro dos seus limites, tarefas bem definidas, padrões conhecidos, produtividade pode aumentar entre 38 e 42%. Quando usada fora dos seus limites, inovação, julgamento profundo, contexto que só humanos têm, a produtividade cai entre 13 e 24 pontos percentuais, porque as pessoas tendem a "desligar o cérebro" e seguir a recomendação da IA mesmo quando ela está errada.

Esse é o ponto cego da conversa atual. Não é "usar ou não usar IA". É saber onde e como usar, pois não usar não é opção mais.

E tem um segundo dado que precisa entrar no radar do líder: o paradoxo da produtividade. A Bain & Company, no relatório From Pilots to Payoff (2025), mostra que times usando assistentes de IA veem entre 10 e 15% de aumento de produtividade. Mas a maioria das empresas não vê aumento de valor, receita, qualidade, retenção.

As empresas que transformam todo o ciclo de desenvolvimento ao redor de IA, em vez de só adicionar a ferramenta, chegam entre 25 e 30% de aumento real de produtividade. A diferença não é a ferramenta. É o desenho do processo em volta dela.

Vivendo isso na prática: a IA só ganha leverage quando o contexto vive em arquivos versionados, markdowns, que ela lê, não em pessoas.

Para mim, isso é trabalho de líder de engenharia. Não é trabalho de "evangelista de IA", nem de "área de inovação". É trabalho de quem tem um time, um roadmap e uma promessa de entrega.

Documentar, dar contexto e automatizar todo seu fluxo é o que estamos fazendo e o que vai te dar um ganho real e, obviamente, conectando o impacto de negócio real das demandas a serem entregues.

O lado que a planilha não captura: confiança, ritmo e saúde

Aqui é a parte que mais me importa, e é a parte onde mais vejo gestor patinando.

Quando a régua passa a ser "tamanho do resultado", a tentação é apertar. Mais entregas, mais velocidade, mais ROI. A Dev Journal publicou em março de 2026 um relato direto: liderança costuma estabelecer metas de 30 a 40% maiores baseadas em artigos genéricos de ROI, não em dados internos do time. Resultado? Adoção desestruturada de IA platôs em torno de 22% de utilização em 30 dias, ganhos individuais não traduzem em output do time, e a sobra vai para a conta do cansaço.

A HR Executive, em maio de 2026, tem uma frase que ficou comigo: a IA está acelerando o trabalho, e o burnout está subindo no mesmo ritmo. Engajamento global de funcionários caiu de 23% para 21%. Engajamento de gestores caiu de 30% para 27%. A Jellyfish, no 2026 State of Engineering Management Report, vai na mesma direção.

Esse é o terreno onde a liderança de engenharia está sendo cobrada, e onde a maioria não foi treinada. Porque o problema não é técnico. É humano.

Eu tenho falado para as pessoas que mentoro algumas coisas simples e talvez por serem simples, elas funcionam:

• Primeiro: respeite o horário do time como se fosse seu. Mensagem às 23h, mesmo "sem pressa", ensina o time que estar disponível à noite é um valor. Você não precisa dizer isso em voz alta. Seu comportamento já disse. Se precisar escrever fora do horário, agende para o dia útil seguinte. Quase todas as ferramentas têm essa função e quase ninguém usa.
• Segundo: trate IA como assistente, não como decisão. No módulo de IA do meu curso de gestão eu insisto numa regra que veio do uso prático: nunca use IA para decisões finais sobre pessoas, contratação, promoção, desligamento. Use IA para reduzir os 100 CVs a 20 que você precisa olhar com calma. A decisão é sua. A responsabilidade é sua.
• Terceiro: meça valor, não atividade. Se o seu time está usando algum tipo de agente de geração de código, a pergunta certa não é "quantas linhas de código a IA gerou". É "o que o time fez com o tempo que sobrou". Se a resposta for "mais entrega da mesma coisa", você está deixando dinheiro na mesa e cansando o time de graça.
• Quarto: cuide da segurança psicológica como ativo de produção. O BCG mostrou em 2024 que segurança psicológica alta reduz risco de atrito em 75%. O Google, no projeto Aristotle, identificou segurança psicológica como o fator número 1 de performance de times acima de habilidades individuais, experiência ou recursos. Não é "soft". É a base que permite tudo o que vem depois.
• Quinto: proteja quem traz má notícia. Especialmente nesse momento, em que metas estão sendo recalibradas por IA, alguém no time vai precisar te dizer "esse prazo é impossível mesmo com tecnologia X". Como você reage a essa frase define o que vai acontecer nas próximas semanas. Se a pessoa for punida, ninguém vai mais te avisar antes do tombo.

O novo papel do líder de engenharia (que ainda está em construção)

Olhando para tudo isso junto, eu não acho que o líder de engenharia está morrendo. Acho que está sendo reescrito.

O líder de 2022 era avaliado por previsibilidade, escopo e tamanho do time. O líder de 2026 está sendo avaliado por uma combinação diferente: capacidade de leitura de produto, fluência em IA (saber quando usar e quando não), e, talvez o mais raro, capacidade de manter um time saudável dentro de uma cultura que está pedindo mais e mais rápido.

A LeadDev publicou em janeiro um artigo interessante sobre como líderes de engenharia estão usando IA. Um dos pontos que mais me marcou foi este: vários líderes relataram que a IA está permitindo que eles "voltem a se aproximar da tecnologia", não necessariamente codando, mas afinando o senso técnico, construindo empatia, entendendo melhor o trabalho dos devs que eles servem.

Isso me parece importante. A gente passou anos achando que ser gestor era se afastar do código. Talvez o próximo capítulo seja exatamente o contrário: usar IA para reduzir a parte rotineira da gestão (resumos, primeiras versões de documentos, análise de métricas) e usar o tempo que sobra para voltar a entender, em profundidade, o que o time está construindo e por quê.

Não é virar IC de novo. É ser um líder que conhece.

Encerrando, por enquanto

Esse texto está longe de ser conclusivo. É um rascunho de onde estou pensando, e eu prefiro publicar assim do que esperar uma versão "pronta" que nunca chega.

Se eu tivesse que resumir em uma frase só, seria mais ou menos isso: o líder de engenharia de 2026 precisa ser fluente em produto, criterioso com IA, e radicalmente humano com as pessoas, mas não apesar da pressão, e sim exatamente por causa dela.

A pressão é real. A oportunidade também é. E o que vai diferenciar quem sai dessa fase fortalecido de quem sai esgotado não é a velocidade. É o desenho.

Nos próximos posts eu pretendo entrar nos casos práticos. O próximo, especificamente, vai ser sobre algo que estamos implementando no time que lidero: um fluxo de produto desenhado em duas raias paralelas, uma compõe a próxima aposta em cinco dias, a outra executa a anterior em cinco dias, com IA presente em todos os estágios.

Hyper Engineering, e o objetivo é direto e reto como esse: reduzir ao mínimo o ruído e o gargalo entre ideia e resultado. Mas o aprendizado mais incômodo do desenho não é técnico. É cultural: a maior parte das coisas que matam o ritmo de um time hoje são rituais que sobreviveram porque a cultura premia ocupação, não clareza.

Vou destrinchar tudo no próximo texto, incluindo o que morre, o que nasce, e por que matar apostas cedo virou prática de cuidado, não de fracasso.

Se você é líder e está vivendo algo parecido, me escreve. Vamos cruzar esse pedaço da ponte juntos.