Cómo contar un fracaso técnico en LinkedIn sin quedar mal

Tienes una historia buena: un despliegue que tiró producción cuatro horas, una decisión de arquitectura que te costó meses deshacer, un cliente que perdiste por un error tuyo. Sabes que contarla en LinkedIn podría generar más conexión que tu último post de 'cinco claves para escalar tu equipo'. Pero también sabes que quien lee puede ser un cliente potencial, un inversor o un recruiter que te está evaluando ahora mismo. Y ahí te frenas: ¿cómo cuentas un fracaso sin que parezca que no sabes hacer tu trabajo?

La mayoría de founders y perfiles técnicos resuelven esto mal de dos formas. O no lo cuentan nunca, y su LinkedIn se convierte en una sucesión de logros que nadie se cree del todo. O lo cuentan como humildad postiza: 'fallé, pero aprendí tanto' sin decir nunca qué falló de verdad. Ninguna de las dos construye confianza. Hay una tercera forma, más incómoda de escribir pero mucho más efectiva: contar el error con la misma precisión técnica con la que contarías un éxito.

En dos minutos

• Cuenta el proceso de decisión, no solo el resultado: qué sabías en ese momento y por qué elegiste esa opción.
• Separa el error técnico del juicio sobre ti mismo: 'tomé una decisión que no funcionó' no es lo mismo que 'soy malo en esto'.
• Evita fracasos que impliquen a terceros identificables (clientes, excompañeros, empresas concretas) salvo que tengas permiso explícito.
• Cierra con el cambio de criterio o proceso que implementaste, no con una moraleja genérica tipo 'nunca te rindas'.
• Si el error es muy reciente o sigue teniendo consecuencias legales o contractuales, espera: contar algo a medio resolver suele salir mal.

Por qué un error bien contado genera más confianza que un logro

Cuando cuentas un éxito, el lector no tiene forma de verificar tu criterio: solo ve el resultado. Cuando cuentas un error y explicas por qué tomaste esa decisión con la información que tenías, el lector ve cómo piensas. Eso es lo que de verdad evalúa un cliente que te va a contratar o un inversor que te va a financiar: no si aciertas siempre, sino si tu proceso de decisión es sólido incluso cuando el resultado sale mal.

Un error bien contado no es una confesión, es una muestra de criterio.

Esto no significa que cualquier fracaso funcione. Si el error demuestra negligencia, falta de preparación básica o un patrón que se repite, contarlo no genera confianza, genera dudas razonables. La clave está en elegir errores que sean defendibles: decisiones razonables que no salieron bien, no descuidos.

La estructura que evita el humble brag

El humble brag técnico suena así: 'metí un bug en producción que casi nos cuesta el cliente... menos mal que mi equipo es increíble y lo resolvimos en tiempo récord'. El foco está en quedar bien, no en el aprendizaje. Para evitarlo, sigue un orden que obliga a explicar el razonamiento antes que el resultado:

1. Contexto técnico mínimo: qué estabas construyendo y qué restricción tenías (tiempo, presupuesto, información incompleta).
2. La decisión: qué elegiste hacer y por qué parecía razonable en ese momento, no a toro pasado.
3. Qué salió mal: el hecho concreto, sin dramatizar ni minimizar.
4. Qué cambiaste después: un proceso, una regla, una herramienta, no solo una intención.

El punto tres es donde más gente se queda corta. Describir el fallo sin detalle ('la cosa no fue bien') no aporta nada porque no deja que el lector aprenda contigo. Tampoco hace falta poner cifras reales si no las tienes claras o no puedes compartirlas; puedes decir 'tardamos más de lo que debíamos en detectarlo' sin inventar un número concreto.

Qué errores no deberías contar en LinkedIn

No todos los fracasos son material de post. Antes de escribir, pasa la historia por este filtro:

• ¿Implica a una persona o empresa identificable que no ha dado permiso para aparecer en la historia?
• ¿Sigue abierto legal o contractualmente de alguna forma?
• ¿Es tan reciente que contarlo ahora podría leerse como una justificación en caliente ante clientes o socios actuales?
• ¿El error revela una carencia que un cliente potencial necesitaría saber antes de contratarte, más que un aprendizaje superado?

Si respondes sí a cualquiera de estas, no es que el error no sirva nunca: es que todavía no es el momento, o necesitas cambiar suficientes detalles para que deje de ser reconocible sin dejar de ser honesto en lo esencial.

Cómo enmarcarlo si quien lee puede ser tu próximo cliente

Esta es la objeción real de muchos CTOs y consultores: 'si cuento que metí la pata, un cliente potencial puede pensar que no soy de fiar'. La solución no es ocultar el error, es encuadrarlo correctamente. Hay una diferencia enorme entre 'no sé hacer X' y 'así es como gestiono X cuando sale mal', y esa segunda frase es exactamente lo que un cliente quiere saber antes de firmar un contrato contigo. Nadie espera cero errores en un proyecto técnico; sí esperan que sepas detectarlos rápido y que tengas un proceso para no repetirlos.

Una forma concreta de aplicarlo: cuando describas el aprendizaje, formúlalo como un cambio de proceso que ahora ofreces como parte de tu forma de trabajar. 'Desde entonces, cualquier cambio en el pipeline de despliegue pasa por una revisión cruzada aunque sea de dos líneas' dice mucho más sobre tu fiabilidad actual que cualquier logro aislado.

Un ejemplo de estructura real

Imagina este esqueleto de post, sin datos inventados, solo como plantilla: primera línea con el hecho concreto ('Hace un año tomé una decisión de arquitectura que tardamos seis meses en deshacer'), seguida de dos o tres líneas de contexto sobre por qué esa decisión parecía correcta entonces, un párrafo describiendo qué empezó a fallar y en qué momento te diste cuenta, y un cierre con la regla o proceso concreto que aplicas ahora para no repetirlo. Nada de frases motivacionales al final, nada de 'el fracaso es el mejor maestro'. El cierre debe ser tan técnico y concreto como el resto del post.

Si quieres ver cómo encajar este tipo de post dentro de una estructura más amplia que mantenga la atención hasta el final, en la guía de Hachi hay más detalle sobre cómo ordenar gancho, desarrollo y cierre en posts técnicos.

Antes de publicar: checklist rápido

• ¿El error es tuyo, no de otra persona identificable?
• ¿Explicas la decisión antes del resultado, no al revés?
• ¿El cierre describe un cambio de proceso concreto, no una moraleja?
• ¿Releyéndolo, sonaría igual de cómodo contándoselo en persona a un cliente potencial?

Si la respuesta a la última pregunta es no, todavía no está listo para publicarse. No porque el error sea malo, sino porque el encuadre aún no transmite lo que quieres que transmita: criterio, no vulnerabilidad sin filtro.

En Hachi ayudamos a estructurar este tipo de posts a partir de tu propia forma de contar las cosas, pero la decisión de qué contar y qué dejar fuera sigue siendo tuya: ninguna herramienta puede evaluar por ti si un error concreto es seguro de compartir con tu audiencia actual.