No intentes esquivar con ingeniería el trabajo de escuchar a la gente

• El principal obstáculo en el trabajo de software no es tanto la falta de conversación en sí, sino la falta de escucha; intentar resolverlo reformulándolo con expresiones como framework o system termina esquivando la escucha que realmente hace falta
• Hacer exactamente lo que alguien pide no es lo mismo que identificar lo que en verdad necesita, y el efecto de la experiencia junto con la dicotomía technical/non-technical hace que se pierdan el conocimiento y el contexto de la otra persona
• Si se asume que todo el mundo tiene la misma energía, las mismas habilidades y los mismos recursos económicos, o si se generaliza a todo un grupo a partir de las características de una sola persona, no se logra captar bien las restricciones ni los criterios de decisión que varían de persona a persona
• Las personas y las organizaciones cambian según el tiempo, el rol, el estrés y la dinámica de grupo, y lo que dicen no siempre coincide con lo que realmente piensan, por lo que los requisitos fijos fácilmente se desalinean con la creación de software
• Fallar al escuchar hace que se pierdan los insights más valiosos, y eso lleva a perder oportunidades de ingresos y ventaja competitiva, además de aumentar el tech debt por la acumulación de malentendidos

---

Argumento central

• En el trabajo de software, algo más importante que la ausencia de conversación entre personas es la falta de escucha, y el enfoque de intentar resolverlo cambiándolo por términos como framework o system es una forma de evitar el trabajo que realmente se necesita
• Diseñadores y responsables de producto intentan traducir las conversaciones con personas a expresiones que ingeniería pueda aceptar más fácilmente, pero más que un mejor sistema, lo que hace falta es escuchar de verdad lo que la gente dice
• Partiendo de la idea de que escuchar a la gente es más difícil que simplemente hablar con ella, se ordenan varias trampas típicas que en la práctica bloquean esa escucha

Trampas típicas que dificultan escuchar

• Hacer lo que te dicen no es lo mismo que escuchar

  • Hacer exactamente lo que alguien dice querer y escuchar lo que realmente necesita no son la misma cosa
  • Como enfoques previos relacionados con este tema, se mencionan Jobs To Be Done, Outcome Driven Innovation y el empathy mapping del ámbito UX

• El efecto de la experiencia hace subestimar la propia perspectiva

  • Cuando una persona lleva mucho tiempo aprendiendo un campo, le resulta fácil asumir que “esto cualquiera debería saberlo”
  • Aunque la otra persona también sea experta en su área, eso no significa que conozca lo mismo; en cambio, puede saber cosas distintas
  • Para escuchar bien, hace falta entender mejor qué sabe la otra persona

• Considerar technical como una sola categoría

  • Es una trampa especialmente común entre desarrolladores de software: technical no es una sola cualidad, sino un espectro amplio de áreas de conocimiento heterogéneas
  • Si se mira a las personas con la dicotomía “technical / non-technical”, se pierden insights y aumenta la probabilidad de no escuchar bien

• Asumir que todo el mundo tiene los mismos recursos

  • Pensar que todas las personas tienen la misma energía, las mismas habilidades y el mismo dinero disponible lleva a errores de juicio
  • Incluso personas con la misma salud pueden diferir en cómo la gestionan o en lo que realmente pueden hacer
  • Hay personas fuertes en matemáticas, otras con fortalezas distintas, y otras que actúan de forma más aversa al riesgo porque tienen menos dinero o menos margen

• Generalizar a todo un grupo a partir de una sola persona

  • Haber conocido a una persona con cierta característica no significa que las demás sean iguales
  • Se menciona como ejemplo la actitud de asumir que las personas mayores no entienden de computadoras
  • Reducir a todas las mujeres a la imagen de una relación familiar personal es el mismo error

• Asumir que las personas y las organizaciones son fijas

  • A nivel macro, la personalidad cambia con el tiempo
  • A nivel micro, la persona que alguien es en el trabajo puede ser distinta de la que es en casa, y su juicio también cambia bajo estrés o en ciertas condiciones

• Asumir que lo que se dice y lo que se piensa es lo mismo

  • Algunas personas quieren decir exactamente lo que dicen, pero otras no
  • Incluso cuando alguien cree que está hablando con honestidad, muchas veces en la práctica no es así

• Juzgar a las personas

  • Si odias o descartas a alguien que malinterpretó algo mal documentado, se reduce muchísimo la posibilidad de escucharle bien
  • También bloquea la escucha asumir que la otra persona hace mal su trabajo o está viviendo mal su vida

• Tratar a 80 personas como un solo grupo en vez de 80 seres humanos individuales

  • B2B tiene, incluso más que B2C, un lado profundamente humano, donde operan relaciones, dinámicas y elementos como el soft power fuera del organigrama
  • Al sumarse la dinámica grupal, aparecen variables aún más complejas que a nivel individual

El desajuste entre requisitos fijos y software

• Debido a que las personas y las organizaciones cambian, el fixed project management no encaja bien con la creación de software
• Aunque los requisitos se dejen cerrados al inicio, las personas cambian en el intermedio, y cuando el resultado aparece, como mucho coincide con lo que se pidió al arrancar
• Al momento del lanzamiento, puede que eso ya no sea lo que se quiere, y además, mientras esperan, las personas van agregando sus propias expectativas, por lo que la realidad no coincide con todas ellas

Resultados e impacto

• Cuando no se escucha bien a la gente, se pierden los insights más valiosos, y eso lleva a perder oportunidades de ingresos y ventaja competitiva
• Cuanto más se acumulan los malentendidos, más elementos nuevos se añaden al código con el que luego habrá que seguir trabajando, y escuchar también se relaciona con minimizar al menos parte de las causas del tech debt
• Cuanto más se logra detectar el momento en que no se está escuchando, mayor es la posibilidad de escuchar mejor

[GN⁺]

Opiniones de Hacker News

• Yo suelo elegir las palabras con bastante precisión, y si usé una expresión específica, de verdad quise decir eso. Pero mucha gente, al menos así lo veo yo, habla como si fuera un tone poem, rondando palabras aproximadas y esperando que se entienda una misma tonalidad general, así que el mero acto de interpretar ya me agota. Cuando escribo, elijo cada palabra intencionalmente, pero incluso en el trabajo casi siempre se repite que interpretan mis expresiones como si hubieran sido imprecisas, y eso me resulta bastante doloroso. Puede que tenga rasgos del espectro, aunque nunca me lo han diagnosticado. Hace como medio año hice un pequeño RPC y escribí documentación para que otro departamento pudiera arrancar una tarea larga; no llegaba ni a una página, pero era completa, exacta y concisa. Pero mi gerente, sin explicar por qué, pasó ese documento por una IA y lo retransmitió, y yo ni siquiera me enteré. En menos de un día empezaron a llegar comentarios absurdos, y cuando vi ejemplos reales de las solicitudes, habían manipulado el endpoint. No era un typo, era una dirección completamente inventada, y en la documentación estaban mal tanto el endpoint como todos los parámetros obligatorios, e incluso se habían inventado funciones que no existían. Normalmente soy una persona paciente, pero pocas veces me he enojado tanto como entonces, y todavía sigo furioso. Si el mercado laboral no estuviera como está, creo que habría renunciado de inmediato. Dejar en manos de una IA un lenguaje que la gente debería leer e interpretar por sí misma se siente como la muerte del lenguaje riguroso, y desde hace meses pienso en serio si la IA generativa será una especie de Great Filter que arruine la civilización

  • Esta perspectiva se me hace un poco extraña. No creo que el habla recorte con exactitud los límites del pensamiento; el lenguaje es una herramienta para expresar el mundo y la comprensión de cada quien, así que es natural explicar conceptos parecidos con palabras distintas. Puede parecer más claro para quien tradujo su pensamiento a palabras, pero no necesariamente para quien escucha. Por eso no creo que se pueda pasar por alto tan fácilmente el trabajo de interpretación. Probablemente, si hablaras con la otra parte en esa situación, ellos también terminarían diciendo algo parecido: que tus palabras eran difíciles de interpretar
  • La idea es tan potente que enseguida pensé en una novela. La conexión entre el Great Filter y la IA generativa está buenísima, y se siente como una historia que Cory Doctorow debería escribir ya mismo
  • Yo primero preguntaría por qué el gerente metió ese documento en una IA. A veces, mientras más precisión se busca, peor resulta la legibilidad, y mientras más comprimido está el lenguaje, más costo cognitivo le exige al lector cada palabra. Leer es traducir el modelo mental del autor al modelo del lector; no ocurre de forma automática solo con las palabras, hace falta un acto de interpretación. Si es demasiado conciso, pueden desaparecer los apoyos que ayudan al lector. También sospecho que ese desvío hacia un resumen con IA pudo pasar porque un documento de una página era demasiado corto para ayudar a un lector general a entenderlo. Escribir para el lector es un trabajo totalmente distinto a tomar notas precisas para alguien con el máximo contexto, y sobre todo cuando escribes para un público indeterminado, creo que hace falta ayudar a la comprensión con repeticiones, ejemplos fáciles, contexto familiar, pasos más desglosados, y a veces hasta humor y explicaciones de fondo
  • A mí me pasó algo parecido hace poco. Escribí una especificación de 4 páginas, pero quien la recibió no la leyó y en cambio le sacó con un LLM unos bullet summaries, y como resultado volvió una propuesta que no coincidía con los requisitos. Cuando me opuse, dijo que eso debería haber estado en la especificación original, pero sí estaba; simplemente no aparecía en su LLM summary. No soy del tipo que se obsesiona con cada palabra, pero siento que la información de un documento de 4 páginas no puede caber íntegra en 10 bullets
  • Más bien, esto me parece un caso perfecto para un prompt dedicado o un LLM personalizado que traduzca el texto a normie speak

• Solo con ver esta sección de comentarios me parece irónico que tanta gente esté reproduciendo exactamente el problema que señalaba el texto. Quiero agregar algunas cosas. Primero, por mucho conocimiento y discusión que se acumule, si la otra persona no quiere aceptar algo, no lo va a aceptar fácilmente. Segundo, escuchar de verdad implica ponerse en una situación vulnerable tanto mental como físicamente. Eso pasa porque uno termina oyendo cosas que chocan con la propia experiencia, creencias y visión del mundo, y como la actitud de juzgar a los demás suele funcionar como un mecanismo de autoprotección, justamente por eso a veces no se logra escuchar bien. Tercero, escuchar muchas veces consiste en no saltar de inmediato a una solución, sino en absorber y procesar el dolor de la otra persona. Por ejemplo, un Product manager puede tender a reducirlo enseguida a una nueva feature o a un ticket, cuando en realidad primero hay que escuchar el caso de uso, encontrar el punto de dolor y resolver eso; no basta con tratar de entender solo el nombre de la función que el usuario pidió

  • Me parece peligroso dar por sentado esa premisa desde el inicio. La mayoría de las cosas dejan margen para negociar, y creo que si uno sabe negociar bien, la situación puede cambiar
  • En especial el punto 2 me pareció muy profundo. De verdad quisiera enviarle esto a alguien importante para mí, con la esperanza de que también listen de verdad
  • Coincido con la idea de que escuchar vuelve vulnerable a una persona, aunque también pienso que, si existiera la garantía de que esa vulnerabilidad no será explotada cada vez, yo felizmente me tomaría el tiempo de escuchar bien siempre
  • De verdad tengo curiosidad: ¿qué significa en la práctica absorber el dolor ajeno, y cómo se pasa desde ahí de forma natural a definir una feature o redactar un ticket?
  • Esta explicación me parece justamente la esencia de presales discovery. Es un terreno que de verdad está más cerca del arte que de la técnica

• Estoy de acuerdo con la preocupación de fondo, pero esta lista me sonó un poco a desahogo. La comunicación efectiva es casi un problema central de toda la humanidad, y el texto tiene un tono como de regaño a los desarrolladores por no saber escuchar, así que me pareció un poco condescendiente. El problema de fondo es que la gente no sabe lo que no sabe. Los mejores comunicadores se parecen a traductores, y la gente recién escucha cuando el mensaje se vuelve evidente dentro de su propio marco de comprensión. No creo que sea simplemente un colapso causado porque todos actúan como niños tapándose los oídos. Por eso buscamos sistemas e ingeniería, e intentamos que esos sistemas incorporen detección de brechas y marcos de traducción. No será perfecto, pero me parece más importante cambiar el entorno a nivel de equipo, empresa y sistema que sermonear a cada individuo para que escuche mejor

  • Me acordé de que una vez un anciano me dijo que esto había que verlo como un Noisy system. La señal siempre es más débil que el ruido, y dentro de eso hay seres humanos con limitaciones. Cada quien tiene un techo en lo que puede hacer, también hay límites en la velocidad a la que una persona puede actualizar su modelo mental, y los límites de un grupo son todavía más bajos que los de un individuo. En especial las organizaciones grandes pueden tardar décadas en cambiar su modelo aunque la realidad ya haya cambiado por completo. Por eso me parece importante aceptar esas restricciones y luego decidir en qué voy a gastar mi tiempo y mi energía
  • A mí este texto me pareció simplemente un artículo común de self-help, e incluso por la falta de ejemplos me decepcionó un poco más que eso
  • Soy desarrollador y también he hecho bastantes otras cosas, así que conozco muy bien la importancia de la comunicación y lo seguido que los desarrolladores fallan ahí. Un patrón muy común es que los desarrolladores actúan como malos médicos: fingen escuchar, pero diagnostican demasiado pronto. Declaran que ya saben lo que hace falta antes de que la otra persona siquiera termine de explicar lo importante. En software, muchas veces lo que el cliente realmente necesita importa más que lo que dice querer. Son pocos los clientes que saben bien cuál es una forma elegante de resolver su problema con software; normalmente llega alguien con una idea, pero sin haber pensado a fondo en software. Eso no significa que su idea no valga nada, sino que el trabajo de definir requisitos y encontrar la solución todavía no ha terminado. Y la forma de completarlo es con observación, explicación y conversación. En mi experiencia, muchos desarrolladores no escuchan bien de verdad, y con médicos u otros trabajos técnicos pasa algo parecido. Quieren parecer competentes rápido, mostrando cuánto saben, y clasifican al otro como un caso más de los muchos que ya han visto. A veces funciona, pero inevitablemente llega el momento en que deja de funcionar
  • En tono de broma, si la comunicación de verdad fuera el problema central de la humanidad, uno pensaría que al menos habría algún versículo al respecto en la Bible

• Creo que no se debe asumir tan fácilmente que lo que la gente dice coincide con lo que realmente piensa. Y al revés, quien habla también tiende a creer por error que quien escucha está imaginando y entendiendo la misma cosa. Por eso es importante dejarlo por escrito de la forma más detallada y sin ambigüedades posible. Si en una reunión alguien intenta explicar un objetivo con un bullet de seis palabras, para mí eso es prácticamente una señal de que nadie entiende el objetivo. Si alguien llega a una reunión sin siquiera un documento de una página, es que todavía no lo entiende lo suficiente, y si mi avance depende de ese entregable, creo que tengo derecho a exigir una imagen más clara

  • A mis colegas a veces tengo que preguntarles about what? varias veces al día. Muchas veces tengo que repreguntar 4 o 5 veces hasta que especifican de qué cliente, qué función o qué producto están hablando. Y a veces tengo que hacerlo incluso cuando yo ya sé exactamente de qué están hablando
  • También siento que siempre hay que cuestionar si los requisitos son válidos. La forma más fácil de ocultar que no se sabe cuál es la necesidad real es pedir de más. En mi experiencia es común pedir diez veces más de lo necesario, y una vez hasta me dijeron que, para no preocuparse por el futuro, había que comprar la opción de gama alta aunque hubiera una diferencia de costo de 500 veces
  • Redactar de forma detallada y sin ambigüedades puede ser una condición previa para un entendimiento mutuo profundo, pero en estos últimos años siento que la gente ya casi no lee más allá de la primera oración de un mensaje, ticket o email. Así que muchas veces hay que darles la información en pedacitos diminutos, y eso me molesta bastante
  • Siento que esto pasa demasiado seguido en la vida real. Si digo que algo no está listo para producción, muchas veces la gerencia lo oye como si eso significara que se le puede vender al cliente como acceptance testing
  • De pronto me acordé de la película soviética Kin-dza-dza. Ahí un personaje dice de otro que dice lo que no piensa y piensa lo que no piensa, y me parece una frase bastante buena para describir la confusión de esta conversación

• Yo trabajo sobre todo en roles de manejo de relaciones con clientes, así que creo que lo más importante es alinear las expectativas del cliente con la realidad. Si haces coincidir sus expectativas con lo que es posible, cuánto va a tardar, cuánto cuesta y cuándo se puede subir a producción, entonces aunque no le gusten la fecha de inicio o el costo, al final terminas con un cliente satisfecho. En particular, el costo suele ser algo que mata tratos, así que prefiero alinear ese rango aproximado desde el principio. Por mucho que escuches y empatices, la realidad sigue siendo la realidad, y el cliente también tiene que reconocer o aceptar esas restricciones. El responsable de cliente que le da la razón en todo al cliente termina haciéndolo más infeliz; un buen interlocutor tiene que escuchar tanto al cliente como al equipo interno para que lo que realmente se puede entregar coincida con lo que el cliente espera

• Quizá estamos dedicando demasiado tiempo a la comunicación. Cuando se asigna tiempo de más, se pierde foco y se vuelve fácil dejar las cosas para después con la idea de que ya se aclararán la próxima vez. Creo que, si reducimos las reuniones innecesarias y asignamos solo el minimum viable time, todos escucharían mejor

  • Yo casi no he visto ese fenómeno en la práctica. La mayoría de las reuniones no son comunicación de verdad sino más bien instrucciones y avisos, y la capacidad de escuchar es una habilidad aparte que no depende de cuánto dure la reunión. Escuchar bien es una capacidad que se pule con práctica; no aparece automáticamente por recortar el tiempo de reunión
  • He estado en demasiadas reuniones cuyo resultado fue agendar otra reunión. Incluso he visto el patrón de meter a más gente, de que los equipos numerosos inclinen las decisiones a su favor para ganar peso político, y de que eso luego lleve a más contrataciones innecesarias y más reuniones. La salida no es aumentar la comunicación, sino establecer una visión única y reducir las dependencias entre equipos para que cada equipo pueda trabajar de forma independiente
  • Trabajando en arquitectura de software, muchas veces he visto que un solo diagrama ahorra más de 60 minutos de discusión y varias reuniones. Ni siquiera tenía que estar perfectamente dibujado; bastaba con que fuera fiel a los hechos, y para lógica compleja o no obvia, un diagram era mucho más claro que las palabras. Si la reunión es remota, con Ai agent y Mermaid.js se puede dibujar rápido; si es presencial, basta con una pizarra o con papel y pluma
  • Me parece que dedicar tiempo a la comunicación y comunicarse de verdad son dos cosas totalmente distintas
  • Yo diría que en realidad no gastamos demasiado tiempo comunicándonos, sino demasiado tiempo fingiendo que nos comunicamos. He visto muchísimas veces reuniones forzadas sin ni siquiera quórum, llevadas adelante sin prerrequisitos, donde avientan un AI slop document hecho sin pensar y, cuando la gente no lo entiende, encima la hacen pasar como si fuera tonta por no haberlo leído bien. Los primeros 30 minutos de la reunión se van casi como en un gaslighting, y solo en los últimos 10 se admite que todo fue una pérdida de tiempo e intentan recomponer. En teoría, una reunión debería servir para compartir ideas bien maduradas y una dirección coherente, y para recibir retroalimentación significativa sobre afirmaciones claras, pero en la práctica muchas veces es el grupo intentando procesar el intento de alguien de convertir su trabajo en un proyecto colectivo tipo stone soup. Si al principio preguntas cuál es el objetivo de la reunión, queda al descubierto si el organizador solo abrió una especie de grupo de estudio. Los gerentes con una visión muy alta a veces creen que el trabajo ocurre dentro de las reuniones, pero no ven el trabajo de pensamiento que hace falta antes de una buena reunión. Si uno apura la comunicación antes de ordenar las ideas, la reunión se vuelve puro ruido. En esas situaciones, la respuesta más poderosa es la actitud de vamos a averiguarlo juntos, y yo hago respetar la dependencia en el orden Why, What, How, Who, When. Si falta algo de la parte inicial, no se puede pasar a lo siguiente, y no permito evasivas fáciles ni de un intern ni de un VP. Si incluso después de descomponer el problema y pensarlo ahí mismo el equipo no cambia, entonces siento que ya corresponde buscar otro equipo

• Siento que la observación del texto sobre el specialism effect está bastante infravalorada. A mí también me ha desesperado que usuarios no entiendan algo que yo llevo años internalizando, pero luego me di cuenta de que el problema no es que a ellos les falte conocimiento, sino que lo tienen acumulado en otra parte. Ellos simplemente han pasado ese mismo tiempo profundizando en cosas completamente distintas

• No estoy totalmente de acuerdo con que la causa principal sea que la gente no habla y no escucha. Tomando prestada una analogía de una caricatura, creo que a mucha gente desde el principio le interesaba más el corte del listón que la carretera misma, y al final obtuvieron justamente eso

• Me ha pasado de forma bastante graciosa que la gente dice que quiere decir exactamente lo que dice, pero en la práctica no es así. Una vez confirmé comprensión reformulando casi palabra por palabra lo que la otra persona había dicho, y la respuesta fue una negación tajante: que eso en absoluto era lo que había querido decir

• Siento que gran parte del problema al hablar con áreas no técnicas es que ellas piden agregar X o cambiar Y sin contexto de costos. Claro que casi todo lo que piden se puede hacer, pero cada solicitud tiene un costo, y si eso no se entiende, es difícil compatibilizarlo con lanzar un producto confiable

  • Más bien, creo que esta respuesta demuestra exactamente el punto del texto. No es que ellos no entiendan el costo, sino que simplemente el contexto es distinto, y el rol del equipo técnico no es esperar que lleguen ya sabiendo el costo, sino ayudarlos a tomar tradeoffs informados
  • En estas situaciones siento que es importante preguntar los whys. Si entiendes el proceso no técnico, puede que en realidad ni siquiera haga falta ese agregado o ese cambio. También coincido en que, si intentas meterlo todo, acabas con un monstruo tipo Turing complete Excel/Email clone
  • Creo que aquí se da una asimetría: el personal no técnico no conoce el costo, y el personal técnico no conoce el beneficio. Al final, hace falta comunicación de ambos lados para encontrar un buen punto de costo-beneficio
  • Esto me parece un problema bastante resoluble. Basta con responder para cada solicitud cuántos meses tomaría y cuánto costaría, en meses y en dólares
  • Pero también siento que hoy la IA se está encargando de la parte de code thing, y eso sí ha bajado bastante el costo de implementación. Te guste o no, creo que ese cambio hay que reconocerlo