escriturastorytelling técnicolinkedincomunicación técnicavoz propia

Cómo explicar algo técnico en LinkedIn sin perder a quien no lo es

Por Clau Navascués · 12 de octubre de 2026 · 8 min de lectura

Escribes un post sobre por qué migrasteis de arquitectura, cómo decidisteis el stack o qué aprendisteis optimizando una query. Lo revisas, te parece claro. Lo publicas. Y pasa una de dos cosas: o tus pares técnicos lo encuentran plano porque falta sustancia, o tu cliente potencial lo cierra a los tres segundos porque no entiende ni la primera frase.

Esto no es un problema de vocabulario. Es un problema de no haber decidido para quién escribes exactamente, y de intentar que una sola frase haga el trabajo de dos lectores distintos a la vez. Se puede resolver, pero no con la táctica habitual de "quitar palabras raras". Eso suele dejar el post sin sustancia y sin precisión, que es justo lo contrario de lo que querías.

En dos minutos

  • Antes de escribir, decide si el post es para perfiles técnicos, para negocio, o para ambos a la vez con capas distintas.
  • Usa la técnica del doble lector: primera frase de cada bloque en lenguaje de negocio, detalle técnico justo después para quien quiera profundizar.
  • Las analogías ayudan a enganchar pero traicionan la precisión si las fuerzas; úsalas para la intuición, no para explicar el mecanismo exacto.
  • No borres todos los términos técnicos: nombra lo específico (la tecnología, el error, la métrica) y explica solo lo que ese término implica.
  • Antes de publicar, léelo imaginando a dos personas reales: tu CTO de referencia y tu cliente más despistado técnicamente.

El problema no es la jerga, es no saber a quién le hablas

Cuando un post técnico falla, la primera reacción suele ser "tengo que simplificar más". Pero simplificar sin criterio produce el efecto contrario: un texto que no dice nada nuevo para nadie. El verdadero punto de partida es otro: decidir quién es el lector principal de ese post concreto.

No todos tus posts tienen que servir a la misma audiencia. Algunos son para otros ingenieros o CTOs que entienden tu stack sin que lo expliques. Otros son para clientes que nunca van a tocar el código pero necesitan confiar en que sabes lo que haces. Mezclar ambos objetivos en el mismo post, sin decidirlo conscientemente, es lo que produce ese texto que no convence a nadie.

  • Si el objetivo es credibilidad técnica entre pares, puedes nombrar herramientas, errores concretos y trade-offs sin traducir nada.
  • Si el objetivo es que un cliente o inversor confíe en tu criterio, el detalle técnico es secundario; lo que vende es la decisión y su consecuencia.
  • Si quieres llegar a ambos, necesitas estructurar el post en capas, no en un único nivel de lenguaje homogéneo.

La técnica del doble lector

Cuando sí quieres llegar a las dos audiencias en el mismo post, la estructura que mejor funciona es escribir cada bloque en dos capas: una frase de negocio primero, el detalle técnico justo después, como una nota a pie de página dentro del propio párrafo.

Por ejemplo, en vez de escribir "migramos de un monolito a microservicios por problemas de escalabilidad en el módulo de pagos", separa las dos capas: primero la consecuencia ("el equipo tardaba semanas en desplegar un cambio sin romper otra parte del sistema"), y después el detalle técnico para quien quiera el porqué ("el módulo de pagos estaba acoplado al resto del backend, así que aislarlo nos permitió desplegarlo de forma independiente").

El lector no técnico se queda con la primera frase y entiende el problema de negocio. El lector técnico sigue leyendo y encuentra el detalle que valida tu criterio. Nadie se siente excluido ni infantilizado.

No se trata de traducir lo técnico a lenguaje sencillo, sino de ordenar primero la consecuencia y después el mecanismo, para que cada lector se quede en la capa que necesita.

Analogías: úsalas para la intuición, no para el mecanismo

Las analogías son la herramienta más usada para "traducir" algo técnico, y también la que más fácil se rompe. Una analogía buena da intuición rápida de por qué algo importa. Una analogía forzada intenta explicar el mecanismo exacto con una comparación que no aguanta el peso, y un lector técnico la detecta al instante y pierde confianza en el resto del post.

Una regla simple: usa la analogía para explicar por qué algo es un problema, nunca para explicar cómo lo resolviste técnicamente. "Teníamos un cuello de botella como una autopista de un solo carril en hora punta" funciona para transmitir la sensación del problema. Pero si intentas usar la misma analogía para explicar cómo implementaste un balanceador de carga, la comparación se rompe y suena a relleno.

  • Usa analogías cortas, de una frase, no desarrolladas durante todo el párrafo.
  • Resérvalas para el problema o la consecuencia, no para la solución técnica.
  • Si la analogía necesita más explicación que el concepto original, no la uses.

Qué detalle técnico dejar dentro (y qué sacar)

El error más común al escribir para una audiencia mixta es pensar que "técnico" es sinónimo de "complejo" y que hay que quitarlo todo. Pero lo específico es lo que da credibilidad, incluso a quien no lo entiende del todo. Nombrar la tecnología concreta, el error exacto o la métrica que miraste no hace el post más difícil de leer si lo acompañas de contexto; lo hace más creíble, porque demuestra que hablas desde la experiencia y no desde la generalidad.

Lo que sí puedes sacar sin perder nada es la explicación paso a paso de cómo implementaste algo, salvo que ese sea precisamente el tema del post para una audiencia técnica. Para un post orientado a cliente o negocio, basta con nombrar el qué y el porqué; el cómo detallado rara vez aporta valor a ese lector y sí alarga el texto sin necesidad.

  1. Nombra la tecnología o el concepto técnico sin miedo, aunque no lo expliques del todo.
  2. Explica en una frase qué implica ese término para el problema que estás contando.
  3. Deja el "cómo paso a paso" fuera, salvo que el post sea explícitamente para público técnico.
  4. Cierra siempre con la consecuencia de negocio: qué cambió para el usuario, el cliente o el equipo.

Un ejemplo de reescritura

Imagina un primer borrador así: "Implementamos un sistema de caché distribuido con invalidación por eventos para reducir la latencia del endpoint de búsqueda." Es correcto, pero solo sirve a quien ya sabe de qué hablas.

La versión con doble capa podría ser: "La búsqueda en la app tardaba varios segundos en los momentos de más tráfico, y eso se notaba directamente en cuántos usuarios abandonaban antes de ver resultados. Añadimos una capa de caché que se actualiza solo cuando los datos cambian de verdad, en vez de consultar la base de datos cada vez. El resultado: búsquedas casi instantáneas incluso en picos de uso." Aquí la consecuencia va primero, el mecanismo técnico está presente pero acompañado, y el cierre vuelve a hablar en términos que cualquier lector entiende.

Antes de publicar: el filtro de las dos personas

Un truco simple para revisar un post técnico antes de publicarlo: piensa en dos personas reales, no abstractas. Alguien de tu equipo técnico al que respetas, y un cliente o inversor concreto que sabes que no tiene ese background. Lee el post pensando en qué se lleva cada uno. Si al técnico le suena vacío y al no técnico le suena a chino, el post necesita más capas, no más o menos palabras difíciles.

Esto también te ayuda a decidir cuándo un tema simplemente no es para LinkedIn en formato post corto. Hay decisiones técnicas tan específicas que solo interesan a un nicho muy concreto, y forzarlas a un formato de alcance amplio diluye tanto el contenido que no sirve ni a los especialistas ni a nadie más. En esos casos, a veces es mejor un comentario en un grupo técnico o una conversación directa que un post abierto.

Escribir sobre lo técnico sin perder a nadie no es cuestión de vocabulario, es cuestión de orden: consecuencia primero, mecanismo después, y una analogía solo si ayuda a sentir el problema, nunca a explicar la solución. Si quieres una checklist más completa de estructura de posts antes de publicar, tienes una guía con ejemplos en la guía de Hachi.

Hachi no te escribe el post por ti ni decide qué nivel de detalle técnico usar: eso sigue siendo criterio tuyo. Lo que hace es ayudarte a mantener tu voz consistente a lo largo de muchos posts y darte datos reales de qué contenido engancha a tu audiencia, para que puedas decidir con información y no solo por intuición.

Preguntas frecuentes

¿Debo explicar siempre las siglas técnicas en LinkedIn?

No todas, depende del post. Si el post es para público técnico, usar las siglas sin explicar da fluidez y credibilidad. Si hay público mixto, explica solo las que sean centrales para entender la consecuencia de negocio, el resto puedes dejarlas sin desarrollar porque no todos los lectores necesitan seguir cada detalle.

¿Es mejor tener dos cuentas, una técnica y otra de negocio?

En la mayoría de casos no merece la pena mantener dos perfiles activos, porque diluye tu audiencia y duplica el esfuerzo. Es más práctico usar una sola cuenta y variar el nivel de detalle según el post, dejando claro desde la primera frase a quién va dirigido cada contenido.

¿Cómo sé si un post mío quedó demasiado técnico?

Si al leerlo en voz alta necesitas contexto adicional que no está en el texto para que tenga sentido, probablemente es demasiado técnico para una audiencia amplia. Una señal práctica es pedirle a alguien de tu entorno que no sea del sector que te resuma la idea principal; si no puede, falta la capa de consecuencia de negocio.

¿Las analogías técnicas funcionan bien en LinkedIn?

Funcionan si se usan para transmitir la sensación del problema, no para explicar el mecanismo exacto de la solución. Una analogía forzada que intenta sustituir una explicación técnica real suele notarse y resta credibilidad, especialmente entre lectores que sí dominan el tema.

Ponle datos a tu LinkedIn

Diagnóstico gratis con tu historial real. Sin tarjeta y sin publicación automática.

Ver mi diagnóstico gratis