---

---

Siempre te van a juzgar por lo que no hiciste

En el mundo del desarrollo de software, como en muchas áreas técnicas, se ha instalado una ilusión peligrosa: la idea de que el éxito se mide solo por lo que falla. No por lo que funciona, no por lo que se logró bajo presión, con recursos limitados, con plazos imposibles y con una organización que cambia de opinión cada lunes. No. El foco se desplaza, casi con sadismo, hacia el único punto donde algo no salió como se esperaba… aunque ese punto estuviera fuera de tu control.

Imagina esto: llevas meses coordinando con áreas de negocio, ajustando cronogramas, priorizando funcionalidades, traduciendo necesidades vagas en requisitos concretos. El equipo está al límite, pero cumple. El sistema entra en producción sin sobrecostos, sin retrasos catastróficos, incluso con tiempo de sobra para pruebas de estabilidad. Miles de usuarios lo usan sin problema. La métrica de rendimiento mejora. El feedback inicial es positivo.

Pero un día, un pequeño detalle —no previsto en el plan, no solicitado en ninguna especificación, no cubierto por ningún contrato— genera un malentendido con un grupo reducido de usuarios. Tal vez fue un caso extremo, una combinación improbable de factores, una dependencia externa que colapsó sin aviso. Nada de eso estaba en tu alcance. Pero sí en tu responsabilidad. Al menos, así lo deciden los ecos del juicio colectivo.

De repente, todo lo construido se desvanece. Nadie menciona los meses de trabajo nocturno, las reuniones interminables, el código limpio, la arquitectura pensada, la documentación que sí se escribió, las pruebas que sí se pasaron. Solo se habla del “fallo”. Como si un edificio de 50 pisos se redujera a una grieta en el segundo nivel… y esa grieta fuera culpa exclusiva del albañil que no vio el terremoto venir.

Este fenómeno no es nuevo, pero hoy se amplifica. Vivimos en una cultura de lo inmediato, de la reacción visceral, del clip de 15 segundos donde no hay tiempo para matices. Si algo no funciona exactamente como alguien cree que debería funcionar, el resto deja de existir. Peor aún: si ese fallo puede ser convertido en un símbolo —de incompetencia, de elitismo, de desconexión—, será explotado sin piedad.

El problema no es el error. El error es parte del oficio. El problema es el doble rasero: se exige perfección absoluta a quienes construyen, mientras se tolera la vaguedad, la improvisación y la irresponsabilidad en quienes definen las reglas del juego.

¿Quién garantiza que los requerimientos sean claros? ¿Quién asegura que los plazos sean realistas? ¿Quién se hace cargo cuando el negocio cambia de dirección a mitad del sprint y nadie avisa al equipo técnico? Nadie. Porque eso no genera titulares. No da para un meme. No alimenta la narrativa del “profesional fallido”.

Mientras tanto, el ingeniero, el programador, el arquitecto, el analista… sigue sentado frente a su pantalla, sabiendo que, sin importar cuánto haga bien, siempre será recordado por lo que no pudo controlar.

Y esto no es solo injusto. Es contraproducente. Porque cuando se castiga el esfuerzo en lugar de celebrarlo, cuando se ignora el contexto y se reduce el mérito al resultado inmediato, se desincentiva la iniciativa. Se fomenta la parálisis. Se premia el perfil bajo, el “no te metas”, el “haz lo mínimo para que no te echen”.

Peor aún: se normaliza la hipocresía organizacional. Donde los mismos que te piden “innovar rápido” son los primeros en crucificarte si algo no es 100% perfecto. Donde se habla de “cultura de aprendizaje” mientras se reparte culpa pública como moneda de cambio en reuniones ejecutivas.

No se trata de excusas. Se trata de equilibrio. De proporcionalidad. De reconocer que en sistemas complejos —y el software lo es, por definición— la perfección no es un objetivo razonable. Es una trampa.

La próxima vez que critiques un producto, un sistema o una entrega técnica, pregúntate: ¿estoy viendo solo la grieta, o también el edificio? ¿Estoy evaluando el esfuerzo en su totalidad, o solo el punto donde falló? Porque si solo miras lo que no funcionó, terminarás viviendo en un mundo donde nadie querrá construir nada.

Y eso sí que sería un fallo colectivo.

#LiderazgoTécnico #CulturaDeEquipo #GestiónDeProyectos #SoftwareConContexto #ResponsabilidadCompartida #IngenieríaHumana #DesarrolloDeSoftware #MéritoVsPerfección #LinkedInTécnico #SentidoComúnEnTecnología