Tu equipo escribió sobre cómo resolvieron aquel problema de concurrencia que les costó tres semanas. Quedó bien, con diagramas y fragmentos de código, y alguien lo compartió en un foro. Dos meses después no llegó una sola consulta comercial desde esa página.
El contenido técnico funciona, el asunto es con quién
Conviene empezar por lo que sí está pasando, porque ese artículo tiene lectores de verdad. En la encuesta Developer Nation de SlashData, sobre más de 17.000 desarrolladores, el 57% aprende con texto largo y el 56% se mantiene al día por redes sociales. Hay un público enorme para lo que escribe tu equipo, y es el mismo público del que ustedes forman parte.
El problema no es la calidad de ese contenido, es que está hablando con tus pares.
El que firma el contrato no busca cómo lo hiciste, busca si ya lo hiciste
Del otro lado hay alguien que necesita resolver algo del negocio y tiene que elegir a quién llamar. No está evaluando tu manejo de concurrencia, está tratando de entender si alguien parecido a su empresa ya pasó por esto con ustedes y salió bien. Quiere saber en qué se mete, cuánto puede tardar, qué suele salir mal y qué pasa cuando el proyecto termina.
Si llega a tu blog, encuentra material excelente para una conversación que no está teniendo.
Las dos audiencias no compiten, se atienden distinto
Nada de esto significa dar de baja el contenido técnico, y conviene decirlo claro. Ese material te ayuda a contratar gente buena, te da prestigio entre quienes te pueden recomendar, y es lo que sostiene el examen cuando un perfil técnico del lado del cliente entra a verificar si son tan sólidos como dicen. Sacarlo sería perder algo que ya construiste.
Lo que falta es la otra pata, la que le habla al que decide, que hoy en la mayoría de los sitios del sector directamente no existe.
Qué publicarías si escribieras para el que decide
Cambia bastante el material. Aparecen los proyectos contados desde el problema del cliente y no desde la solución técnica, con el sector, la restricción que había y qué cambió después. Aparece lo que nadie cuenta, cómo se estima un proyecto así, por qué a veces conviene empezar más chico, qué pasa con el mantenimiento al año siguiente y cómo trabajan con el equipo interno del cliente.
Son temas que tu equipo discute todas las semanas y que casi nunca llegan al sitio, porque suenan menos interesantes que la parte de ingeniería.
Google y los modelos de IA te clasifican por lo que publicas
Acá esto deja de ser una discusión editorial. Un buscador arma su idea de tu empresa con lo que encuentra publicado, y un modelo de lenguaje hace algo parecido cuando tiene que decidir a quién nombrar en una recomendación. Si todo tu contenido gira alrededor de frameworks y arquitectura, la lectura más razonable es que son un buen equipo de ingeniería que escribe sobre ingeniería.
Para aparecer cuando alguien busca quién puede construir un sistema determinado para una industria determinada, tiene que existir contenido sobre eso. No es una fórmula garantizada ni hay manera seria de prometerlo, es una señal que mueve la probabilidad a tu favor, igual que un sitio que se deja leer y un mensaje que dice sin rodeos qué construyen. Ordenar esa parte es de lo que se trata el GEO para empresas de desarrollo de software que hacemos.
El mismo equipo puede escribir las dos cosas
Vuelve un segundo al artículo de concurrencia. No hay que borrarlo ni pedirle que convierta, porque hace bien su trabajo con la gente que lo lee. Lo que falta es su equivalente del otro lado, el artículo que cuenta ese mismo proyecto desde el problema que tenía el cliente, publicado con la misma seriedad.
Tu equipo ya tiene las dos historias. Hoy publica solo una.
