Síndrome do impostor: a crise de verdade chega quando você começa a decidir sozinho

A síndrome do impostor não vai embora com a experiência, ela muda de forma: bate mais forte quando você começa a tomar decisões sem que ninguém as revise. Como distinguir feedback real de validação disfarçada, e por que documentar seu raciocínio é o antídoto que funciona.

Desenvolvedor de software fazendo home office
13 de mar. de 20254 min de leitura
Atualizado em 3 de set. de 2026

Você já programa há cinco, seis, sete anos. Te promoveram pra tech lead, ou você simplesmente é a pessoa com mais experiência da equipe remota e as decisões de arquitetura começaram a cair na sua mesa sem que ninguém as revise antes de irem pra produção. E bem nessa hora, quando você deveria se sentir mais seguro do que nunca, aparece a sensação de que a qualquer momento alguém vai perceber que você está improvisando.

Isso vai além da versão genérica da síndrome do impostor que se explica com "reconheça suas conquistas": é a ansiedade específica que aparece quando você passa de executar decisões de outra pessoa pra ser você quem toma essas decisões, sem a rede de segurança de uma revisão sênior.

Por que a transição de senioridade dispara isso mais do que a falta de experiência

Quando você é júnior ou pleno, cada decisão técnica passa por pelo menos uma revisão: um PR que alguém sênior aprova, uma arquitetura que um tech lead valida, um design que a equipe discute antes de implementar. Essa revisão, mesmo às vezes sendo frustrante, funciona como uma rede de proteção. Se você errar, alguém vai pegar antes de chegar em produção.

Quando você é promovido, ou quando simplesmente vira o dev com mais experiência numa equipe remota pequena, essa rede desaparece. Agora você é a última instância de revisão. E aí o cérebro faz algo contraintuitivo: em vez de sentir que ganhou autoridade, você sente que perdeu o respaldo. A mesma ambiguidade que antes outra pessoa resolvia agora é sua, e a ausência de um "sim, tá bom isso" externo é interpretada como evidência de que você não sabe o que está fazendo, quando na verdade é só a consequência lógica de ter crescido.

A armadilha de buscar validação onde ela já não existe mais

O erro mais comum nessa fase é tentar recriar a validação que você tinha antes: mandar cada decisão de arquitetura pra um canal do Slack pedindo opinião, mesmo já tendo resolvido, só pra sentir que outra pessoa aprovou. No curto prazo, isso acalma a ansiedade. No médio prazo, manda pra equipe, e pra você mesmo, o sinal de que você não confia no seu próprio critério, e corrói exatamente a autoridade que você está tentando construir.

A diferença entre pedir feedback genuíno e buscar validação disfarçada de feedback está na pergunta que você faz. "O que você acha dessa abordagem?" quando na verdade você já decidiu e só quer ouvir um "sim" é buscar validação. "Você vê algum risco que eu não considerei em X ou em Y?" quando você genuinamente quer que alguém teste seu raciocínio é feedback de verdade. A segunda te faz melhor. A primeira só te faz sentir melhor por um tempo.

Documentar seu raciocínio é o antídoto que ninguém te recomenda

O que mais ajuda nessa fase, segundo o que a gente vê nos desenvolvedores seniores com quem trabalhamos na Howdy, é bem concreto e nada abstrato: escrever o raciocínio por trás de cada decisão de arquitetura antes de implementá-la, num documento curto, mesmo que ninguém tenha pedido.

É pra você mesmo: quando você escreve por que escolheu uma opção em vez de outra, quais alternativas descartou e quais riscos aceitou conscientemente, você para de operar no terreno vago do "espero que isso esteja certo" e passa pro terreno concreto do "foi isso que decidi e por quê". Seis meses depois, quando alguém perguntar por que o sistema é desenhado assim, você vai ter a resposta escrita em vez de uma lembrança vaga de um palpite. Isso, com o tempo, é o que constrói a confiança de verdade: a evidência acumulada de que seu critério resiste à prova do tempo.

A síndrome não desaparece, ela muda de forma

Ninguém que eu conheço, nem mesmo os devs com quinze anos de experiência liderando equipes, parou de sentir essa pontada de dúvida antes de uma decisão grande. O que muda com a experiência é a velocidade com que você para de dar ouvidos a ela, não que o impostor desapareça de vez. Na primeira vez que você toma uma decisão de arquitetura sem que ninguém a revise, a dúvida pode te paralisar o dia inteiro. Com a prática de documentar seu raciocínio e de distinguir feedback real de validação disfarçada, essa mesma dúvida dura quinze minutos e depois você volta a trabalhar.

ESCRITO POR

Lead de contenido editorial de Howdy
Matías GomezEditorial Lead
COMPARTILHAR