Diseñar prácticas para ser usadas por personas

Tiempo aproximado: 8 min.

Hace unas semanas pregunté en Twitter sobre si delegar se basa en «confiar con método» o en «desconfiar con método»? La respuesta fue masivamente la primera aunque, sinceramente, el resultado cuantitativo de la encuesta me resulta indiferente. En realidad lo que me interesan de estas «encuestas-provocación» son las reflexiones que despiertan entre quienes las leen y, sobre todo, las respuestas que obtengo a los mismos. Enriquecedoras en su inmensa mayoría.

Para tu comodidad, voy a reproducir íntegramente el contenido de aquel hilo, en un formato algo más legible, y al final haré una consideración más, porque creo que el hilo deriva excesivamente hacia el concepto de la delegación, que no era el punto central de mi discurso.


A veces pensamos que las prácticas que seguimos son inocentes de lo que luego sucede. Son nuestros valores, los de los que ejecutamos la práctica, los que deciden el resultado. Yo discrepo. El diseño de una práctica puede influir significativamente sobre los resultados.

Voy a tratar de hacer un repaso de diferentes situaciones siguiendo el framework #Cynefin porque me ayuda a hablar de complejidad y su relación con el diseño de prácticas.

Quizás te interese este artículo que escribí hace tiempo:

Pongamos el caso de un problema simple cualquiera. Sumar números. Al sumar seguimos una receta bien conocida en la que no podemos incorporar creencias ni demás sesgos. Se notaría mucho porque el resultado es predecible.

Cuando el problema que tratamos de resolver es complicado, podemos discrepar sobre la manera de resolverlo (la receta a seguir), pero al final el resultado será el mismo. Todo caso, dependerá de las variables consideradas en el análisis del problema las que variarán el resultado.

Ojo, porque aquí ya hemos dado pié a una decisión humana, es decir, a introducir un sesgo. Dependiendo de qué variables decidimos incorporar en nuestro análisis, la receta elegida dará un resultado diferente. Voy a poner un ejemplo.

Imaginemos que tenemos que elegir el menú para la cena. Si sólo consideramos las preferencias de quien paga, el resultado será bien distinto de si consideramos también las preferencias de quienes comen. Ídem si consideramos el número de comensales. Cuantas más variables consideremos, la decisión será potencialmente más apropiada. El proceso y el resultado del mismo serán también cada vez más complicados. Como humanos, tendemos a simplificar, es decir, a incorporar nuestros sesgos bajo la premisa de que tal variable no es significativa.

(No seguiré hacia el terreno de lo complejo porque creo que aquí ya hay suficiente para explicar lo que quería reflexionar en el tweet original).

Vayamos ahora a un proceso de delegación más o menos ideal. Como bien me apuntaban por aquí, «delegar consiste en que otras personas realicen tareas de las que tú eres responsable, aunque eso implique que no se harán exactamente como tú las harías».

No me considero un experto ni mucho menos, pero lo que he ido aprendiendo durante estos años acerca de la delegación es que es un proceso en el que vamos evolucionando una serie de acuerdos y que, en muchas ocasiones, nos obliga a poner a prueba nuestros valores.

Esta semana, por ejemplo, he usado la práctica de #management30 del Delegation Board para establecer unos primeros acuerdos de trabajo entre el sponsor de nuestro «Plan de Dominación Mundial (Título Provisional)» y la Coalición para el Cambio.

AVISO: Voy a hacer aquí una telegráfica explicación sobre la técnica del Delegation Board porque creo que así se entiende mejor el resto del hilo.

El tablero de delegación (o Delegation Board en inglés) es una técnica que recoge Jurgen Appelo en su Management 3.0 y sirve para que un manager acuerde con sus subordinados qué tareas va a delegar y con qué nivel de delegación.

Los niveles que plantea son los siguientes:

  1. DECIR. El manager dice a sus colaboradores lo que deben hacen.
  2. VENDER. El manager intenta «vender» lo que hay que hacer. «¿Quién se atreve? ¿A quién le apetece?»
  3. CONSULTAR. El manager pide consejo a su equipo pero al final es él (o ella) quien decide.
  4. ACORDAR. Lo acuerdan juntos.
  5. ACONSEJAR. El manager aconseja, pero los colaboradores deciden.
  6. PREGUNTAR. El manager preguntará después de que el equipo haya decidido (lo cuál implica que debe estar informado de las decisiones). El objetivo es poder dar feedback, no deshacer las decisiones equivocadas.
  7. DELEGAR. Los colaboradores son plenamente autónomos para tomar decisiones. Ni siquiera necesitan informar, aunque parece razonable que creen mecanismo de transparencia porque el manager seguramente también tiene otros superiores que pueden requerir de información sobre lo que está en marcha.

Explicitar estos acuerdos permite:

  • al manager, que vaya dejando de tomar decisiones en favor de sus colaboradores pero manteniendo el control de aquello que está bajo su responsabilidad,
  • a los colaboradores, que vayan adquiriendo conocimiento sobre las tareas y los criterios para tomar decisiones, saliendo así de la zona de confort, pero sin llegar a la zona de pánico.

habilitando, por tanto, a ambas partes para ir ganando en confianza.

A partir de ACORDAR comienza a ser relevante cómo se toman las decisiones pues el reparto de poder ya es explícito. Pero esto es otra historia…

AVISO: Hasta aquí la digresión. Continúa el hilo original.

Supongamos que, como es mi caso, eres una persona altamente controladora y enfocada en los detalles. Seguramente me quedaría en el nivel de «Acordamos» como máximo porque no me fío de los resultados a los que puedan llegar los demás sin mí.

Sigamos imaginando. Si la gente a la que tuvieramos que delegar fueran novatos o incluso son muy reacios a tomar responsabilidades (por la razón que sea), muy probablemente nos quedaríamos también en los niveles más bajos de delegación.

Aparentemente, el proceso no está diciendo nada sobre qué nivel de delegación está bien o está mal para cada actividad. Por tanto, lo deja todo al criterio de las personas que deben acordarlo. Es decir, lo deja todo al efecto de los valores de las personas involucradas. Y eso nos lleva a hablar de confianza. Si la persona que delega le da más importancia a empoderar a su equipo y a que estos adquieran cada vez más responsabilidad, entonces no le quedará más remedio que confiar en ellos y darles la oportunidad de que, de vez en cuando, fallen. Si, por el contrario, lo que busca es dejar de hacer tareas y que éstas se hagan con un cierto criterio de exigencia, éste debe ser explícito y formar parte del proceso de delegación, mucho más basado en la desconfianza que en la confianza. Ninguno de los dos enfoques es malo. Dependerá de muchos factores, entre otros, de los valores de las personas involucradas. El proceso de acordar el nivel de delegación, tal y como está diseñado, empuja a hablar de ello. Y eso es diseño.

En resumen: podemos (y debemos) diseñar las prácticas para favorecer ciertos comportamientos, teniendo en cuenta que, al final, los valores de las personas involucradas serán los que terminen por decantar los resultados.

Me encantaría conocer tu opinión.


Hasta aquí el hilo que publiqué en Twitter. Sin embargo, como te comentaba más arriba, creo que puse en él demasiado foco en la delegación, a pesar de que para mí se trata de apenas una práctica más de muchísimas.

Estamos rodeados de prácticas: muchas de las actividades que hacemos cada día como, por ejemplo, la reunión diaria de Scrum, son prácticas, o usar un tablero para gestionar el trabajo en curso es también una práctica, una reunión para dar feedback es también una práctica… Los procesos son prácticas, los roles son prácticas, los artefactos son prácticas… y hemos llegado a ellos tras un proceso más o menos consciente de diseño, es decir, de decisiones que configuran lo que luego harán las personas.

Hace pocos días publicaba Jeff Gothelf (autor de Lean UX, entre otros) una breve entrada en su blog advirtiendo justamente de que los departamentos que ofrecen servicios hacia dentro de las organizaciones deben pensar también en medir los beneficios («outcomes») de los cambios que realizan para sus «clientes internos», como si de un producto para «clientes finales» se tratase.

Estoy absolutamente convencido de que debemos diseñar deliberadamente las prácticas como productos, pero no sólo para que cubran las necesidades de los intervinientes (para qué sirven), sino también teniendo en cuenta cuándo y cómo el diseño de esas prácticas les obligan a contrastar sus propios valores (por qué lo hago, qué dejo de hacer a cambio de hacer esto…).

Pero, es más, nuestra responsabilidad como diseñadores (y a veces facilitadores) de esas prácticas es muy alta porque somos los que primero influimos con nuestros propios valores. Nuestra participación no se queda en seguir un framework o adaptar la última dinámica que hemos conocido en un meetup, y nos quedamos tan panchos pensando que es una elección inocente. Elegir también es diseñar. Y nuestras elecciones son también reflejo de nuestros valores, y con ellas influimos sobre lo que luego sucede. Para lo bueno, y también para lo malo.

He visto muchas veces a Agile coaches y ScrumMasters (yo mismo), más o menos expertos, quejándose porque la gente con la que trabaja no participa de las dinámicas que han diseñado con tanta dedicación para ellos. Puede ser duro reconocer que, como diseñador de esa práctica, has puesto tus propios valores por encima de los del grupo. Yo le doy valor a la transparencia y diseño una retrospectiva para que la gente comparta cara a cara sus puntos de vista y busquen soluciones colectivas. Muy bonito, pero igual no he tenido en cuenta que el equipo está formado por personas de diferentes empresas (el cliente y dos proveedores diferentes, que son competencia entre ellos). Esa retrospectiva, tal y como ha sido diseñada, tiene muchas papeletas para que no cumpla las expectativas. Quizás una retrospectiva basada en métricas sobre el producto sea un formato más adecuado para ese contexto.

Durante la travesía intelectual que está representando para mí el Plan de Dominación Mundial (Título Provisional) en , cada día soy más consciente de la influencia que tengo sobre cómo se relacionarán los participantes en el desarrollo del mismo. Al diseñar prácticas en las que el foco se pone en acordar cómo se comparte el poder, no garantizo que éste se comparta, pero sí obligo a tener la conversación y a enfrentar los valores de los intervinientes (entre ellos y consigo mismos). Una de las características esenciales de lo que estamos haciendo se basa en crear el hábito de cambiar, y para ello es imprescindible que aprendamos a tomar decisiones juntos. Ser explícitos en los acuerdos de trabajo forma parte esencial de este aprendizaje.

Otra decisión consiste en que las iniciativas de cambio no vienen «desde arriba» sino que debemos hacer una invitación para el cambio. Es todo un reto incorporar mecanismos que eviten (por diseño) dejarse llevar por la inercia de usar la jerarquía y «camuflarla» de invitación.

Pero, ojo, porque yo, como diseñador de todas estas prácticas, estoy decidiendo que el reparto del poder (delegación, p.ej.) debe ser explícito y debemos hablar de ello como un potencial impedimento para lograr una mayor agilidad en la organización. Podría haber decidido, por ejemplo, no hablar de ello (lo que tácitamente es ponerme del lado del statu quo). Y todo esto es una decisión ideológica. Estoy imponiendo mis valores a la hora de diseñar nuestras prácticas, enmarcando de esta manera el comportamiento de los participantes en ellas.


LA FOTO: Obtenida en Pexels, representa el papel artesanal del diseño (también de procesos, roles, etc). Hay que darle forma a la vasija, sabiendo que queremos que contenga líquidos, pero sabiendo también que queremos que sea usada por nuestros clientes. Y para ello es necesario mancharse las manos y también preguntar mucho cuáles son los gustos (valores) de esos clientes.