Storytelling técnico en LinkedIn: cómo contar una decisión sin aburrir

Has tomado una decisión técnica importante —migrar de monolito a microservicios, cambiar de proveedor cloud, reescribir el core en otro lenguaje— y quieres contarla en LinkedIn. Te sientas, escribes, y el resultado se lee como un ticket de Jira con contexto añadido: qué hicisteis, qué herramientas usasteis, qué resultado obtuvisteis. Nadie comenta. Nadie pregunta. El post desaparece en seis horas.

El problema no es que el tema sea aburrido ni que tu audiencia no sea técnica de verdad. El problema es que estás escribiendo un informe cuando deberías estar contando una historia con un conflicto real, una apuesta y un coste. La gente no reacciona a decisiones correctas explicadas con precisión; reacciona a decisiones difíciles explicadas con honestidad.

En dos minutos

• Un post técnico funciona si tiene conflicto (algo que podía salir mal), no solo información (qué hicisteis).
• La estructura que mejor rinde es: contexto breve → decisión difícil → coste real → resultado (con matices).
• Corta el detalle técnico antes de lo que crees: en LinkedIn el código y la jerga van en los comentarios, no en el cuerpo.
• Admitir dudas o fracasos parciales genera más conversación que presentar la decisión como obviamente acertada.
• Si escribes para no-técnicos, traduce el riesgo a términos de negocio (tiempo, dinero, disponibilidad), no simplifiques la decisión en sí.

Por qué tus posts técnicos suenan a documentación interna

Cuando llevas años trabajando en ingeniería, escribes por defecto para ser preciso y completo: enumeras opciones consideradas, criterios de decisión, stack final. Es el modo correcto de escribir un ADR (Architecture Decision Record), pero es el modo equivocado de escribir un post que alguien lea en el móvil entre reuniones.

El síntoma más claro es que el post no tiene ningún momento en el que algo pudiera haber salido mal. Si lo lees y todo suena a plan ejecutado sin fricción, no hay historia: hay un resumen. Y los resúmenes no generan comentarios porque no dejan nada abierto sobre lo que opinar.

• Falta un momento de duda real ("no sabíamos si aguantaría la carga").
• Falta una alternativa descartada con motivo honesto, no solo listada.
• Falta el coste: tiempo perdido, algo que se rompió, algo que tuvisteis que revertir.
• Sobra detalle de implementación que solo interesa a quien ya conoce el problema.

La estructura que funciona: conflicto, decisión, coste

Esta estructura no es una fórmula mágica, pero te obliga a incluir los elementos que faltan en la mayoría de posts técnicos. Puedes seguirla como guion antes de escribir la versión final.

1. Contexto en una o dos frases: qué problema tenías y por qué importaba (no técnicamente, sino para el negocio o el equipo).
2. El momento de conflicto: la opción difícil, el trade-off, lo que no sabíais si funcionaría.
3. La decisión y por qué, sin listar las cinco alternativas con pros y contras exhaustivos: elige la tensión principal.
4. El coste real: qué se rompió, qué tardó más de lo previsto, qué tuvisteis que aprender sobre la marcha.
5. El resultado con matices: qué mejoró, qué sigue siendo un problema, qué harías distinto hoy.

Si quieres ver esta lógica aplicada a hooks y aperturas concretas, en la guía hay ejemplos de cómo se traduce esta estructura en la primera línea del post, que es donde se decide si alguien sigue leyendo.

Cuánto detalle técnico incluir (y dónde cortar)

Un error frecuente es intentar demostrar rigor técnico metiendo nombres de librerías, configuraciones o fragmentos de código en el cuerpo del post. El resultado es que solo un porcentaje pequeño de tu audiencia entiende esa parte, y el resto se pierde justo cuando debería estar enganchado con la historia.

La regla práctica es: el detalle técnico específico va en los comentarios, no en el post. En el cuerpo describes el problema y la decisión en términos que un CTO de otra stack o un founder no técnico puedan seguir. Si alguien pregunta "¿qué usasteis exactamente?", ahí es donde entras en detalle, y esa pregunta en comentarios vale más que diez líneas de código que nadie leyó.

Un post técnico no gana credibilidad por la cantidad de detalle que incluye, sino por si el lector entiende qué estaba en juego.

El error de querer sonar objetivo del todo

Muchos perfiles técnicos evitan dar su opinión sobre la decisión porque quieren parecer neutrales o profesionales. El resultado es un post que describe hechos sin postura: "evaluamos X, Y y Z, y finalmente optamos por Y". Es honesto, pero no da a nadie un motivo para comentar, porque no hay nada que rebatir ni con lo que estar de acuerdo.

Contar que dudaste, que casi tomaste la decisión contraria, o que en retrospectiva cambiarías algo, no te resta autoridad. La resta, paradójicamente, sonar como si nunca te hubieras equivocado ni hubieras dudado de nada: eso es lo que activa el filtro mental de "esto suena a marketing" o "esto lo escribió una IA", porque nadie que haya vivido el problema de verdad lo cuenta sin ninguna arruga.

Ejemplo de reestructuración

Imagina un post original que dice: "Migramos nuestro backend de monolito a microservicios. Usamos Kubernetes, mejoramos el tiempo de despliegue y ahora escalamos mejor por servicio." Es correcto y aburrido: no hay conflicto, no hay coste, no hay decisión visible.

Reestructurado con la fórmula anterior podría quedar así: contexto ("cada release del monolito bloqueaba a los tres equipos durante horas"), conflicto ("la opción fácil era vivir con eso otro trimestre más; la otra era parar features seis semanas para dividir el sistema"), decisión y coste ("elegimos dividir, y esas seis semanas se convirtieron en diez porque subestimamos la complejidad de la capa de datos compartida"), resultado con matiz ("hoy desplegamos por servicio, pero seguimos arrastrando un servicio mal cortado que tendremos que revisar"). Es el mismo hecho, pero ahora hay algo sobre lo que un lector puede opinar, preguntar o compartir su propia experiencia.

Cómo aplicarlo esta semana

Coge la última decisión técnica relevante que tomaste y escribe, antes de redactar el post, una sola frase para cada uno de los cinco puntos de la estructura: contexto, conflicto, decisión, coste, resultado. Si no puedes rellenar el punto de coste con algo honesto, probablemente el post todavía suena a informe de éxito, y merece la pena revisar qué parte incómoda estás dejando fuera.

No necesitas inventar dramatismo ni exagerar el conflicto para que funcione: basta con contar la parte que normalmente se omite porque parece poco profesional. Esa parte es, casi siempre, la que hace que el post se lea como algo que escribió una persona y no un departamento de comunicación.

En MyPostCoach trabajamos justo esta capa: ayudarte a estructurar el post y a identificar dónde falta conflicto o dónde sobra detalle, manteniendo tu forma de contar las cosas. Lo que no hace es inventar la historia por ti; el conflicto, la duda y el coste solo los conoces tú, porque los viviste. Si quieres ver cómo encaja esto en un flujo de trabajo semanal, puedes revisar los planes.