Las cuatro entregas anteriores describieron problemas. Performative alignment, adoption asymmetry, la fricción que eliminamos sin querer. Si has llegado hasta aquí, probablemente ya reconoces alguno de ellos en tu equipo.
Esta entrega es diferente. No describe nada nuevo. Te da el método para hacer algo con lo que ya sabes.
Llevo tiempo usando una estructura de tres fases con los equipos con los que trabajo. No es complicada. De hecho, su valor está precisamente en que es simple: Name it, Map it, Fix it. Nombrar, mapear, arreglar. En ese orden, porque cada fase depende de la anterior.
Te lo cuento con el detalle suficiente para que puedas ejecutarlo sin mí.
Fase 1 — Name it
La primera vez que expliqué el concepto de performative alignment a un equipo, pasó algo que no esperaba. La diseñadora me interrumpió a media frase y dijo “¿eso tiene nombre?”. Llevaba meses sintiendo que las reuniones de su equipo eran raras (todos asentían, nada se cuestionaba) pero no tenía palabras para describirlo. En el momento en que el fenómeno tuvo nombre, dejó de ser una sensación vaga y se convirtió en algo de lo que se podía hablar.
Esa es toda la idea de la primera fase. La mitad de estos problemas se resuelven, o al menos empiezan a resolverse, solo con nombrarlos. Porque lo que no tiene nombre no se puede discutir. Y lo que no se puede discutir se queda enquistado.
Nombrar tiene tres pasos concretos.
Primero, ten las conversaciones individuales. No empieces por una reunión de equipo. Empieza por tus one-on-ones de esa semana. A cada persona, hazle la misma pregunta abierta: “¿Cómo estás usando IA en tu trabajo ahora mismo, y cómo te sientes al respecto?” No la conviertas en una encuesta. No la enmarques como un diagnóstico formal. Es una conversación. Tu único trabajo es escuchar y tomar nota de los patrones. Vas a oír cosas que no esperabas. La persona que creías que no usaba IA te va a decir que la usa a escondidas porque le da vergüenza. La persona que creías cómoda te va a confesar que se siente desbordada. Apunta todo.
Segundo, trae los patrones al equipo. En la siguiente retro o en una reunión específica, comparte lo que escuchaste (anonimizado). “He hablado con todos esta semana y hay tres cosas que se repiten.” No expongas a nadie. No digas “María se siente atrás.” Di “varias personas sienten que el ritmo del equipo ha cambiado y no saben si pueden seguirlo.” El objetivo es que cada persona se reconozca en los patrones sin sentirse señalada. Cuando lo haces bien, ves cómo la gente asiente. Acabas de nombrar algo que todos sentían en privado y creían que solo les pasaba a ellos.
Tercero, acordad una sola norma. No diez. Una. Al final de esa conversación, el equipo decide junto un único cambio para la semana siguiente. Puede ser “cuando presentemos trabajo, decimos qué parte fue asistida por IA.” Puede ser “las sesiones de priorización las hacemos sin propuesta previa generada con IA.” Una norma, concreta, acordada por todos, para empezar. La razón de que sea solo una es que las transformaciones grandes fracasan y los cambios pequeños se sostienen. Quieres una victoria pequeña que demuestre al equipo que esto se puede cambiar.
Al final de la fase 1, no has resuelto nada todavía. Pero has hecho algo más importante: has convertido un malestar invisible en una conversación explícita. Y le has dado permiso al equipo para hablar de algo de lo que nadie hablaba.
Fase 2 — Map it
Una vez que el equipo ha nombrado lo que siente, necesitas entender dónde están realmente los problemas. Porque las sensaciones son un buen punto de partida, pero no son un diagnóstico. La fase 2 convierte sensaciones en información.
La idea es simple: que cada persona evalúe de forma individual y anónima cómo ve el equipo en una serie de dimensiones, y luego comparéis los resultados. Lo valioso no son las puntuaciones en sí. Son las discrepancias.
Te doy un set de preguntas que puedes usar tal cual. Cada persona puntúa del 1 al 5, en privado, y luego se comparten los resultados agregados.
Para detectar performative alignment:
“Cuando aprobamos un documento, todos entendemos por igual el razonamiento detrás, no solo el documento en sí.”
“En nuestras reuniones, es normal que alguien cuestione abiertamente una propuesta.”
“La última vez que aprobamos algo importante, las asunciones clave se discutieron explícitamente.”
Para detectar adoption asymmetry:
“Sé qué herramientas de IA usa cada persona del equipo y para qué.”
“El valor de cada persona en el equipo se percibe por su criterio, no por la sofisticación de sus herramientas.”
“Me siento cómodo/a mostrando cómo trabajo, use o no use IA.”
Para detectar pérdida de fricción productiva:
“Tenemos claro en qué momentos del proceso la IA ayuda y en cuáles preferimos no usarla.”
“Nuestras reuniones de decisión siguen teniendo el debate que necesitan.”
“Cuando algo se decide rápido, es porque estamos alineados, no porque nadie objeta.”
El ejercicio entero lleva unos cuarenta y cinco minutos. Quince para que cada persona puntúe, treinta para discutir los resultados.
Y aquí viene lo importante: cuando compartís las puntuaciones, busca las brechas. Si el PM puntúa un 5 en “es normal que alguien cuestione una propuesta” y dos personas puntúan un 2, ahí tienes el diagnóstico. No en el número promedio sino en la distancia entre cómo lo ve quien tiene más poder en la sala y cómo lo ven los demás. Esa distancia es casi siempre el mapa exacto de dónde está el problema.
He visto equipos descubrir en esta fase cosas que llevaban meses sin ver. Un PM que estaba convencido de que su equipo debatía sanamente y descubrió que era el único que lo percibía así. Un equipo que creía tener un problema de herramientas y descubrió que en realidad tenía un problema de confianza. El mapa no miente, porque nadie firma su puntuación.
Fase 3 — Fix it
Aquí es donde la mayoría de aproximaciones a este tipo de problemas fracasan. Porque la reacción instintiva es crear una política. Un documento de “buenas prácticas de IA en el equipo” que nadie lee. Una norma impuesta desde arriba que genera cumplimiento performativo. El mismo fenómeno que intentabas resolver, ahora aplicado a tu intento de resolverlo.
La fase 3 funciona con un principio diferente: las intervenciones se diseñan como product decisions, no como políticas. No cambias la cultura con un documento. La cambias cambiando los defaults; las cosas que pasan automáticamente si nadie decide lo contrario.
Hay tres tipos de intervención, y cuál uses depende de lo que el mapa de la fase 2 te haya revelado.
Si el problema es de transparencia y percepción, usa intervenciones de disclosure.
El default que cambias: cómo se presenta el trabajo. La norma es que cuando alguien comparte un entregable, dice cómo lo hizo. No como confesión, como contexto. “El borrador lo generé con Claude, los trade-offs son míos.” “Estas exploraciones son de Midjourney, la dirección de arte es mía.”
Esto resuelve dos cosas a la vez. Resuelve el authenticity gap, porque el equipo deja de preguntarse cuánto de cada trabajo es pensamiento propio y cuánto es output de máquina. Y resuelve parte de la adoption asymmetry, porque normaliza tanto el uso de IA como el no-uso. La persona que trabaja sin IA ya no tiene que sentir que esconde algo, y la que trabaja con IA ya no proyecta una falsa imagen de productividad sobrehumana.
Si el problema es de decisiones que nadie cuestiona, usa intervenciones de fricción protegida.
El default que cambias: dónde está permitida la IA en el proceso. El equipo marca explícitamente qué momentos son “AI-assisted” y cuáles son “human-only.” Priorización, discovery synthesis y retrospectivas se protegen. La preparación para esos momentos puede usar IA; el momento en sí, no.
Una forma concreta de implementarlo: antes de cualquier review de un documento importante, el autor no presenta el documento. Presenta las tres asunciones de las que menos seguro está. Eso cambia la reunión de “¿alguien tiene comentarios?” (que invita al silencio) a “¿me equivoco en alguna de estas tres cosas?” (que invita al desafío). Cinco minutos. Cambia toda la dinámica.
Si el problema es de niveles desiguales que generan distancia, usa intervenciones de nivelación.
El default que cambias: cuánto se ve el trabajo de los demás. Una vez al mes, alguien del equipo dedica treinta minutos a enseñar cómo trabaja. No una formación. No un tutorial top-down. Un intercambio horizontal: “así es como yo hago esto.” El que usa IA a fondo enseña cómo prompetea. El que no la usa enseña por qué prefiere su método. El tech lead enseña cómo piensa una arquitectura. Nadie tiene que cambiar su forma de trabajar. El objetivo es que todos entiendan cómo trabajan los demás, porque la asimetría se alimenta de la invisibilidad. Cuando ves cómo trabaja el otro, dejas de asumir.
El orden importa
Una advertencia sobre las tres fases: el orden no es decorativo. Es la parte más importante.
Si te saltas Name it y vas directo a Fix it, impones soluciones a problemas que el equipo no ha reconocido. La gente cumple por obligación, no por convicción, y la intervención se convierte en otra política vacía.
Si te saltas Map it, arreglas el problema equivocado. Crees que tienes un problema de herramientas cuando tienes uno de confianza. Diseñas una intervención de nivelación cuando lo que necesitabas era una de fricción protegida. El mapa existe para que no malgastes esfuerzo en el sitio equivocado.
Y si solo haces Name it sin llegar nunca a Fix it, conviertes a tu equipo en uno que sabe diagnosticar perfectamente sus problemas y no hace nada con ellos. Lo cual, con el tiempo, es peor que no haberlos nombrado, porque genera cinismo.
Las tres fases. En orden. Cada una corta. Ninguna requiere un consultor, un presupuesto, ni un offsite de dos días.
Lo que de verdad estás construyendo
Hay una idea que quiero dejar antes de cerrar, porque es fácil perderla entre lo táctico.
Cuando haces este proceso, en apariencia estás resolviendo problemas concretos de adopción de IA. Pero lo que de verdad estás construyendo es la capacidad del equipo para hablar de cómo trabaja. La mayoría de equipos nunca tienen esa conversación. Trabajan, entregan, repiten, y dan por sentado que la forma en que colaboran es simplemente como son las cosas.
Name it, Map it, Fix it no es solo un método para gestionar la IA. Es una excusa estructurada para que el equipo mire su propia forma de trabajar y decida, conscientemente, cómo quiere que sea. La IA es lo que hace urgente esa conversación. Pero la conversación en sí es valiosa con IA o sin ella.
Y ese es, en el fondo, todo el punto de The Human Layer. La tecnología cambia. Los modelos mejoran, las herramientas se renuevan, los flujos se reinventan cada pocos meses. Lo único que permanece es la capacidad de un equipo para entenderse, cuestionarse y decidir junto. Esa capa, la humana, es la que determina si toda la tecnología que pongas encima te hace mejor o solo más rápido.
Nómbrala. Mapéala. Diséñala. Antes de que la velocidad decida por ti.
The Human Layer es una serie que explora la infraestructura humana debajo de la adopción de IA en equipos de producto.
También encontrarás en el libro PRAXIS (www.praxisbook.com) más información acerca de los fenómenos y prácticas que estaré informando a través de esta serie.
Si esto te ha resonado, compártelo con alguien de tu equipo. Estas conversaciones funcionan mejor cuando las dos personas tienen el lenguaje.