De consultor de marketing a programador: por qué crucé una línea que la mayoría no cruza
La versión breve: después de más de una década asesorando a marcas en branding, marketing y comunicaciones, tanto desde agencias como de forma independiente, seguía topándome con el mismo muro: desarrolladores capaces de construir casi cualquier cosa, pero que rara vez entendían por qué importaba, en primer lugar, una decisión de marketing o de diseño. La traducción entre nosotros costaba tiempo real y dinero real, una y otra vez, con equipos distintos y en años distintos. Con el tiempo dejé de contratar para tapar esa brecha y empecé a cerrarla yo mismo.
El muro con el que seguía topándome
A lo largo de doce años en branding, marketing y comunicaciones, trabajé en ambos lados del mundo de las agencias: dentro de agencias que atendían a muchas marcas a la vez, y de forma independiente, asesorando directamente. Salas distintas, clientes distintos, el mismo muro.
Entregaba una estrategia, una pieza de razonamiento de diseño, una razón por la que un titular tenía que decir exactamente lo que decía, y la veía llegar, ya alterada de maneras que importaban, al otro lado de la construcción. No por mala fe. Simplemente se perdía. Un desarrollador simplificaba algo por conveniencia técnica y no se daba cuenta de que, sin querer, había eliminado su propósito. O construía exactamente lo que se le pedía, de forma literal, sin entender el "por qué" detrás de ello, y entregaba algo técnicamente correcto y estratégicamente equivocado. O los dos pasábamos días traduciendo una pieza de estrategia a un brief con el que un equipo de desarrollo pudiera trabajar, y aun así algo se escapaba en ese ir y venir. O el trabajo resultaba técnicamente excelente y completamente indiferente a lo que en realidad provocaba en la conversión o en la marca.
Nada de esto era culpa de un mal desarrollador o de un mal mes. Era el mismo fallo, vestido de otra forma, repitiéndose, con equipos distintos y en años distintos. Cada vez que ocurría, costaba tiempo, costaba dinero y, peor aún, le costaba al cliente una versión del trabajo silenciosamente peor que la que se había diseñado.
Por qué contratar para sortear el problema nunca lo resolvió
La solución obvia parece ser contratar mejor, preparar un brief más riguroso, o encontrar "al desarrollador adecuado". Probé las tres, más de una vez. Ayudan en los márgenes. No resuelven el problema estructural, que es que un brief es una traducción, y toda traducción pierde algo. La persona que lo recibe nunca estuvo en la sala donde se tomó la decisión, así que llena los vacíos con su propia suposición razonable, y las suposiciones razonables se desvían.
Eso no es un problema de contratación. Es un problema de distancia. La única solución que de verdad lo cierra es eliminar la distancia: sentar a la persona que entiende por qué se tomó la decisión en el mismo puesto que la persona que la construye.
La decisión
Así que tomé la decisión que la mayoría de las personas en mi posición no toma. Dejé de delegar la construcción y aprendí a hacerla yo mismo.
No hubo bootcamp ni curso detrás de esto. Aprendí por mi cuenta, directamente sobre trabajo real, construyendo para proyectos reales a medida que aprendía, en lugar de practicar primero con ejercicios desechables y aplicarlo después. Fue más lento y más desordenado de lo que habría sido un curso estructurado, y significó aprender en público, con trabajo que importaba, sin red de seguridad entre un error y el momento en que un cliente lo viera. También fue la única forma que de verdad cerró la brecha, porque cada proyecto que construí fue una prueba real de si la estrategia había sobrevivido a la construcción, y no la simulación de una.
Lo que realmente cambió
La diferencia no fue que mi código llegara a ser mejor que el de un desarrollador especializado. Rara vez lo fue, y nunca afirmé lo contrario. La diferencia fue que ya no se perdía nada. El razonamiento detrás de una decisión ya no necesitaba sobrevivir a una entrega, porque no había entrega. La persona que entendía por qué algo importaba era la persona que lo construía, así que el "por qué" nunca tuvo que traducirse, y nunca tuvo ocasión de desviarse.
Ese es todo el argumento para cruzar la línea de consultor a programador. No que una persona pueda construir mejor que un especialista. Que una persona que sostiene los dos extremos de la misma decisión deja de perder lo que un relevo siempre pierde.
Preguntas frecuentes
Porque el problema no era la calidad de los desarrolladores con los que trabajaba. Era la distancia. Un brief es una traducción, y toda traducción pierde algo, sin importar la habilidad de quien la recibe. La única solución real era eliminar por completo ese paso de traducción.
Varias cosas que se superponían entre sí, y todas se repetían: la intención de diseño y UX eliminada en silencio por conveniencia técnica, trabajo construido exactamente como se pedía de forma literal, sin entender por qué importaba, idas y venidas lentas y costosas para traducir la estrategia en un brief técnico, y trabajo técnicamente sólido que ignoraba lo que realmente provocaba en la conversión o en la marca.
No. Aprendí por mi cuenta directamente sobre proyectos reales, construyendo para trabajo real de clientes a medida que aprendía, en lugar de practicar por separado primero. Fue más difícil, pero significó que cada habilidad que adquiría se ponía a prueba de inmediato en trabajo que realmente importaba.
No está exento de riesgo, y en algunos tramos fue más lento de lo que habría sido un curso estructurado. Pero también era la única forma de comprobar de verdad si una pieza de estrategia había sobrevivido a la construcción, porque no había ningún proyecto sustituto que hiciera las veces del real.
No, y ese nunca fue el objetivo. La idea nunca fue que pudiera construir mejor que un especialista. Era que, al ser dueño tanto de la estrategia como de la construcción, el razonamiento detrás de una decisión nunca tenía que sobrevivir a un traspaso, porque no había ningún traspaso que sobrevivir.
Prefiero guardarme los detalles de eso, pero pasar de una carrera consolidada en consultoría a la construcción práctica no es un movimiento habitual, y es justo decir que sorprendió a más de uno. Los resultados fueron los que zanjaron la cuestión.
Ambas cosas. Mi propia experiencia fue específica de mi caso, pero el problema de fondo, que un brief pierde información cada vez que cambia de manos, no es específico de mí en absoluto. Es la misma razón por la que Thabrew Effect está construido en torno a un único responsable que sostiene juntos la estrategia, el diseño, la construcción y el crecimiento.
No. La lección no es que todos deban programar. Es que, siempre que una decisión tiene que cruzar un traspaso, algo corre el riesgo de perderse, y la solución es eliminar ese traspaso o asegurarse de que el razonamiento viaje con él de forma deliberada. Para mí, eliminarlo fue la decisión correcta. No será la decisión correcta para todos.