"Why do we need three engineers on this for two quarters instead of shipping features?"
Es la pregunta que un VP de Producto te hace en la reunión trimestral cuando presentas el plan de migrar el sistema de provisioning de servicios. Tienes la respuesta técnica lista — el sistema actual no escala, cada servicio nuevo toma dos semanas en vez de dos clics — pero en el momento de decirlo en inglés, la explicación suena a excusa de ingeniería, no a una decisión de negocio. El stakeholder asiente, pero el presupuesto no se aprueba.
El error más común: explicar la arquitectura en vez del costo
Cuando un Tech Lead presenta una migración técnica a un stakeholder no técnico en inglés, el reflejo es explicar cómo funciona el sistema actual y por qué el nuevo es mejor — "the current system uses a monolithic provisioning script that doesn't scale horizontally." El stakeholder no tiene con qué evaluar esa frase. No sabe si "no escala horizontalmente" es grave o cosmético, así que lo trata como preferencia técnica, no como riesgo de negocio.
El segundo error es prometer una fecha de cierre sin mostrar el plan para llegar ahí — "we'll have this migrated by end of year" — sin decir qué pasa si algo sale mal en el camino. El stakeholder que ya vio una migración estancarse en el pasado no confía en la fecha; confía en el plan detrás de la fecha.
El framework en 4 pasos: Costo → Riesgo controlado → Adopción → Fecha de cierre
Paso 1: Nombra el costo de no migrar, no la arquitectura
Traduce el problema técnico a una cifra o un impacto que el stakeholder ya usa para tomar decisiones.
Di: "Every new service we provision on the current system takes two weeks — with the new one, it's two clicks. That's the gap we're closing."
No digas: "The current provisioning system is built on Puppet and doesn't support self-service."
El stakeholder no necesita saber qué es Puppet. Necesita saber que dos semanas se convierten en dos clics, y que esa diferencia se multiplica por cada servicio que el equipo provisiona ese trimestre.
Paso 2: Muestra que el riesgo ya se probó donde más podía fallar
Un stakeholder que aprueba una migración está apostando a que no lo vas a dejar a medio camino. Esa confianza se gana mostrando que el plan empezó por el caso más difícil, no por el más fácil.
Di: "We're piloting this with the team that has the messiest edge cases first — if it holds up for them, it holds up for everyone else."
No digas: "We'll roll it out gradually and see how it goes."
"See how it goes" no tiene información. "The team with the messiest edge cases" sí — comunica que ya se buscó el peor escenario a propósito, en vez de esperar a encontrarlo en producción.
Paso 3: Presenta la adopción como algo que el equipo puede hacer solo, no como trabajo tuyo
La parte de una migración que más le preocupa a un stakeholder no técnico es cuánto tiempo de su equipo se va a consumir en el cambio. La respuesta correcta no es "confía en nosotros" — es mostrar que el trabajo de adopción está reducido al mínimo.
Di: "Once the tool is ready, any engineer can migrate their own service in about fifteen minutes — no ticket, no waiting on our team."
No digas: "Teams will need to coordinate with us to migrate over the next few months."
La primera frase le dice al stakeholder que su equipo no va a perder velocidad esperando turno. La segunda le dice exactamente lo contrario, aunque el plan real sea el mismo.
Paso 4: Fija la fecha en que el sistema viejo deja de ser una opción
Una migración sin fecha de cierre nunca termina — sigue siendo "una de las dos formas de hacerlo" indefinidamente. El paso que de verdad mueve la aguja es anunciar cuándo el sistema anterior deja de estar disponible para trabajo nuevo.
Di: "Starting March 1st, every new service defaults to the new system — nothing new gets built on the old one after that."
No digas: "We're hoping most teams will have moved over by the end of the year."
"Starting March 1st" es una fecha que el stakeholder puede poner en su propio calendario y usar para presionar a otros equipos. "Hoping" no es un plan — es un deseo con fecha de vencimiento.
Ejemplos de diálogo real
Escenario: presentar el presupuesto de la migración en la reunión trimestral
"Every new service we provision on the current system takes two weeks — with the new one, it's two clicks. We're piloting this with the team that has the messiest edge cases first, so we know it holds up before anyone else touches it. Once it's validated, any engineer can migrate their own service in about fifteen minutes. Starting March 1st, every new service defaults to the new system."
Costo, riesgo controlado, adopción sin fricción, fecha de cierre — en ese orden, sin que el stakeholder tenga que preguntar por ninguno de los cuatro.
Escenario: el stakeholder pregunta por qué no se puede esperar hasta el próximo año
Stakeholder: "Can this wait until next year's roadmap?"
"Every quarter we wait, the gap gets more expensive to close — right now it's three weeks of extra engineering time per new service, and we're provisioning more of them each quarter, not fewer."
La pregunta de timing se responde con una cifra que crece, no con una defensa de por qué el proyecto es importante en abstracto.
Escenario: el stakeholder está preocupado por interrupciones en producción
Stakeholder: "What happens if this breaks something mid-migration?"
"The rollout is reversible at every step — teams can go back to the old system instantly if something doesn't work, and we're starting with the team best equipped to catch problems early, not the one most exposed if something goes wrong."
La preocupación por el riesgo se responde nombrando la reversibilidad, no asegurando que nada va a salir mal.
Qué practicar esta semana
Antes de tu próxima conversación sobre una migración pendiente, arma las cuatro frases con tu proyecto real:
- "Every [unidad de trabajo] on the current system costs [tiempo/dinero] — with the new one, it's [tiempo/dinero reducido]."
- "We're piloting this with [el caso más difícil] first, so we know it holds up before anyone else touches it."
- "Once it's ready, [rol] can [acción de adopción] in about [tiempo] — no [fricción que eliminaste]."
- "Starting [fecha], [comportamiento por defecto que cambia]."
Si puedes producir estas cuatro frases antes de la reunión, la migración deja de sonar a un proyecto de ingeniería que compite por presupuesto y empieza a sonar a una decisión de negocio con un plan detrás.