Síndrome del impostor: la crisis real llega cuando empezás a decidir solo

El síndrome del impostor no se va con la experiencia, cambia de forma: golpea más fuerte cuando empezás a tomar decisiones sin que nadie las revise. Cómo distinguir feedback real de validación disfrazada, y por qué documentar tu razonamiento es el antídoto que funciona.

Desarrollador de software haciendo home office
13 mar 20254 min de lectura
Actualizado el 2 sept 2026

Llevás cinco, seis, siete años programando. Te dieron el pase a tech lead, o simplemente sos la persona con más experiencia del equipo remoto y las decisiones de arquitectura empezaron a caer en tu escritorio sin que nadie las revise antes de que se implementen. Y justo ahí, cuando deberías sentirte más seguro que nunca, aparece la sensación de que en cualquier momento alguien va a notar que estás improvisando.

Esto va más allá de la versión genérica del síndrome del impostor que se explica con “reconocé tus logros”: es la ansiedad puntual que aparece cuando pasás de ejecutar decisiones de otro a ser vos quien las toma, sin la red de seguridad de una revisión senior.

Por qué la transición de seniority lo dispara más que la falta de experiencia

Cuando sos junior o semi senior, cada decisión técnica pasa por al menos una revisión: un PR que aprueba alguien senior, una arquitectura que valida un tech lead, un diseño que discute el equipo antes de implementarlo. Esa revisión, aunque a veces sea frustrante, funciona como una red de contención. Si te equivocás, alguien lo va a agarrar antes de que llegue a producción.

Cuando ascendés, o cuando simplemente sos el dev con más experiencia en un equipo remoto chico, esa red desaparece. Vos sos ahora la última instancia de revisión. Y ahí el cerebro hace algo contraintuitivo: en lugar de sentir que ganaste autoridad, sentís que perdiste el respaldo. La misma ambigüedad que antes resolvía otra persona ahora es tuya, y la ausencia de un “sí, está bien esto” externo se interpreta como evidencia de que no sabés lo que estás haciendo, cuando en realidad es solo la consecuencia lógica de haber crecido.

La trampa de buscar validación donde ya no existe

El error más común en esta etapa es intentar recrear la validación que tenías antes: mandar cada decisión de arquitectura a un canal de Slack pidiendo opinión, aunque ya la tengas resuelta, solo para sentir que alguien más la aprobó. A corto plazo calma la ansiedad. A mediano plazo le manda al equipo, y a vos mismo, la señal de que no confiás en tu propio criterio, y erosiona exactamente la autoridad que estás tratando de construir.

La diferencia entre pedir feedback genuino y buscar validación disfrazada de feedback está en la pregunta que hacés. “¿Qué opinás de este enfoque?” cuando en realidad ya decidiste y solo querés escuchar un “sí” es buscar validación. “¿Ves algún riesgo que no consideré en X o en Y?” cuando genuinamente querés que alguien ponga a prueba tu razonamiento es feedback real. La segunda te hace mejor. La primera solo te hace sentir mejor por un rato.

Documentar tu razonamiento es el antídoto que nadie te recomienda

Lo que más sirve en esta etapa, según lo que vemos en los desarrolladores senior con los que trabajamos en Howdy, es bastante concreto y nada abstracto: escribir el razonamiento detrás de cada decisión de arquitectura antes de implementarla, en un documento corto, aunque nadie te lo pida.

Es para vos: cuando escribís por qué elegiste una opción sobre otra, qué alternativas descartaste y qué riesgos aceptaste conscientemente, dejás de operar en el terreno difuso de “espero que esto esté bien” y pasás al terreno concreto de “esto es lo que decidí y por qué”. Seis meses después, cuando alguien te pregunte por qué el sistema está diseñado así, vas a tener la respuesta escrita en vez de un recuerdo vago de una corazonada. Eso, con el tiempo, es lo que construye la confianza real: la evidencia acumulada de que tu criterio sostiene la prueba del tiempo.

El síndrome no desaparece, cambia de forma

Nadie que yo conozca, ni siquiera los devs con quince años de experiencia liderando equipos, dejó de sentir esa punzada de duda antes de una decisión grande. Lo que cambia con la experiencia es la velocidad con la que dejás de escucharlo, no que el impostor desaparezca del todo. La primera vez que tomás una decisión de arquitectura sin que nadie la revise, la duda puede paralizarte un día entero. Con la práctica de documentar tu razonamiento y de distinguir feedback real de validación disfrazada, esa misma duda dura quince minutos y después seguís laburando.

ESCRITO POR

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