ENSAYO

Lo que sobrevive cuando lo cuentan sin ti

Hace unos meses perdí una sala y me tomó tiempo entender por qué.

La reunión iba bien. Estaba explicando la arquitectura de una empresa que ayudo a dirigir, y la estaba explicando con precisión. Actuación piezoeléctrica. Un barrido espiral resonante. Cuatro módulos de software con su ruta regulatoria trazada. Cada frase era cierta y cada frase cargaba peso. A los once minutos vi que un inversionista muy inteligente dejaba de tomar notas, y seguí hablando igual, que es la parte de la que menos me enorgullezco.

Después hice lo que hace casi todo operador: culpar un poco a la audiencia. Luego mi propio equipo me dijo que tampoco terminaba de entenderlo, y esa excusa dejó de servir. Son personas con todos los incentivos para entenderlo y que se sientan a tres metros de la ingeniería. Si ellos estaban confundidos, el problema estaba antes del oyente.

Esto es lo que estaba haciendo mal. Explicaba el mecanismo cuando debía explicar la consecuencia. Desde adentro parecen el mismo acto. Desde afuera no se parecen en nada.

La frase que lo resolvió

La empresa construye una sonda de imagen muy pequeña que mira hacia adelante dentro de un vaso sanguíneo. Los dispositivos existentes miran de lado. Esa distinción es todo el logro técnico, y yo venía tratando de transmitirla a través de la física de cómo se logra.

La imagen actual mira de lado, que es manejar solo con los espejos laterales. Nuestra sonda es un faro. Una vez que hay faros, un sistema de navegación se vuelve posible. El software es el sistema de navegación.

Eso es todo. Sin actuador, sin geometría de barrido, sin vocabulario regulatorio. Y la reacción fue distinta de un modo que no anticipé. La gente dejó de preguntarme qué era el software y empezó a preguntar qué haría. La analogía no solo había explicado el producto. Lo había vuelto inevitable.

Ese último efecto es el que vale la pena entender, porque no es lo que hacen la mayoría de las analogías.

Simplificar no es comprimir

El consejo habitual es simplificar. Creo que ese consejo está equivocado, o al menos gravemente incompleto. Simplificar es quitar contenido hasta que lo que queda sea fácil. Comprimir es encontrar un recipiente más pequeño que contenga todo el contenido. Uno pierde el argumento. El otro lo conserva.

La frase del faro no es una simplificación. Carga el reclamo competitivo, que nadie más puede ver hacia adelante. Carga el reclamo arquitectónico, que el software depende del hardware. Y carga el reclamo de secuencia, que el hardware tiene que ir primero, que es el que determina a dónde va el dinero. Tres argumentos en veintiocho palabras. No se descartó nada. Se plegó.

De ahí sale una prueba. Una simplificación se rompe cuando la empujas, porque el contenido que quitaste es justamente el que necesitas para responder la repregunta. Una compresión se extiende, porque el contenido sigue ahí adentro.

Cuatro pruebas para una analogía que carga peso

Empecé a aplicarlas antes de usar una en una sala que importa.

¿Se extiende sin romperse? La versión del faro llegó más lejos de lo que yo pretendía. Los cuatro módulos de software terminaron calzando con las cuatro cosas que hace un sistema de navegación. Uno identifica qué bloquea el camino, porque un derrumbe y una inundación piden respuestas distintas. Otro lee si la vía va a soportar tráfico una vez despejada. Otro pone todas las capas en un solo mapa en lugar de cuatro pantallas. Otro entrega todo eso indicación por indicación mientras manejas. Yo no diseñé ese calce. Lo encontré, que suele ser la señal de que una analogía es estructural y no decorativa.

¿Carga la parte difícil? Una analogía débil explica la mitad fácil y te abandona en la objeción. La pregunta más dura que recibimos es qué impide que un incumbente grande haga esto el año que viene. Dentro de la misma metáfora la respuesta ya está ahí. Los sistemas de navegación mejoran porque una flota de vehículos les alimenta datos del camino, y los kilómetros ajenos no se descargan.

¿Te limita con honestidad? Esta es la que la gente se salta. Una buena analogía debería hacerte visibles tus propias exageraciones antes de que se las haga visibles a un especialista. La nuestra lo hizo. Un sistema de navegación no maneja el auto, y en el momento en que dije eso en voz alta entendí algo sobre cómo había que posicionar el producto que llevaba meses buscando a tientas.

¿Sobrevive cuando la repiten? Esta es la prueba real y casi nadie la aplica. Rara vez estás hablando con quien decide. Estás hablando con la persona que tendrá que reconstruir tu argumento, de memoria, frente a gente que no estuvo en la sala. Cuatro nombres técnicos no sobreviven ese viaje. Un sistema de navegación sí.

El modo de falla

Las analogías son peligrosas de una manera muy específica, y yo caí de lleno en ella.

Una vez que el encuadre del faro funcionó, construimos una imagen alrededor. La primera versión traía un pie de foto que prometía que la tecnología revela todos los obstáculos y curvas y entrega un mapeo integral en tiempo real. Ambas frases son falsas para nuestro dispositivo de un modo que un especialista detectaría en dos segundos. La analogía había hecho lo que toda buena metáfora intenta hacer, que es completarse sola. Los sistemas de navegación reales sí mapean de forma integral. El nuestro hace algo más angosto y más específico.

La analogía tiene permiso para explicar el producto. Nunca tiene permiso para describirlo. En el momento en que empieza a generar afirmaciones en vez de transmitirlas, hay que frenarla.

Reescribimos el pie de foto. La versión angosta sigue siendo una muy buena historia, y ahora además es cierta. Esa secuencia, exagerar y luego corregir, conviene esperarla más que avergonzarse de ella. Una metáfora lo bastante fuerte para ser útil es lo bastante fuerte para adelantarse a los hechos, y la disciplina consiste en alcanzarla antes de que lo haga un cliente.

Por qué esto se generaliza

Al comienzo de mi carrera escribí software en un equipo de investigación hospitalaria, y el trabajo consistía en tomar un instrumento en papel que los clínicos ya entendían y reconstruirlo para una computadora. Yo era la persona menos experta en cada una de esas salas. Después pasé casi una década en Microsoft explicando tecnología en cincuenta y cuatro países, ante audiencias que no compartían ni mi vocabulario ni buena parte de mi contexto. Esos fueron los años en que debí aprender bien esta lección.

Lo que sí aprendí entonces, y luego olvidé, es que la explicación no es una envoltura alrededor del producto. En cualquier negocio donde el comprador no puede evaluar la tecnología por sí mismo, la explicación es parte del producto. Algo que no puede repetirse con precisión es algo que se va a repetir sin ella, y uno no elige cuál versión viaja.

La misma experticia que te permite construir algo es la que te vuelve malo para describirlo. Pierdes acceso a lo que se siente no saber. Eso no es un defecto de carácter y no se resuelve pensando más, y por eso hace falta una prueba y no una intuición.

La prueba que uso ahora

Es lo bastante simple para aplicarla en el momento. No: ¿me entendieron? Esa pregunta nos halaga a los dos y es fácil de aprobar. La mejor pregunta es si podrían explicárselo a otra persona mañana, sin mí en la sala, y no equivocarse.

La mayoría de las veces la respuesta honesta es no. Eso no es un problema de comunicación. Significa que todavía no terminé de pensar.