"Still on track for Friday, right?"
El mensaje llega por Slack, con el tono liviano de quien espera un "sí" rápido. Sabes que no lo es — dos de los tres bugs de la integración de pagos siguen abiertos y uno de ellos no tiene causa raíz clara todavía. Escribir "yeah, should be fine" compra veinticuatro horas de tranquilidad y las convierte en un problema más grande el viernes a las 5pm.
El error más común: suavizar hasta esconder la información, o ser tan directo que suena a acusación
Frente a una mala noticia en inglés, el Tech Lead cae en uno de dos extremos. El primero suaviza tanto el mensaje — "this might slip a tiny bit, nothing major" — que el stakeholder no entiende la gravedad real hasta que ya es tarde para replanificar. El segundo va directo a la conclusión más dura — "there's no way we're hitting Friday, this was rushed from day one" — y convierte una noticia técnica en una acusación que la otra persona tiene que defenderse, no procesar.
Ninguno de los dos deja al stakeholder en condiciones de tomar una decisión informada. El primero le quita los datos. El segundo le quita la calma para usarlos.
El framework en 4 pasos: Hechos → Conclusión tentativa → Pregunta → Plan
Paso 1: Comparte los hechos, sin conclusión todavía
Los hechos son lo menos discutible que tienes — empieza ahí, antes de decir qué crees que significan.
Di: "As of this morning, two of the three payment integration bugs are still open, and one doesn't have a clear root cause yet."
No digas: "We're probably not going to make Friday." — eso es una conclusión disfrazada de actualización, y llega antes de que el stakeholder tenga el contexto para entenderla.
Paso 2: Comparte tu conclusión, en tono tentativo pero específico
Una vez que los hechos están sobre la mesa, di lo que crees que significan — sin exagerar tu certeza ni esconderla.
Di: "Based on that, I don't think Friday is realistic — I could be wrong if the third bug turns out to be quick."
No digas: "There's no way we're hitting Friday, this was rushed from day one." Tampoco digas "this might slip a tiny bit." Un extremo insulta, el otro esconde la severidad detrás de la cortesía.
Paso 3: Pregunta lo que no sabes
Casi siempre falta información de tu lado — un constraint de negocio, una fecha que no es negociable por razones que no conoces.
Di: "Is there a hard constraint on Friday I'm not aware of, or is there room to move?"
No digas: nada — asumir que ya sabes todo el contexto es el error que convierte una mala noticia manejable en una sorpresa desagradable para ambos lados dos días después.
Paso 4: Cierra con un plan, no con una disculpa
La disculpa sin plan deja al stakeholder con la misma pregunta que tenía al principio: ¿y ahora qué?
Di: "Here's what I'd propose: we ship the core flow Friday and the edge-case fix Monday — does that work on your end?"
No digas: "I'm really sorry about this." Una disculpa sola no mueve la conversación hacia una decisión.
El orden de los cuatro pasos hace el trabajo pesado. Empezar por la conclusión — "we're not going to make it" — pone al stakeholder a la defensiva antes de que tenga los hechos para entender por qué. Empezar por los hechos deja que llegue a una versión de la misma conclusión por su cuenta, así que cuando la escucha de tu boca ya no lo toma por sorpresa.
Ejemplos de diálogo real
Escenario: fecha de lanzamiento en riesgo
Stakeholder: "Still on track for Friday, right?"
"As of this morning, two of the three payment integration bugs are still open, one without a clear root cause. Based on that, I don't think Friday is realistic. Is there a hard constraint on that date, or is there room to move? If there's room, I'd propose shipping the core flow Friday and the fix Monday."
Hechos primero, conclusión tentativa, pregunta genuina, plan concreto. Ninguna disculpa, ninguna acusación.
Escenario: el stakeholder responde con presión, no con información
Stakeholder: "This really needs to happen Friday, we already told the client."
"Understood — that's exactly the kind of constraint I was asking about. Given that, here's the option that gets us there: we ship without the edge-case handling and patch it Monday. That means a small risk window for that one flow — is that acceptable on your end, or does the client need the edge case covered too?"
Volver a preguntar en vez de ceder o defender mantiene la conversación en el trade-off real, no en quién tiene razón.
Escenario: la mala noticia es sobre calidad, no sobre fecha
"We shipped on time, but we found a data inconsistency affecting about 3% of transactions from the last two days. The fix is ready — it needs a migration that takes roughly two hours. I'd propose running it tonight during low traffic. Does that timing work, or is there a reporting cycle it would interfere with?"
Mismo orden, distinto contenido: hecho verificable, alcance específico (3%, dos días), plan con horario, pregunta que revela lo que todavía no sabes.
Qué practicar esta semana
Antes de tu próxima conversación difícil, arma las cuatro frases con la situación real:
- "As of [momento], [hecho verificable]."
- "Based on that, I don't think [conclusión] — I could be wrong if [condición]."
- "Is there [constraint] I'm not aware of, or is there room to [alternativa]?"
- "Here's what I'd propose: [plan concreto] — does that work?"
Si las cuatro frases te salen antes de escribir la primera respuesta en Slack, la mala noticia deja de sentirse como algo que hay que confesar y empieza a sentirse como información que el stakeholder necesita para decidir.