Del código al contexto: cómo leer una reunión de negocio siendo técnico
Un Tech Lead entra a una reunión de roadmap con tres directores de negocio. Lleva su propuesta preparada: migrar el sistema de facturación antes de Q3, con datos de latencia, deuda técnica cuantificada, un plan de tres fases. La expone bien. Las preguntas que recibe son razonables. Nadie levanta la voz. Al final, el VP de Producto dice "muy interesante, lo revisamos con calma" y pasa al siguiente punto de la agenda.
Sale de la sala convencido de que fue bien. Dos semanas después, la migración no está en el roadmap y el presupuesto se asignó a otra iniciativa que ni siquiera se discutió en esa reunión.
¿Qué falló? El contenido de su propuesta era correcto. Los datos eran reales. La lógica era impecable. Y perdió.
Dos formas de entender qué pasó en esa sala
La primera lectura es la que casi todo técnico hace: perdió por un problema de contenido. Le faltó un dato, un argumento, una cifra que cerrara el caso. La solución, bajo esta lectura, es preparar mejor la próxima. Más benchmarks. Un ROI más ajustado. Una comparativa con la competencia. Si el argumento gana en el papel, gana en la sala.
La segunda lectura es incómoda para quien viene de la ingeniería: la decisión no se tomó por el contenido. Se tomó por señales que circularon en la sala y que él no leyó, porque estaba mirando sus slides en lugar de mirar a las personas.
Ambas lecturas son plausibles. Y elegir la equivocada tiene costo: si el problema era de contenido y lo tratas como de lectura, te vuelves paranoico interpretando gestos que no significan nada. Si el problema era de lectura y lo tratas como de contenido, preparas la próxima reunión aún mejor y vuelves a perder exactamente igual.
Necesitamos saber cuál de las dos operó. Y para eso hay que reconstruir la reunión como lo que realmente era.
Una reunión es un sistema donde la información está repartida
Empecemos por una pregunta que parece obvia pero no lo es: ¿dónde estaba la información que necesitaba nuestro protagonista para tomar la decisión correcta sobre cómo presentar?
Él asumió que estaba en su propuesta. Que si construía el caso técnico completo, la sala convergería hacia la conclusión correcta. Esa asunción tiene un problema: da por hecho que él tenía toda la información relevante para ganar la reunión. No la tenía. Ni podía tenerla.
La información que decidía el resultado estaba distribuida entre las tres personas al otro lado de la mesa. El VP de Producto sabía que su bono de fin de año dependía de lanzar una funcionalidad que la migración retrasaría. La directora de Operaciones había tenido una mala experiencia con la última migración grande y arrastraba desconfianza. El tercer director, callado casi toda la reunión, era quien realmente controlaba el presupuesto. Nada de eso estaba en la agenda. Nada de eso se dijo en voz alta.
Andrew Grove distingue en High Output Management dos tipos de reunión: la orientada a proceso, donde se comparte información de forma rutinaria, y la orientada a misión, donde se toma una decisión concreta. Nuestro protagonista creyó que estaba en la primera —exponer, informar, recibir feedback— cuando en realidad estaba en la segunda. Se estaba tomando una decisión. Y las decisiones en una sala de negocio no se toman con la información que está sobre la mesa, sino con la que cada persona trae debajo del brazo.
Aquí está el primer giro: si el conocimiento que decide el resultado está repartido entre las personas y no en tu documento, entonces tu trabajo en la sala no es transmitir tu información. Es leer la de ellos.
¿Y cómo se lee información que nadie dice en voz alta?
Si la información crítica no se verbaliza, tiene que salir por algún otro canal. Porque las personas no dejan de comunicar cuando dejan de hablar. Comunican con el cuerpo, con la cara, con lo que hacen mientras otro habla.
Cuando el VP dijo "muy interesante, lo revisamos con calma", el contenido verbal era neutro, incluso positivo. Pero fíjate en lo que probablemente acompañó esa frase: una mirada breve al director del presupuesto antes de hablar, un cambio de postura hacia atrás en la silla, el gesto de recoger sus papeles medio segundo antes de terminar la frase. Ninguna de esas señales está en la transcripción. Todas dicen lo mismo: esto ya está decidido, y no a tu favor.
Joe Navarro, que pasó décadas leyendo lenguaje corporal en el FBI, lo describe en What Every Body Is Saying: el cuerpo filtra el estrés y la disconformidad mucho antes de que la persona los ponga en palabras —si es que llega a ponerlos. Los pies que apuntan hacia la puerta, las manos que se retiran de la mesa, el bloqueo momentáneo de los labios. Son señales de que algo no encaja, aunque la boca diga que todo va bien.
Y las microexpresiones —esos gestos faciales de menos de un segundo que Paul Ekman documenta en Emotions Revealed— son todavía más difíciles de fingir. Un destello de desprecio en la comisura de los labios cuando mencionas el plazo. Una tensión fugaz alrededor de los ojos cuando aparece la palabra "presupuesto". Duran lo que dura un parpadeo y contradicen frontalmente lo que la persona está diciendo.
Nuestro protagonista no vio nada de esto. No porque fuera incapaz. Porque estaba mirando la pantalla.
La objeción real casi nunca es la que se pronuncia
Supongamos que sí levanta la vista. Que ve el gesto del VP, la retirada de la directora de Operaciones. ¿Y ahora qué? Ver la señal no es lo mismo que saber qué hacer con ella.
Aquí entra una segunda capa. En SPIN Selling, Neil Rackham demuestra con datos que las objeciones que un cliente verbaliza rara vez son las que de verdad bloquean la decisión. La objeción dicha es socialmente aceptable —"necesitamos revisar el presupuesto"—. La objeción real suele ser otra —"no confío en que este equipo termine la migración sin romper producción como la última vez"—. Nadie dice la segunda en una sala con cinco personas. Pero la segunda es la que decide.
La técnica de Rackham no es adivinar la objeción real. Es hacer preguntas que la saquen a la superficie. En lugar de defender la propuesta con más datos cuando percibes resistencia, preguntas: "¿Qué tendría que ser cierto para que esta migración os diera tranquilidad en vez de preocupación?" Esa pregunta hace algo que ningún benchmark hace: mueve el conocimiento que está en la cabeza de ellos hacia la mesa, donde por fin puedes trabajarlo.
Daniel Pink, en To Sell Is Human, lo enmarca con precisión: vender —y convencer a un comité de negocio es vender— dejó de ser transmitir información al comprador. El comprador tiene toda la información que necesita. Lo que no tiene resuelto es su propia ambivalencia. Tu trabajo es ayudarle a resolverla, y para eso primero tienes que verla.
¿Ves cómo se conecta con lo anterior? Las señales no verbales te dicen dónde hay resistencia. Las preguntas SPIN te dicen qué la causa. Una sin la otra no sirve: leer el gesto sin preguntar te deja adivinando, y preguntar sin haber leído el gesto te deja preguntando lo que no importa.
El marco de status que decide antes de que hables
Falta una pieza. Oren Klaff, en Pitch Anything, aporta el elemento que explica por qué el tercer director —el del presupuesto, el que apenas habló— era quien más pesaba.
Klaff observa que toda sala tiene un marco de status, y que la persona con el status dominante decide antes de escuchar los argumentos. Nuestro protagonista dedicó toda su energía a las preguntas del VP, que hablaba mucho, y ninguna al director callado, que decidía. Leyó mal quién tenía el poder porque confundió volumen con autoridad.
El poder informal en una reunión no coincide con el organigrama ni con quién habla más. Se lee en a quién miran los demás antes de responder. En quién puede interrumpir sin pedir permiso y a quién nadie interrumpe. En hacia quién se orientan los cuerpos cuando surge la pregunta difícil. Esa información —dónde está el poder real— no aparece en ningún documento de la empresa. Solo aparece en la sala, y solo si la estás mirando.
Ahora la cadena está completa. El conocimiento que decidía la reunión estaba repartido entre tres personas. Salía por canales no verbales. La objeción real no era la pronunciada. Y el poder no estaba donde el organigrama decía. Cuatro capas de información que no estaban en la propuesta, y que ningún dato adicional habría suplido.
Perdió porque operó con información parcial del sistema, creyendo que la tenía completa.
Lo que esto generaliza más allá de una reunión de roadmap
El principio se extiende a cualquier sala donde un técnico intente que una decisión vaya en cierta dirección: la reunión no es un canal para transmitir tu información, es un sistema para extraer la de los demás. El técnico que llega a convencer con datos trata la sala como un compilador —entra código correcto, sale decisión correcta—. La sala no funciona así. Funciona como un sistema donde cada persona tiene una parte del conocimiento que decide el resultado, y casi nadie lo dice en voz alta.
Tu ventaja como Tech Lead no está en tener el mejor argumento. Eso lo puedes preparar en tu escritorio. Está en leer, en tiempo real, la información que las otras personas no están poniendo en palabras: dónde está la resistencia, qué la causa de verdad, y quién decide. Esa lectura no la sustituye ninguna cantidad de preparación previa, porque esa información no existe hasta que las personas están en la sala.
La próxima reunión de negocio, cierra el portátil durante la parte que importa. No para prestar más atención a lo que se dice. Para empezar a ver todo lo que no se dice y decide igual.
Cada semana analizo un problema real de liderazgo técnico. Con el mismo nivel de profundidad.