Cómo comunicar hacia arriba cuando las noticias son malas
Un Tech Lead descubre un lunes por la mañana que el proyecto que su equipo lleva construyendo tres meses no va a llegar a la fecha comprometida. No por un imprevisto trivial. Por una decisión de arquitectura que tomaron temprano y que ahora, con la carga real de datos, no aguanta. Refactorizar significa seis semanas más. La demo con el cliente final está en dos.
Tiene una reunión con su manager en cuarenta minutos.
Y una decisión que tomar antes: cómo contar esto.
Dos formas de entrar a esa reunión, ambas defendibles
La primera es la honesta por defecto. Entrar, poner todos los datos sobre la mesa, explicar la decisión de arquitectura, por qué parecía correcta entonces, por qué falla ahora, y cuántas semanas cuesta arreglarla. Transparencia total. Que el manager tenga la misma información que tú y decida con criterio completo.
La segunda es la que muchos ingenieros senior aprenden por las malas. Entrar con el problema ya enmarcado: aquí está la situación, aquí están las dos opciones que veo, aquí está la que recomiendo y por qué. No ocultas nada, pero no vuelcas el problema crudo. Lo entregas procesado.
Las dos parecen razonables. Y elegir mal tiene costo.
La primera opción, la transparencia total, es la que dicta el instinto del buen ingeniero: los datos hablan por sí solos. El problema es que asume que tu manager procesa la información igual que tú. La segunda parece manipuladora — como si estuvieras controlando lo que la otra persona ve. Pero también parece más profesional.
¿Cuál elige el Tech Lead? Antes de responder, hay una pregunta anterior que casi nadie se hace.
Qué escucha tu manager cuando hablas
Empecemos por lo que parece obvio y no lo es: ¿qué información necesita tu manager?
La respuesta instintiva es "toda". Pero fíjate en una asimetría que cambia todo el problema. Tú tienes el contexto técnico completo y responsabilidad limitada sobre el resultado de negocio. Tu manager tiene contexto técnico parcial y responsabilidad total sobre ese resultado. Vas a comunicar entre dos personas que ni saben lo mismo ni cargan con lo mismo.
Cuando explicas la decisión de arquitectura que falló, tú oyes una explicación técnica. Tu manager oye otra cosa. Oye: ¿esto se puede arreglar? ¿cuánto me va a costar? ¿este ingeniero tiene esto bajo control o me lo está trasladando para que lo resuelva yo? ¿qué le digo yo al cliente, o a mi propio jefe, en dos horas?
Tu manager no procesa la arquitectura. Procesa el riesgo. Procesa la confianza.
Andrew Grove observó en High Output Management que la información más útil para un manager llega por intercambios verbales rápidos, y que cuanto más a tiempo llega, más vale. Pero el valor no está solo en la velocidad. Está en que el intercambio verbal permite algo que el informe escrito no: leer cómo aterriza la noticia mientras la das, y ajustar.
Entonces la primera pregunta no era "qué información necesita". Era otra.
La pregunta real: qué modelo mental estás construyendo
Cuando tu manager sale de esa reunión, sale con una imagen del estado del proyecto en la cabeza. Esa imagen es la que va a usar para decidir, para tranquilizar o alarmar a los de arriba, para calibrar cuánto confía en ti la próxima vez.
Tu trabajo en esa reunión no es transferir datos. Es construir esa imagen con precisión.
Y aquí la transparencia total falla, aunque parezca contraintuitivo. Si vuelcas el problema crudo — "la arquitectura no aguanta, no llegamos, no sé exactamente qué hacer" — la imagen que construyes en la cabeza de tu manager es la de alguien que perdió el control. No porque lo hayas perdido. Porque le entregaste el problema sin procesar, y él lo procesa con la única lente que tiene disponible: el riesgo sobre el resultado del que responde.
Camille Fournier lo dice sin rodeos en The Manager's Path: el manager que solo hace de correa de transmisión entre el equipo y la dirección — relaya el problema hacia arriba y la respuesta hacia abajo — no añade valor. Tú, comunicando hacia arriba, tienes el mismo riesgo invertido. Si relayas el problema crudo, estás pidiéndole a tu manager que haga el trabajo de procesamiento que era tuyo.
¿Significa esto ocultar información? No. Mira la diferencia con cuidado, porque es sutil.
Procesar no es filtrar
Filtrar es decidir qué partes de la verdad ve la otra persona. Procesar es entregar la verdad completa en un formato que la otra persona pueda usar para decidir.
El Tech Lead que entra con "aquí está la situación, aquí están las dos rutas viables, aquí la que recomiendo y el porqué" no está escondiendo nada. La decisión de arquitectura fallida sigue ahí, sobre la mesa. Las seis semanas siguen ahí. Lo que cambió es que la información llega ya conectada a lo que el manager necesita para actuar: opciones y una recomendación.
Chris Voss, en Never Split the Difference, insiste en algo que parece de negociación de rehenes pero aplica exacto aquí: antes de proponer, nombra el peor escenario en voz alta tú mismo. "Sé que esto pone en riesgo la demo del cliente." Cuando eres tú quien nombra el miedo del otro, dos cosas pasan. Le quitas a tu manager el trabajo de tener que sacarlo él — que es el momento donde la conversación se vuelve tensa. Además, demuestras que ves el problema desde su asiento, no solo desde el tuyo.
Eso es lo que construye confianza. No la ausencia de malas noticias. La demostración de que entiendes qué está en juego para quien te escucha.
Los autores de Crucial Conversations lo llaman crear seguridad antes de entregar contenido difícil. La seguridad, en la comunicación ascendente, se crea de una forma específica: dejando claro desde la primera frase que tú y tu manager están del mismo lado del problema, no en lados opuestos. "Tenemos un problema con la fecha y traigo dos maneras de resolverlo" hace eso. "La arquitectura falló" no lo hace — te pone a ti como fuente del problema y a él como juez.
El orden de las frases decide la reunión
Queda una pregunta táctica: ¿en qué orden sale todo esto?
El instinto del ingeniero es cronológico. Primero el contexto, luego cómo llegamos aquí, luego el problema, al final la propuesta. Es como escribes un post-mortem. Es exactamente el orden equivocado para hablar hacia arriba.
Porque durante todo el tiempo que dedicas al contexto, tu manager no está escuchando el contexto. Está esperando a saber cómo de grave es y qué le vas a pedir. Su ansiedad crece con cada frase de preámbulo. Cuando por fin llegas a la propuesta, ya construyó su propia imagen del desastre y estás peleando contra ella.
Inviértelo. Titular primero: qué pasa, qué impacto, qué propones. Después el detalle, para quien lo pida. En Pitch Anything, Oren Klaff describe cómo la parte del cerebro que recibe primero cualquier mensaje no es la analítica — es la que evalúa amenaza. Si esa parte no recibe rápido la señal de "esto está bajo control y hay un plan", bloquea todo lo que venga después. Diste los datos perfectos a un interlocutor que ya dejó de procesarlos.
El titular primero no es simplificar. Es reconocer que la persona que te escucha necesita el marco antes que los datos, porque sin marco los datos solo alimentan la alarma.
Lo que generaliza más allá de esta reunión
Este caso trata de una fecha que no se cumple, pero el principio se extiende a toda comunicación donde tú tienes más contexto técnico y la otra persona más responsabilidad sobre el resultado: presentar a dirección, negociar un plazo con producto, reportar un incidente a alguien que no toca código.
En todas ellas, tu trabajo no es transmitir lo que sabes. Es construir, con precisión y sin mentir, el modelo mental que la otra persona usará para decidir. Esa persona no procesa tu información con tu lente. La procesa con la suya — la del riesgo que carga y la confianza que necesita para dormir. Comunicar bien hacia arriba es entregar la verdad completa traducida a esa lente.
La transparencia que no considera cómo aterriza no es transparencia. Es descargar tu ansiedad sobre alguien que tiene menos herramientas que tú para procesarla, y llamarlo honestidad.
Empieza esta semana por lo más pequeño: la próxima vez que tengas que dar una mala noticia hacia arriba, escribe la primera frase antes de entrar. Solo la primera. Si esa frase pone el problema como algo que resuelven juntos y no como algo que tú traes para que otro cargue, el resto de la conversación cambia de eje.
Para las cinco situaciones más difíciles de comunicación ascendente — el plazo que se cae, el incidente en producción, el error propio, la estimación que hay que revisar al alza, el desacuerdo con una decisión de dirección — preparé mensajes tipo con el orden de frases ya resuelto. Es el recurso descargable de esta semana para suscriptores.
Cada semana analizo un problema real de liderazgo técnico. Con el mismo nivel de profundidad.