Un CEO pregunta "¿podemos lanzar esto en marzo?" El CTO dice que sí. En marzo, no está lanzado. Ninguno de los dos mintió.
El CEO escuchó: ¿podrán los clientes usar esto en marzo? El CTO respondió: ¿estará el trabajo de ingeniería terminado en marzo? Entre esas dos frases están QA, la revisión de la tienda, una migración, un equipo de soporte que necesita capacitación, y una aprobación legal que nadie posee. Todos eran honestos. La fecha seguía siendo incorrecta.
He estado en ambos lados de esta mesa — dirijí una startup antes de liderar equipos de ingeniería — y es, más que cualquier problema técnico, lo que silenciosamente destruye los roadmaps.
Las cuatro frases que causan más daño
- "Casi listo." Para un ingeniero: la parte difícil está resuelta. Para un ejecutivo: el trabajo está casi terminado. El 10% restante de la parte difícil suele ser el 50% del calendario.
- "Solo un pequeño cambio." Pequeño en la interfaz no es pequeño en el sistema. Cambiar un campo de divisa es una tarde o un trimestre, y nada en la solicitud revela cuál.
- "Es deuda técnica." Escuchado como: los ingenieros quieren ordenar. Realmente significa: una decisión tomada bajo presión de tiempo ahora está cobrando intereses, y el pago está llegando, esté o no programado.
- "Necesitamos refactoring." Casi siempre un síntoma, no una solicitud. Pregunta qué lo hará posible. Si la respuesta no es un resultado de negocio, es una preferencia. Si es, es un elemento del roadmap que has estado mal valorando.
Por qué persiste
Porque ambas personas están siendo racionales. El CTO da una estimación técnica porque es la parte que controla y puede defender. El CEO pide una fecha porque es lo que la junta, el cliente y la campaña necesitan.
Ninguno está equivocado. Pero nadie en la sala es responsable del espacio entre los dos — y ese espacio es donde muere cada plazo.
Cuatro soluciones que realmente funcionan
Pregunta por la fecha en que algo llega al usuario
No "¿cuándo está listo?" sino ¿Cuándo puede un cliente real hacer la cosa? Este único replanteamiento superficializa cada dependencia oculta — revisión, migración, capacitación, firma legal — porque todas se encuentran entre código completo y listo para el cliente.
Haz que el CTO diga qué está asumiendo
Cada estimación descansa en suposiciones: que una API funciona, que terceros responden, que nadie se dedica a algo urgente. Escritas, se convierten en riesgos que puedes gestionar. Sin escribir, se convierten en excusas en abril.
Traduce el trabajo técnico en una frase de negocio
No "necesitamos migrar la base de datos." En cambio: "si no migramos para Q3, el onboarding de un cliente con más de 10.000 asientos tardará tres semanas en lugar de un día." Ahora el CEO puede priorizarlo contra todo lo demás, que es su verdadero trabajo.
Separa las tres preguntas que realmente estás haciendo
- ¿Podemos construir esto? — casi siempre sí.
- ¿Qué dejaríamos de hacer para construirlo? — la pregunta que la gente salta, y la única que revela el costo real.
- ¿Qué pasa si nos equivocamos en la fecha? — determina si necesitas una ventana fija o una flexible.
La señal de que tienes este problema
Estimaciones que siempre son aproximadamente correctas a nivel de tarea y siempre incorrectas a nivel de lanzamiento. Ese patrón significa que tus ingenieros están estimando bien y algo entre la ingeniería y el cliente no está contado.
Casi nunca es un caso de gente trabajando demasiado lentamente. Es un caso de dos personas describiendo diferentes líneas de meta y asumiendo que son la misma.
Si no tienes a alguien haciendo la traducción
Algunas empresas tienen esta persona naturalmente — un fundador técnico que ha manejado un P&L, un VP que surgió de ingeniería y se mantuvo cercano al negocio. La mayoría no, e contrata para llenar la brecha sin reconocerla.
Ahí es donde entro normalmente. No para escribir código que un buen equipo podría escribir, sino para sentarme en el espacio entre las dos respuestas y asegurarme de que sean sobre la misma línea de meta. La decisión sobre si contratar para eso permanentemente es su propia pregunta.