El empoderamiento de los equipos y el principio de realidad

Llevo dos décadas trabajando en diseño de experiencia de usuario y he escuchado el mantra de los «equipos empoderados» más veces de las que puedo contar. La promesa hay que reconocer que es seductora: dale a los equipos problemas que resolver en lugar de características que construir, y verás cómo florece la innovación. La realidad, como casi siempre, es bastante más compleja.

Hay un artículo de Laura Klein en Nielsen Norman Group, de la factoría NNG, que me leí en el tren el otro día, sobre por qué la mayoría de los equipos de producto no están realmente empoderados. El texto es francamente honesto y describe con bastante precisión los síntomas, pero hay algo que me falta: el principio de realidad. Porque el problema no es sólo que las organizaciones no tengan “equipos empoderados”, que a veces (o muchas veces) eso es así. El problema es que el empoderamiento, el rollo de los equipos empoderados, tal como se vende en la literatura de producto, es muchas veces incompatible con cómo funcionan realmente las empresas reales, las que pagan nóminas.

La tensión fundamental: certeza vs. iteración

Las empresas necesitan certezas. Lo afirmo y lo mantengo. Llevo gestionando una empresa 15 años. No es un capricho ni es una supuesta resistencia al cambio motivada por una pulsión conservadora: es supervivencia organizacional. Las nóminas, en general, no se pagan bajo un modelo de experimentación continua. Para quienes los tienen (no es mi caso), los inversores no invierten en el vacío. Los clientes grandes no firman contratos con empresas que improvisan su roadmap cada sprint.

Esta tensión que hay entre la certeza que necesita el negocio y la iteración que promete el producto no es un bug del sistema, sino más bien una característica producto de trabajar en organizaciones complejas. En castellano simple: son lentejas. Pero tenemos a una buena parte del discurso sobre equipos empoderados ignorando esto olímpicamente. Con este escenario tenemos un punto de partida retador.

Cuando en una empresa la dirección anuncia que la prioridad estratégica del año es la inteligencia artificial, no están pretendiendo ser malvados ni presentarse como el grinch de los usuarios. Simplemente están haciendo su trabajo. Quien paga la fiesta, manda. La pregunta que importa no es «¿por qué no nos dejan seguir nuestra investigación de usuarios?«, sino «¿cómo convertimos este requisito de mierda en algo que no sea una mierda?«.

El verdadero problema es la ausencia de liderazgo en diseño

Klein describe un escenario que podemos reconocer: un equipo usa modales para las confirmaciones, otro usa mensajes inline, un tercer equipo lleva al usuario a una página nueva. Los botones dicen «Enviar» en un sitio, «Guardar» en otro, «Continuar» en un tercero. El tono del microcopy oscila salvajemente entre formal y casual. Un sindiós.

Si me permitís la analogía, un revuelto parecido al que el diseño de los iconos de Tahoe nos ha traído.

El diagnóstico de Klein: los equipos no tienen el poder suficiente para coordinarse. Mi diagnóstico: no hay liderazgo en diseño.

Si esto pasa en el sitio en el que trabajas, me parece que hay altas posibilidades de que alguien no está haciendo su trabajo. Y ese alguien probablemente tiene Lead, Principal o Director en su título. Porque, amigas y amigos, coordinar la experiencia de usuario a través de equipos que trabajan de manera autónoma es precisamente el trabajo del liderazgo en diseño. Esto no es un extra, no es algo que podríamos hacer en caso de tener tiempo. Mas bien este es, literalmente, el cometido principal de esa posición.

Porque, permitidme, voy a invocar al principio de realidad: los usuarios no ven equipos; los usuarios ven un producto. Volvemos a hablar un poco como en los 2000, pero la pedagogía es también un poco esto.

El problema no es que los equipos tengan autonomía. El problema es que se les da autonomía sin la estructura de gobierno que garantice coherencia. Es empoderar a perfiles sin visión holística, con incentivos perversos y skills debatibles, y luego sorprenderse de que el resultado sea un Frankenstein. Vamos a ser serios.

La madurez profesional es trabajar con las restricciones, no contra ellas

Una de las frases más reveladoras del artículo de Klein es cuando describe a una product manager que fue contratada para ser una pensadora estratégica pero se ha convertido en una project manager enfocada enteramente en logística y coordinación.

La conclusión implícita es que esto es malo, que el sistema ha fallado, que la logística y sobre todo la coordinación no son la tarea estratégica que hay que abordar. Pero ahora yo me pregunto en público y en voz alta: ¿y si esa coordinación es el trabajo estratégico? ¿Y si en organizaciones complejas, con múltiples equipos y dependencias entre sistemas compartidos, la capacidad de coordinar efectivamente es la habilidad diferencial?

Porque aquí está el secreto que nadie quiere admitir: en la moderación está la virtud. Que sí, que tengo ya frases de abuelete, que ya lo sé. Pero es que entre un idealismo un poco ingenuo del equipo totalmente autónomo y el ordeno y mando tradicional, existe un espacio de madurez profesional donde:

1. Aceptas que no controlas el roadmap, ya que esto pasa más de lo que nos gustaría, pero a veces es lo que hay.
2. Eliges tus batallas, porque no puedes pelear cada mandato top-down.
3. Construyes reputación mediante ejecución ya que si tu equipo tiene fama de tomar buenas decisiones y de entregar trabajo de calidad, conseguirás más margen de maniobra, más credibilidad.
4. Conviertes calabazas en carrozas, o por lo menos, en algo presentable, algo que no sea vergonzoso.

Esto último es especialmente importante. Cuando, por poner un ejemplo, la dirección te manda integrar IA porque es la prioridad estratégica del año, tienes dos opciones: quejarte de que no te dejan seguir tu investigación de usuarios, o estrujarte el cerebro para hacer de ese requisito algo memorable. O, insisto, al menos algo que no sea una mierda.

Las herramientas del principio de realidad

La buena noticia en todo este panorama es que, incluso en situaciones imperfectas (perdón: se dice «principio de realidad«), puedes tener impacto estratégico. Se puede trabajar incluso en escenarios poco favorables. Pero eso requiere de mucho trabajo y del uso de herramientas específicas:

1. Visualiza el journey completo del usuario

Si sólo nos centramos en nuestro trozo de producto, estamos perdidos. El liderazgo en diseño implica entender el journey end-to-end, a través de diferentes canales y touchpoints. Sí, esto entra en conflicto con la idea de equipos individuales empoderados, cada uno con su problema y con su métrica. Pero es que esa idea, cuando hablamos de diseño de equipos y ejecución de roles, es toxicidad pura.

2. Construye relaciones antes de necesitarlas

Si partimos de la base de que la construcción de liderazgo necesita obligatoriamente una estrategia de tejer relaciones, consensos, intereses comunes y complicidades, esto no debería ser un tema de conversación. Y sin embargo, hay que seguir insistiendo: hablar con otros equipos antes de necesitar algo de ellos es parte irrenunciable de nuestro trabajo.

Entender cómo nuestro trabajo afecta sus métricas y prioridades es nuestra responsabilidad. El trabajo en equipo implica entender de dónde viene el request que recibimos y dónde va nuestro delivery.

3. Documenta todo

Pues si hay que seguir insistiendo en esto, se hace. Pero sí, tenemos que documentar. No necesitaremos explicar nuestros razonamientos o posiciones en reunión tras reunión si todo eso está escrito y es accesible en algún sitio. Y además, tendremos el canario en la mina para detectar debilidades de liderazgo: si las mismas preguntas surgen una y otra vez a pesar de estar documentadas, hay un problema de proceso o de personas.

4. Trabaja con liderazgo para definir métricas que importen

Nadie dijo que fuera fácil. Pero es que si las métricas que caen en nuestro lado no capturan lo que realmente importa, nuestro trabajo es proponer alternativas y convencer. Esto requiere credibilidad, y esa credibilidad se construye entregando resultados consistentes. La ejecución sigue siendo diferencial.

5. Elige problemas con menos dependencias

Esta es una actitud que podría denominarse conservadora, pero la compro. Si podemos elegir entre trabajar en algo que requiere coordinación con catorce equipos y algo que podemos resolver con nuestro equipo y dos dependencias, la segunda opción nos dará más autonomía real. Y luego ya iremos viendo y ya iremos construyendo. No hay que olvidar que con victorias vamos ganando credibilidad y eso siempre ayuda en la construcción de los consensos y de las complicidades que necesitamos.

Lo que nadie quiere decir en voz alta

Hay algo que es muy incómodo en el discurso sobre equipos empoderados: la suposición implícita de que las restricciones organizacionales son el enemigo. Que si pudiéramos eliminar la burocracia, las dependencias, los mandatos top-down, entonces sí que haríamos productos increíbles.

Es una fantasía. Y honestamente me parece tratar a las personas como si fueran menores de edad.

Las restricciones son el contexto en el que trabajamos. Las dependencias existen porque los sistemas son complejos y los productos están cada vez más integrados. Los mandatos estratégicos vienen de arriba porque alguien tiene que tomar decisiones de negocio que van más allá de lo que un equipo individual puede ver.

El problema no son las restricciones. El problema es la falta de liderazgo para lidiar con esas restricciones y hacerlo bien. Y específicamente, en diseño, el problema es que seguimos sin asumir que coordinar una experiencia coherente a través de equipos autónomos es nuestro trabajo principal.

No es responsabilidad del PM que se ha convertido en coordinador. Es responsabilidad del diseñador senior que no ejerce liderazgo. No es responsabilidad de la organización. Es responsabilidad del Head of Design que no ha establecido sistemas de gobierno del diseño.

Una invitación a la honestidad brutal

Después de veinte años en esto, he llegado a una conclusión: el discurso sobre empoderamiento de equipos es a veces una forma de evitar conversaciones difíciles sobre liderazgo, gobernanza y madurez profesional.

Es más fácil culpar a «la organización» que admitir que quizá no tenemos las habilidades necesarias para coordinar de manera profesional a través de la complejidad. Es más cómodo quejarse de que «no nos dejan hacer nuestro trabajo» que reconocer que nuestro trabajo ha evolucionado y ahora incluye coordinación política, construcción de consenso y navegación de restricciones.

Las empresas que funcionan bien no son las que han eliminado las restricciones. Son las que han desarrollado músculo organizacional para trabajar productivamente dentro de esas restricciones. Y en diseño, ese músculo se llama liderazgo.

Así que la próxima vez que escuches a alguien lamentarse de que su equipo no está realmente empoderado, pregúntale: ¿has documentado tu razonamiento? ¿Has construido relaciones con los equipos de los que dependes? ¿Has propuesto métricas alternativas? ¿Has entregado resultados consistentes que te den credibilidad? ¿Estás ejerciendo liderazgo en diseño para garantizar coherencia?

Porque si la respuesta es no, el problema no es el empoderamiento. El problema eres tú.

Para quien le interese, aquí dejo el artículo de Klein, subrayado y comentado.