Imagina la escena. Entras a una reunión con tu equipo técnico y dices algo perfectamente razonable: “Necesitamos que cuando el cliente llegue al pago, si ya tiene cuenta, le aparezca su dirección guardada automáticamente”. Todo el mundo asiente. Parece sencillo.
Tres semanas después, el desarrollo sigue sin estar listo, el presupuesto se ha disparado y tu desarrollador te explica que había que refactorizar el módulo de autenticación, migrar la lógica de sesiones y además aprovechar para unificar los endpoints de usuario.
Tú no pediste nada de eso. Pero de alguna forma, eso es lo que se construyó. No es que tengas un problema de incompetencia, más bien es un problema de idioma.
Es el coste de no entenderse
Tú hablas en objetivos de negocio: reducir fricción, aumentar conversión, retener al cliente. Tu equipo técnico escucha en términos de sistemas, dependencias y arquitectura. Cuando describes lo que necesitas, ellos lo traducen a través de su propio filtro. El resultado es que parece que jugáis al teléfono roto y tu necesidad real se pierde entre sprints, tareas de Jira y decisiones técnicas que nadie te explicó que ibas a pagar.
Cuando no existe nadie en medio traduciendo, la inercia natural del equipo técnico es sobrediseñar. Un buen desarrollador siempre ve oportunidades de mejora en cada petición, y sin un límite claro sobre qué es prioritario para la empresa en ese momento, acabarán haciendo más de lo que pediste. Es dinero que se pierde en un trabajo que realmente no se necesitaba.
Por tu parte, la falta de contexto hace que subestimes el esfuerzo. Lo que para ti es “un simple botón”, a nivel de código puede implicar alterar tres capas del sistema. Al no haber nadie que te explique el porqué real de los plazos y los costes, acabas sintiéndote engañado y frustrado aunque los números sean justos. Todo esto genera una tensión en la cual el equipo siente que no entiendes la complejidad técnica y tú sientes que ellos no escuchan ni entregan. Y esa tensión, al fin y al cabo, es dinero perdido.
Te falta un buen cortafuegos
La figura que resuelve esto no es un gestor de proyectos con un Excel interminable. Es alguien que entiende de negocio y de sistemas a la vez. Alguien que se sienta contigo, escucha lo que necesitas en términos de facturación, y luego es capaz de bajarlo a tierra en términos técnicos, marcando límites claros sobre qué es lo que realmente se necesita construir y qué no. Alguien que sepa decir “esto no es necesario ahora” o “esto es un lujo que no nos podemos permitir” sin que el equipo técnico lo tome como una crítica a su trabajo, sino como una decisión estratégica.
Un Director Técnico o un CTO no es el desarrollador más rápido del equipo. Es el que sabe cuándo parar, qué no construir y cómo convertir un objetivo de negocio en una solución técnica que no reviente el presupuesto.
Sin esa figura, cada reunión con tu equipo es una apuesta. Puede que salga bien. Puede que no. Pero en ambos casos, el coste de la ambigüedad lo pagas tú. Las empresas que crecen sin fricción tecnológica no es que tengan equipos más listos. Tienen a alguien que traduce.