Por qué los ingenieros sénior no se meten a evitar que los proyectos malos fracasen

Lalit Maganti, en su blog Why Senior Engineers Let Bad Projects Fail, escribe:

Cuando era un ingeniero junior, mi manager ocasionalmente me confiaba sus frustraciones durante nuestras 1:1 semanales. Señalaba un proyecto en el que otro equipo estaba trabajando y decía: “No creo que ese proyecto vaya a llegar a ningún lado, están resolviendo el problema equivocado”. Yo me preguntaba: “Pero eres muy senior, ¿por qué no vas y hablas con ellos sobre tus preocupaciones?”. Me parecía un desperdicio de su influencia no decir nada.

Es la misma vibra de cuando ves a alguien que va caminando todo absorto en su celular y sin ver el poste que tiene enfrente. Porque eres buena persona, piensas, no mames, debería decir algo. Pero luego tu instinto de preservación genética te pone un alto: que se pegue ‘pa que aprenda a no caminar sin ver por dónde va.

Le escuché a un terapeuta una vez: no les niegues a las personas el privilegio de aprender de sus propios errores.

Pero volviendo al punto original — ingeniería de software.

Lalit habla más desde la perspectiva de un desarrollador, y cómo ser el que se la pasa advirtiéndoles a otros que van por un mal camino puede afectarles:

Una o dos veces puedes ser visto como alguien que está defendiendo la “calidad”. Pero si lo haces con demasiada frecuencia, rápidamente pasas a ser visto como una “persona negativa”, alguien que constantemente genera problemas, no que los soluciona. Rara vez recibes crédito por los desastres que evitaste. Como no pasó nada, la gente lo olvida rápidamente.

Finalmente, también está el impacto psicológico. Hay una sola persona como tú y cientos de ingenieros trabajando en espacios donde tu experiencia podría ayudar. Tu atención es finita, pero la capacidad de una gran empresa para generar malas ideas es infinita. Por experiencia, involucrarte demasiado en detenerlas puede volverte muy cínico respecto al estado del mundo. Y ese no es un buen lugar mental para estar.

El mejor consejo que da sobre cómo manejar estas situaciones —cuando sabes que alguien la está cagando, pero no sabes si deberías decir algo o no— es manejar tu influencia como una cuenta de banco:

Entonces, si no puedes detener todos los malos proyectos, ¿qué haces? Te vuelves estratégico. En lugar de intentar arreglar todo, ve tu influencia como una cuenta bancaria. Cada mes tienes cierta cantidad de “influencia” que entra conforme haces tu trabajo, ayudas a otras personas, entregas proyectos exitosos y, en general, te mantienes como alguien de baja fricción.

Luego, cuando importa de verdad, debes estar listo para hacer “retiros”. Cada vez que bloqueas algo o levantas una preocupación, por pequeña que sea, estás escribiendo un cheque contra tu balance. Pero no todos los cheques cuestan lo mismo:

• El cheque de $5: Un detalle menor en un code review. Gasto barato y cotidiano.
• El cheque de $500: Cuestionar una decisión arquitectónica o presionar contra un timeline. Requiere ciertos ahorros.
• El cheque de $50,000: Intentar matar el proyecto favorito de un VP. Es un gasto enorme. Quizá solo puedas permitirte uno de estos cada varios años.

El problema aparece si gastas $5 en cada pequeña ineficiencia que ves. Si constantemente estás diciendo “no” a cosas pequeñas, tu cuenta estará vacía cuando necesites escribir el cheque grande para detener un verdadero desastre.

Si te “sobregiras”, entras en bancarrota política. La gente deja de invitarte a reuniones, deja de pedir tu opinión y, en esencia, empieza a trabajar alrededor de ti. Una vez en bancarrota, tu influencia cae a cero y no solo dañas tu capacidad de influir, sino también tu habilidad para hacer que las cosas sucedan.

Esto resuena con lo que escribí hace unos meses en Deja de optimizar tu stack, empieza a optimizar tu influencia:

• Lectura de contexto: Qué está intentando lograr el negocio de verdad, más allá del OKR bonito en Notion.
• Cartografía de poder: Quién decide qué, cómo se reparten recursos, quién tiene veto silencioso, quién tiene influencia informal.
• Traducción entre mundos: Cómo explicar riesgos técnicos en lenguaje que finanzas, producto y leadership puedan usar para decidir.
• Diseño de apuestas: No solo “hacer features”, sino proponer apuestas con impacto en métricas y tradeoffs claros.
• Narrativa y visibilidad: Hacer que el trabajo importante se vea, se entienda y se cuente en los foros correctos.

Ese es el stack que te lleva de “buen senior” a alguien que realmente mueve sistemas completos (técnicos y humanos).

Esta es la perspectiva de lo que significa “ganar experiencia” en la industria, más allá de cuántos lenguajes de programación sabes:

Cuando estás al inicio de tu carrera, quieres creer que las buenas ideas ganan por mérito propio; que si simplemente explicas las cosas con suficiente claridad, la gente entrará en razón. A mí me tomó bastante tiempo aceptar que las grandes empresas no funcionan así.

Pero eso no significa que dejes de preocuparte. Significa que te vuelves estratégico respecto a cuándo gastar tu credibilidad. Elige las batallas donde realmente puedes cambiar el resultado, donde tu equipo se verá afectado si guardas silencio, donde el costo de estar equivocado es bajo, pero el costo de que el proyecto falle es alto.

Conocimiento ≠ sabiduría. Cuando escribí que la definición de Full Stack Developer cambia para 2026, me refería justamente a esto:

Lo que está cambiando no es solo el stack técnico. Está cambiando el tipo de valor que las organizaciones necesitan.

Cuando escribir código se vuelve barato, abundante y automatizable, lo que empieza a importar es todo lo demás: entender el problema correcto, navegar organizaciones, influir en decisiones, traducir necesidades humanas en sistemas que funcionen.

Dicho de otra forma: ser un Full Stack Developer ya no se trata de lenguajes de programación y frameworks, sino de habilidades sociales, políticas y de desarrollo de producto; de qué tan bueno eres hablando con personas que no tienen background técnico; de tu capacidad integral para resolver problemas.

Hace unos años podías darte el lujo de ser más pasivo al demostrar habilidades que no estuvieran relacionadas con escribir código. Le dejabas el desmadre “político” a las personas encargadas de eso. Eso era posible porque tu habilidad para producir código todavía no era un commodity.

Lo que dice Lalit en su blog es cierto: tienes que volverte más estratégico al decidir en qué batallas gastas tu capital de influencia. Lo que yo agregaría es que eso ya no aplica solo para seniors, sino para cualquiera que quiera seguir siendo relevante en la industria durante los próximos años.