O líder que você acha que é não é o líder que o time percebe

Existe uma versão sua que você não enxerga direito.

Ela aparece nas reuniões em que você não está. Nas mensagens do Teams depois de uma decisão difícil. Na expressão de alguém quando você interrompe sem perceber. No jeito como o time se prepara antes de te trazer um problema.

Essa versão não é melhor nem pior do que a que você carrega na cabeça. Ela só existe.

E, para quem lidera times técnicos, é nesse descompasso que mora a diferença entre evoluir como líder e ficar travado no mesmo lugar.

O espelho interno mente um pouco

Todo mundo tem uma visão sobre si mesmo.

“Eu sou direto.”
“Eu sou exigente.”
“Eu sou técnico.”
“Eu protejo o time.”
“Eu resolvo as coisas.”
“Eu dou autonomia.”

O problema é que o time pode estar traduzindo essas mesmas frases de outro jeito.

“Ele é direto” vira “ele atropela”.
“Ele é exigente” vira “nada nunca está bom”.
“Ele é técnico” vira “ele não deixa ninguém decidir”.
“Ele protege o time” vira “ele centraliza tudo”.
“Ele resolve as coisas” vira “ele não deixa ninguém crescer”.
“Ele dá autonomia” vira “ele some quando a gente precisa”.

A parte desconfortável é essa: quase sempre, as duas versões têm um fundo de verdade.

Você pode realmente querer ajudar e, ainda assim, sufocar.

Pode querer dar clareza e, ainda assim, soar impaciente.

Pode querer elevar a régua e, ainda assim, fazer o time evitar te mostrar trabalho incompleto.

Liderança não acontece dentro da sua intenção. Ela acontece no impacto que você causa.

O que ajudava antes começa a atrapalhar agora

Em engenharia, isso fica especialmente difícil. Muita gente chega à liderança carregando uma identidade técnica forte.

A pessoa passou anos sendo reconhecida por resolver problemas difíceis. Era a referência. A pessoa chamada quando o deploy quebrava, quando o banco travava, quando a arquitetura virava um nó.

Aí ela vira líder.

E o problema é que o jeito de trabalhar que a fez chegar nesse lugar é o mesmo que agora atrapalha.

Antes, entrar no problema e resolver era virtude. Agora, entrar em todo problema e resolver vira gargalo.

Antes, saber mais era vantagem. Agora, saber mais e usar isso para ganhar todas as discussões destrói autonomia.

Antes, velocidade individual era impacto. Agora, impacto depende de quantas pessoas conseguem decidir bem sem você.

Antes, ter opinião técnica forte era o que te diferenciava. Agora, soltar essa opinião cedo demais faz o time parar de pensar e começar a esperar.

Antes, o “tô vendo um problema aí” era um alerta valioso. Agora, dito da forma errada, vira veto.

A transição é cruel porque não parece erro. Parece responsabilidade.

Você olha e pensa:

“Estou ajudando.”
“Estou garantindo qualidade.”
“Estou evitando retrabalho.”
“Estou protegendo o prazo.”

Enquanto isso, o time pode estar pensando:

“Não adianta decidir, ele vai mudar.”
“Melhor esperar ele opinar.”
“Se não estiver perfeito, ele vai desmontar.”
“Isso aqui só anda quando passa por ele.”

Repare uma coisa: ninguém aí está agindo de má fé. Os dois lados estão tentando fazer um bom trabalho. Só que, sem perceber, vocês foram montando juntos um jeito de trabalhar que não serve para nenhum dos dois.

Autoconsciência é monitoramento, não autoflagelação

Muita gente confunde olhar para si com bater em si mesmo.

Não é a mesma coisa.

Pense nisso como observabilidade. Você não coloca métrica em produção para se sentir culpado quando a latência sobe. Você coloca métrica para enxergar o sistema com menos fantasia.

Sem dado, você opera no escuro e chuta. Com dado, você decide.

Com liderança é igual.

Sem saber como você aparece para os outros, sua única referência é a história que você conta para si mesmo. E essa história puxa para o lado generoso onde você quer brilhar, e para o lado duro onde você já se cobra.

Você acha que está disponível porque sua agenda tem espaços livres. O time talvez não te veja como acessível.

Você acha que é pragmático porque corta discussões longas. O time talvez te veja como alguém que não escuta.

Você acha que está dando autonomia porque não acompanha de perto. O time talvez sinta abandono.

O ponto não é decidir quem está certo. É reconhecer que existem dois sinais e que, sem olhar para os dois, você está rodando com metade da telemetria.

A história confortável

Quando o feedback chega, o reflexo é montar a explicação.

“Eles não entendem a pressão.”
“Eles não têm contexto.”
“Eu só faço isso porque ninguém assume.”
“Se eu não entrar, a coisa não anda.”
“É só nessa fase do projeto.”

Pode até ser verdade. Mas também pode ser, exatamente, a história que você conta para proteger sua autoimagem.

A pergunta útil não é “esse feedback é justo?”. A pergunta útil é “como é, na prática, conviver comigo no trabalho, para alguém chegar nessa conclusão?”.

Porque a primeira pergunta julga o feedback. A segunda investiga o que está acontecendo.

Mudança pequena. Efeito enorme.

Um exercício para a próxima semana

Sem questionário. Sem 360. Sem ferramenta. Só atenção.

Escolha uma situação recorrente que você sabe que existe no seu time. Pode ser:

• Revisão de código
• Reunião de planejamento técnico
• Discussão de incidente
• Decisão de arquitetura
• Conversa de carreira com alguém do time

Durante uma semana, em todas as vezes em que essa situação aparecer, observe três coisas:

1. Quanto tempo você esperou antes de falar a primeira vez?

Não a sua opinião final. A primeira interferência. Pergunta, ressalva, “só uma coisa”, “deixa eu entender”. Cronometre se for o caso.

2. Quem parou de falar depois que você entrou?

Olhe para a thread, para a sala, para o call. Quem estava participando antes e some depois da sua aparição? Esse é um sinal forte.

3. A decisão final mudou em relação ao que estava sendo construído antes de você entrar?

Se sim, foi mudança técnica que precisava acontecer? Ou foi você reescrevendo no seu jeito uma decisão que já estava boa o suficiente?

Não tente corrigir nada na primeira semana. Só observe. Anote em algum lugar bobo, um arquivo de texto, um caderno, um Notion qualquer.

Depois de cinco a sete situações observadas, você vai ter dado real. Não opinião. Não autoimagem. Comportamento medido.

E aí, com o dado na mão, escolha um único ajuste para testar nas próximas duas semanas.

Um. Não cinco.

Pode ser algo pequeno tipo:

“Vou esperar três respostas de outras pessoas antes de me posicionar.”
“Vou perguntar ‘que tipo de ajuda você quer aqui’ antes de oferecer solução.”
“Vou escrever minha opinião num rascunho e só mandar depois que a discussão andar mais.”
“Vou explicitar quando estou discordando da ideia, não da forma como foi apresentada.”

Duas semanas. Mesmo tipo de situação. Mesma observação. Compara.

Isso é loop fechado. Hipótese, intervenção, medição, conclusão. O mesmo método que você usa quando uma feature está com performance ruim.

A diferença é que o sistema sob observação é você.

Liderança é o que as pessoas sentem, não o que você acha que está fazendo

No fim, a liderança que importa não é a que você imagina exercer. É a que as pessoas percebem.

A diferença entre uma coisa e outra esconde, ao mesmo tempo, seus maiores pontos cegos e algumas forças que você subestima.

Talvez você seja mais confiável do que imagina. Talvez comunique mais clareza do que percebe. Talvez inspire mais segurança do que sente por dentro. Talvez esteja tentando ser especialista, ainda, quando seu maior valor agora é fazer o sistema andar.

O buraco entre como você se vê e como o time te percebe não é um defeito do líder.

É telemetria.

Serve para te mostrar onde o sistema está se comportando diferente do esperado. Que é, exatamente, o tipo de informação que todo bom engenheiro aprendeu a respeitar antes de virar líder.