Cultura

Servant leadership, separando el grano de la paja

Si has leído la guía de Scrum o asistido a uno de nuestros cursos, habrás oído hablar del término servant-leader. Al contrario de lo que muchas personas piensan, el concepto de Servant-Leadership no es nuevo, tiene un fundamento científico fuerte detrás y ha sido adoptado mucho más allá de entornos ágiles por distintas organizaciones a lo largo de muchos lustros.

El Servant-Leadership es un modelo de liderazgo en donde la meta última del líder es servir, a diferencia de los modelos tradicionales en donde la meta del líder es crear una organización o una empresa próspera, lo que puede -o no- alinearse con la meta de servir a la organización.

Alguien que lidere a través del servicio comparte poder, anteponiendo las necesidades de los empleados y ayudando a las personas -incluyendo a los stakeholders- a desarrollar su máximo potencial.

En la formulación original de Robert K. Greenleaf, la pregunta que debe hacer el líder es: ¿Están creciendo aquellos a los que se sirve? ¿Son más saludables, sabias, libres, autónomas, se sienten mejor, más capaces para convertirse en en servidoras también?

Esto, que puede intuitivamente ser asociado a un entendimiento superfluo del liderazgo, ha sido ampliamente estudiado. En un estudio de investigación del año 2002, Sendjaya y Ramos analizan cual es el impacto del Servant Leadership en las organizaciones que deliberadamente han decidido adoptarlo como modelo de liderazgo.

Servant Leadership, un término con más de 50 años

Aunque parezca un término nuevo, el término Servant-Leadership (liderazgo a través del servicio) fue formulado hace casi medio siglo. La idea le surgió a Greenleaf tras leer el libro Viaje al Oriente, de Herman Hesse, que describía la épica aventura de un grupo que decide viajar a Oriente y cuya figura más aparentemente innecesaria, Leo, desaparece, provocando el desarraigo y la separación de un grupo aparentemente cohesionado.

Durante el viaje, Leo se encarga de realizar tareas mundanas y aparentemente veniales: Fregar platos, recoger materiales, pero también animar al resto en cuerpo y alama. Nadie diría que Leo es el pegamento del grupo hasta que éste desaparece.

A Greenleaf le cautivó la idea de que el sirviente fuera realmente el líder y decidió conceptualizar la idea de Servant-Leadership en una persona cuyo éxito se mide por el crecimiento y el éxito de otros, no de sí mismo.

Las características de un Servant leader

En 1998, Larry Spears publicó otro artículo de investigación en el que describía las características más importantes de un líder servicial a raíz de las formulaciones posteriores a la conceptualización inicial de Greenleaf. Éstas 10 características son:

Escucha. Aunque los líderes son valorados por su capacidad comunicativa y de decisión, éstas tienen que estar reforzadas por una profunda capacidad de escucha activa hacia los demás. Dado que el compromiso del líder servicial es hacia los demás, aprender a escuchar tanto lo que se dice como lo que no es fundamental para poder accionar decisiones.
Empatía. La empatía se puede describir como la habilidad para ponerse en la piel del otro, desprendiéndose de los propios juicios -y prejuicios-. Es importante no confundirlo con la simpatía -sentir lo que siente el otro-. De esa manera, el líder puede utilizar mejor su capacidad de acción.
Curación. Ser capaz de sanar y reforzar relaciones es una potente capacidad transformadora y de integración. Una de las grandes fortalezas de un líder servicial es ser potencialmente capaz de sanar las relaciones propias y ajenas.
Conciencia. La conciencia de lo que ocurre a su alrededor, y especialmente la auto-conciencia, son dos capacidades que tiene el servant-leader a su disposición para hacer crecer a otros y desarrollar un entorno en el que puedan alcanzar nuevas cotas de potencial.
Persuasión. Lo que diferencia la persuasión de la manipulación es la intención. Persuadir es la habilidad de conseguir convencer a alguien para hacer algo en pro de un bien común. La manipulación consiste en convencer a alguien para hacer algo solamente en pro de un beneficio personal.
Conceptualización. La capacidad de observar un problema desde una perspectiva de conceptualización significa que uno debe de mirar más allá de los problemas del día a día. Conceptualizar problemas a través del modelado es una habilidad fundamental para un líder servicial.
Previsión. Muy relacionada con la conceptualización, la habilidad de preveer los resultados de una acción es difícil de definir pero sencilla de identificar. La previsión es una capacidad que permite al líder servicial aprender del pasado, entender los problemas del presente y generar espacio para la resolución de problemas complejos a través de aquellos a los que sirve.
Gobernanza. A diferencia de la dirección, la gobernanza se manifiesta en la capacidad de conseguir consenso en un entorno complejo para alcanzar resultados mayores. Mientras que la dirección implica la toma de decisiones individual, la gobernanza se centra en la creación de marcos donde los miembros del sistema tienen libertad para conseguir metas.
Compromiso hacia el crecimiento de las personas. No debería de sorprendernos saber que la mayoría de los líderes consideran a las personas como medios para conseguir sus propios fines y no cómo entes autónomos con sus propias motivaciones cuyo crecimiento ayuda a sumar al sistema.
Construcción de comunidad. Por último, los líderes serviciales están muy orientados a la creación de comunidades donde otros pueden tomar el papel de liderazgo en cualquier momento.

Es interesante hacer un inciso para aclarar que en Psicología se distingue entre rasgos y características del carácter. Mientras los primeros pueden no ser modificados y van implícitos en el carácter de la persona, los segundos se adquieren a través del entrenamiento y el aprendizaje.

SLBS-6, midiendo el Servant Leadership

En 2019, Sendjaya junto con su grupo de investigación publicó un cuestionario corto de 6 preguntas, basado en un estudio de dos años antes, para validar la fiabilidad del constructo de Servant-Leadership.

En Psicología, cuando se pretende medir algo a través de un cuestionario, hay que refutar que realmente las preguntas miden aquello que se pretende estudiar. Esto es lo que se determina mediante la validación de las propiedades Psicométricas de las preguntas. En particular se analizan la fiabilidad, la cohesión y la validez del constructo. La escala del estudio consta de seis elementos:

[Mi jefe…]

Utiliza su autoridad en servicio de otros, no para su propia ambición
Me da el derecho a cuestionar sus acciones o decisiones
Me respeta por quien soy, no por cómo le hago sentir
Realza mi capacidad para acciones morales
Me ayuda a generar un sentido de propósito del trabajo diario
Contribuye a mi crecimiento personal y profesional

Servicial no es servil

Es fácil pensar que el objetivo de un líder servicial es servir las necesidades de todas las personas con las que trabaja. Nada más alejado de la realidad.

En la mayoría de las ocasiones y ante un problema, un líder servicial actuará con el objetivo de empoderar a la persona, en lugar de resolverle el problema. Ésta es la diferencia entre servicial -sirve- y servil -lame culos-.

Para terminar, merece la pena hacer una referencia a que el conjunto de prácticas de Management 3.0 puede ayudar a un servant-leader a entender cuales son las motivaciones y obtener retroalimentación para las primeras características que mencionábamos más arriba.

La autoorganización en las empresas

Los equipos y estructuras autoorganizadas son claves para un desarrollo ágil y, por lo tanto, para activar los beneficios de la business agility en nuestra empresa. Uno de los problemas con los que se encuentra la autoorganización es que la idea tiene una barrera de entrada fuerte. Generalmente, en las empresas de corte más tradicional genera rechazo inmediato, urticaria y escepticismo. En este artículo voy a compartir qué me ha funcionado para convencer y para poner en marcha equipos autoorganizados.

[Leer más…]

Aplicando Design Thinking para impulsar la gestión del cambio

Ya nadie duda que estamos viviendo una época compleja, y en este entorno las empresas tienen el reto de adaptarse con rapidez para dar respuesta al movimiento de los mercados. Aquí es donde el framework que propone Lean Change Management viene a aportar aire fresco a cómo se gestiona el cambio en las organizaciones, y en este contexto el Design Thinking se está viendo como una herramienta potente para enlazar el diseño centrado en las personas con la cocreación y compromiso de las personas afectadas por el cambio en las organizaciones. Veamos Lean Change Management y Design Thinking, potenciando el cambio.

Artículo escrito por: José Antonio Ortega Barros

¿En qué consiste Lean Change Management?

LCM es un framework de gestión del cambio, planteado por Jason Little, que se sustenta sobre todo en disciplinas como Lean Startup y Design Thinking. LCM parte de la base de que es complejo predecir el impacto de un cambio y por tanto, en lugar de un tener un plan cerrado en tiempo y alcance, es mejor disponer de un backlog de cambios e ir introduciendo esos cambios en el sistema como si de experimentos se tratasen para luego ir modificando la estrategia de cambios en base al feedback recibido. El ciclo LCM es el siguiente

El framework se basa en la búsqueda de Insights (hallazgos que vamos aflorando de la organización relacionados con el propósito del cambio) que permiten plantear opciones de cambio, de los cuales extraemos experimentos de cambios que posteriormente se tendrían que introducir en la organización. La clave es que al poner en marcha los experimentos, el feedback recibido será fundamental para reajustar todo el contenido del framework (hallazgos, opciones y experimentos). Al final, lo que buscamos es que los cambios se vayan introduciendo en un proceso evolutivo que permita que la organización vaya absorbiéndolos de una forma más natural y sistémica.

¿Design Thinking? ¿en gestión del cambio?

Hace años que hemos venido aplicando Design Thinking, sobre todo en aspectos de diseño de producto y de hecho, cuando empezamos a aplicarlo, fue un descubrimiento por el fuerte énfasis en poner a las personas en el centro de cualquier solución. Provengo de un entorno técnico, en donde las soluciones que buscábamos no partían realmente de empatizar con los usuarios que iban a usar nuestras soluciones y por ello, hacer ese ejercicio de empatizar con los usuarios nos colocaba en un eje diferente a la hora de buscar soluciones. Ya que el proceso del Design Thinking te obliga a replantearte el problema que quieres resolver, se producen conversaciones que jamás hubiéramos tenido de otro modo.

Otro aprendizaje que hemos visto al aplicar Design Thinking es que supone un hack en la cultura de los equipos de trabajo, generando un mayor nivel de compromiso por parte de todos los participantes a la hora de buscar soluciones creativas que aporten un gran valor a los usuarios o personas afectadas.

Cuando empezamos a usar LCM como parte de nuestro proceso de gestión del cambio en proyectos de rediseño organizativo o transformación, aplicar el enfoque de Design Thinking supuso un salto natural, sobre todo para diseñar las intervenciones con los equipos afectados por el cambio. Fue una herramienta muy potente para ir creando en los equipos un mindset con un enfoque más orientado a crear un nuevo marco de relaciones entre las personas de la organización afectadas por el cambio.

Parafraseando a Tim Brown, autor del libro de “Change by Design” y CEO de IDEO, Design Thinking es una disciplina que usa la sensibilidad de los diseñadores para cubrir las necesidades de las personas con soluciones que sean tecnológicamente viables, pero también alineadas con la viabilidad de negocio, que puedan crear valor para los clientes y con la creación de oportunidades de mercado. Si lo pensamos bien, ¡es toda una declaración de intenciones si pensamos en los procesos de gestión de cambio que podamos conocer!

En su definición original de LCM, Jason Little mencionaba que LMC es un enfoque basado en el feedback para la gestión del cambio. Usando la filosofía del Design Thinking, podríamos completarlos del siguiente modo

LCM es un enfoque basado en el feedback y el diseño de acciones de cambio centrado en las personas para crear un entorno ilusionante de cambio para la organización

¿Qué es Design Thinking?

Partiendo de la definición de IDEO, Design Thinking es un proceso centrado en las personas, para buscar soluciones partiendo de los insight identificados para convertirlos en acciones o experimentos que se pueden accionar en soluciones o productos que respondan a los problemas que realmente afloran y como los que hay que resolver.

El proceso de DT ocurre en 5 etapas iterativas del siguiente modo:

Empatizar
Definir el problema
Idear
Prototipar
Testear

Empatizar: en esta etapa, buscamos entender cómo se comporta las personas afectadas por el reto que estamos investigando. Cuáles son sus alegrías y sus frustraciones. Para ello se pueden usar diferentes modelos de información como los mapas de empatía o la herramienta Persona, que nos permiten ir estructurando la información que obtenemos de las entrevistas reales que mantenemos con las personas afectadas por el problema o por el cambio.

Definir el problema: nos permite crear conversaciones entorno a la información de la que disponemos, para desde diferentes perspectivas entender el problema que tenemos que realmente resolver. Para ello buscaremos patrones que se repiten o desafíos que nos permitan identificar oportunidades. Existen varias herramientas para ayudarnos en esta etapa como es crear el Customer Journey para identificar la experiencia de las personas en relación al reto que nos hemos planteado.

La redefinición del problema se convertirá en el punto focal de la siguiente etapa de ideación

Idear: esta etapa es de divergencia, es decir, se trata de dejar un espacio para plantear soluciones creativas, incluso soluciones locas. En esta etapa hay una seria de reglas que recomendamos cumplir, y que parten de la base que Alex Osborn definió para realizar un buen Brain Storming:

Postponer el juicio: en este momento del proceso no hay ideas malas, todas son aceptadas y no se critica ninguna
Alentar ideas muy locas
Construir sobre las ideas de los demás
Usar cuantas más herramientas de creatividad posibles: existen muchas técnicas para generar ideas (conexiones forzadas, brainstorming, brainwritting, personajes, desvarío en 8 etc…)
Centrarse en la cantidad: según estudios se estima que para tener 1 buena idea se requiere manejar un grupo de entre 40 y 50 ideas… ¡hagan números!

Prototipar: para entrar en esta fase, será necesario realizar una actividad previa de selección de ideas. Es importante considerar que si usamos una matriz de selección muy lineal podemos llegar a descartar ideas locas desde el principio, y en esa reflexión, sugerimos que antes de descartarlas reflexionar sobre ella, si detrás de la idea hay matices que nos pueden llevar a complementar otras que las puedan enriquecer.

Con las ideas seleccionadas, pasaremos a la fase de prototipado. Entendiendo por prototipo crear un modelo o representación de las ideas para poder mostrárselas a otras personas. La idea del prototipo es crear un modelo que nos permita fallar y aprender barato. Podemos llegar a ser muy creativos a la hora de representar la idea de solución o cambio para poder posteriormente hacer un testeo con una persona o grupo de personas real. Una recomendación que siempre hacemos es que a la hora de realizar el prototipo reflexionar sobre las hipótesis que nos hacemos de lo que se va a producir si pusiéramos en marcha esa solución o acción de cambio.

Testear: ahora toca probar que nuestras ideas son aceptada por las personas afectadas por el cambio. Es normal que esta etapa conlleve iterar sobre el diseño, ya que lo que se busca es el feedback de las personas a las que les presentamos nuestra solución. Por tanto, el foco de esta fase es obtener feedback y que ver qué no funciona en nuestro el prototipo para lograr mejorarlo. ¡No intentar venderlo!

¿Cuál es nuestra experiencia usando Design Thinking en procesos de gestión del cambio?

Es importante entender que en nuestro enfoque de gestión del cambio, una vez que hayamos hecho la fase de levantar insight, buscamos cocrear un backlog de acciones o experimentos de cambio con las personas afectadas por el cambio. Por tanto, diseñar intervenciones con las personas afectadas por el cambio usando una mentalidad de Design Thinking nos permite introducir un hack cultural que nos lleva realmente al centro de nuestra filosofía de trabajo: permitir que las personas afectadas por el cambio se conviertan en facilitadores y con ello convertir la resistencia al cambio de un problema en un regalo que nos da la organización (cita que no es mía sino de Paul Tolchinsky).

De manera práctica, usamos el proceso de Design Thinking como una herramienta para diseñar el Flow de una intervención con un grupo de personas de la organización a la que estamos acompañando en un proceso de cambio. El entregable de una intervención usando el Design Thinking como enfoque, es la generación de un backlog de Opciones y experimentos de cambio que ha sido propuesto por las propias personas de la organización.

Nuestra experiencia usando herramientas de este tipo, es la generación de un alineamiento entre las personas de la organización con los objetivos de negocio de la misma, que al final, para nosotros, como agentes del cambio, es un eje estratégico de nuestro enfoque de hacer proyectos, sea la naturaleza del cambio que sea, desde ayudar a nuestros clientes en sus proyectos de transformación agile como incluso diseñar un proceso de cambio de otra índole.

En el corazón del Lean Change Management, está la puesta en marcha de un enfoque que nos pueda ayudar a la hora de definir, revisar e iterar sobre las aproximaciones de acciones de cambio, y siempre teniendo en mente la experiencia de las personas ante la transformación. Empatizando con las necesidades de las personas de la organización desde el principio, identificado sus puntos de dolor o sus experiencias actuales, incluso nos puede ayudar en identificar métricas para medir el impacto del cambio.

Un importante aprendizaje que nos llevamos al aplicar el mindset del Design Thinking como enfoque de nuestras intervenciones para definir acciones de cambio, es que estamos creando un espacio seguro para que las personas puedan conversar entorno a sentimientos o emociones que afloran en el día a día de la organización. Sin olvidarnos igualmente que un proceso LCM requiere tomar medidas sobre el impacto del cambio.

En definitiva, poner a las personas en el centro del proceso de cambio está en el core del enfoque de Lean Change Management, y es el eje fundamental para poder garantizar que realmente los cambios van a tener el impacto que la organización requiere, para adaptarse a la realidad del mercado o ámbito de actuación.

Artículo escrito por: José Antonio Ortega Barros

DevOps es ante todo Cultura, nipollas*

* ‘,nipollas’. Operador granaino unitario post-fijo de negación; x,nipollas == !x. Ej. si,nipollas == no

Estoy harto de encontrarme con publicaciones en las que se prioriza, por encima de cualquier otro factor, el cambio cultural como elemento fundamental de la transformación DevOps. Esta idea se ha convertido en omnipresente. Te pongo un par de ejemplos:

«La adopción de DevOps es un factor al 80% cultural, de esta forma, la cultura debería ser siempre tratada primero». CloudOps
«DevOps es una filosofía […] que prioriza personas sobre procesos y procesos sobre herramientas». Emily Freeman
«DevOps es cultura, […] cualquiera que te diga otra cosa te está vendiendo algo». Bridget Kromhout

Alguien que se aproxima al movimiento DevOps por primera vez tiene la impresión de que es una iniciativa diseñada por el ingenio de Agile Coaches, Change Managers y otros facilitadores de similar calaña. Y NO es así.

¿Cómo hemos llegado a este estado de cosas?

Quizás porque los técnicos están tan ocupados en crear soluciones que no tienen tiempo de publicar… No, en serio, dejo mi indignación aparte y me centro.

DevOps es hijo de su tiempo. Surgió hace diez años porque el contexto lo hizo posible. Por un lado, se sube a los hombros de dos modelos de desarrollo consolidados: Agile y Lean Development. Por otro lado, es posible gracias a la consolidación de las tecnologías que hacen posible las prácticas de Continuous Delivery: Cloud y Automation.

La comunidad Agile es muy prolífica en la creación de contenidos. Y se ha centrado, casi en exclusiva, en los aspectos organizativos y culturales. En parte se debe a una aplicación, a modo de mandamiento, del primer principio agile: «Personas e Iteraciones sobre procesos y herramientas». En parte, por falta de interés en la tecnología, que lleva a algunos agilitas a desentenderse de la realidad del trabajo diario en desarrollo y operaciones.

Lamentablemente, no me son extraños los mensajes en los que no se considera o se menosprecia la base tecnológica. A lo largo de mi carrera profesional, demasiado frecuentemente me he encontrado con el mantra de «nos centramos en el negocio, la tecnología es lo de menos». No puedo evitar esbozar una sonrisa cuando ejecutivos y managers se llenan la boca con la «Transformación Digital». Queremos mejorar la competitividad de la empresa empleado tecnologías punta como IoT, blockchain o big data. Pero esto, solo es posible contando con un equipo técnico con un alto grado de conocimiento práctico en el uso de las herramientas que las sustentan.

DevOps son Prácticas y Herramientas.

DevOps va de incrementar la productividad del equipo IT aumentando la velocidad de despliegue sin sacrificar la calidad de las operaciones. Evidentemente, que la organización tenga una cultura generativa, facilita este objetivo. De la misma forma que facilita la producción de la chirimoya salvaje. Pero, cuando hablamos de desarrollo y operaciones de software, la eficiencia solo es posible contando con la maestría en el uso de herramientas y prácticas como: arquitecturas desacoplados, gestión de la configuración, continuous delivery o monitorización. Señ[email protected], esto no se puede hacer solo con buenas intenciones y post-it.

Hablemos de gestionar la transformación DevOps. Buscamos eliminar los bloqueos característicos de las transferencias de responsabilidad. Para eso, es imprescindible romper con los nichos de conocimiento. Y, la forma en la que los profesionales de IT intercambian conocimiento es formalizado en herramientas y artefactos. Un desarrollador será autónomo en la configuración de sistemas, cuando haya practicado en pairing con su compañero de operaciones, disponga de los playbooks de Ansible en el repositorio centralizado Git y pueda lanzar en Jenkins los test automáticos de integración sobre un entorno aprovisionado a demanda con Vagrant.

Pero es más. Los técnicos vemos la realidad a través de las herramientas que utilizamos (si, somos así de simples). He perdido la cuenta de las ocasiones en las que una nueva herramienta me ha facilitado entender una forma distinta de realizar mi trabajo, ha cambiado mis prácticas y, finalmente, ha impactado en mi entorno cultural. Sin contarte la mili: SCM, IoC, SOA, Test automáticos, motores de integración, cloud, contenedores, orquestación, …

Si, DevOps es también cultura.

No voy a negar la importancia de la cultura en el entorno de trabajo. Para mi, cultura y organización son sinónimos. Como parte de mi trabajo, en muchas ocasiones he presentado la compañía a nuevos compañeros. Y, lo que les he contado son los valores y objetivos, las prácticas y las reglas tácitas. Es decir, les he descrito la cultura de mi organización.

Una cultura generativa es fundamental en una industria, como la nuestra, que vive del talento. Pero la cultura es un concepto principalmente abstracto sobre el que es muy difícil de actuar de forma directa. En su lugar, podemos cambiar nuestra forma de trabajar y que el día a día imponga una forma distinta de hacer las cosas. El cambio debe estar permitido por el nivel ejecutivo y facilitado por managers y agilitas. Pero se producirá, de abajo hacia arriba, desde los técnicos.

«No puedes cambiar la cultura actuando directamente sobre ella, pero puedes cambiar las prácticas y éstas se convierten en cultura» – Lloyd Taylor

Y a las pruebas me remito. La señora Nicole Forsgren en su trabajo Accelerate (faro del movimiento DevOps), identifica científicamente las relaciones causa-efecto que empujan la transformación DevOps. Y lo que encuentra, es una relación de predictibilidad entre la aplicación de prácticas DevOps y la cultura de la organización (no al revés).

Bueno, al final, me quedo con los dos.

Si piensas que no tengo criterio, estás en lo cierto. Estoy convencido las herramientas y prácticas DevOps son fundamentales para el cambio cultural. Pero este, a su vez, es necesario para consolidar y escalar a toda organización. Ambos factores, correctamente cuidados por técnicos y agilistas, se realimentan en un bucle positivo que es el auténtico motor del cambio DevOps.

Imágenes de: Aaron Blanco, Icon8 y Burns todos en unsplash.com

Lean Change Management para generar alineamiento

Autor: José Antonio Ortega Barros

Cuando empecé a aplicar el enfoque de Lean Change Management en los proyectos de gestión del cambio que facilitaba, me llamó la atención el fuerte énfasis que se hacía al uso de Canvas o lienzos, para la generación de conversaciones que permitiesen el alineamiento entre las personas afectadas de manera general por los cambios. ¿Pero, es tan importante que Lean Change Management para generar alineamiento en la organización ante la implantación de un cambio? ¿qué opina el lector?

A lo largo de mi trayectoria, me he encontrado con muchas organizaciones que implantaban cambios, y muchas personas afectadas por los mismos no tenían realmente claro cuál era el propósito ni las razones fundamentales para efectuar ese cambio. Lamentablemente, lo normal es encontrarnos con proyectos de gestión del cambio, en dónde el propósito e incluso los nuevos planteamientos de cambios organizativos, son elaborados en extensos documentos por consultores externos. ¿quién no ha vivido algo así?

¿En qué consiste Lean Change Management?

Pero antes de seguir vamos a recordar brevemente en qué consiste LCM. LCM es un framework de gestión del cambio, planteado por Jason Little, que se sustenta sobre todo en disciplinas como Lean Startup y Design Thinking. LCM parte de la base que es complejo predecir el impacto de un cambio, y por tanto en lugar de un tener un plan cerrado en tiempo y alcance, es mejor disponer de un backlog de cambios y al introducir esos cambios, como si de experimentos se tratasen, ir modificando la estrategia de cambios en base al feedback recibido (aprendizaje validado).

Como resumen, el ciclo LCM es el siguiente

El framework se basa en la búsqueda de Insights (hallazgos que vamos aflorando de la organización relacionados con el propósito del cambio) que permiten plantear opciones de cambio, de los cuales extraemos experimentos de cambios que posteriormente se tendrían que introducir en la organización. La clave, es que al poner en marcha los experimentos, el feedback recibido será fundamental para reajustar todo el contenido del framework (hallazgos, opciones y experimentos). Al final lo que buscamos es que los cambios se vayan introduciendo en un proceso evolutivo que permita que la organización vaya absorbiéndolos de una forma más natural y sistémica.

Un valor importante sobre él, que sustenta el modelo desarrollado por Jason, y que yo comparto totalmente con él, es la de hacer participar a la organización afectada por el cambio en el propio diseño del cambio e incluso, e igualmente importante, en la generación de conversaciones para permitir el alineamiento de los equipos de personas afectados por el cambio, en contraposición a los modelos prescriptivos, en donde son personas o consultores externos que lo definen todo.

¿Por dónde empezar para crear alineamiento?

El paso inicial es identificar la visión para el cambio. Pero esto no es nada nuevo. En cualquier modelo como él de Kotter o CAP ya se hace hincapié en la necesidad de crear alineamiento. La diferencia radica en cómo se lleva a cabo. En mi caso, yo suelo hacerlo a través de sesiones facilitadas, tanto para generar conversaciones que permiten definir el propósito, como para compartirlo con los equipos.

¿Pero por donde empezamos? En LCM nos sugieren usar el Canvas estratégico.

Este Canvas, lo suelo usar para dos cosas:

Permitir que el equipo directivo o responsables del cambio reflexionen sobre el propósito del cambio
Posteriormente, uso este Canvas para crear conversaciones con el resto de los equipos, ya que hemos visto un cambio importante de actitud cuando generamos conversaciones entorno al propósito con los equipos afectados por el cambio.

De manera general, suelo facilitar las conversaciones entorno a este Canvas usando diferentes técnicas, que suelo escoger en función de múltiples factores, cómo tiempo o disponibilidad de los diferentes equipos.

Las mejores sesiones que he experimentado se han dado cuando pude trabajar tanto con los equipos directivos, como posteriormente con los equipos de personas afectadas por el cambio, ya que facilitaba de una manera considerable el alineamiento para el cambio. Al término de una sesión de este tipo, termino con una serie de preguntas para intentar cerrar todos los flecos:

¿Quién debería de ser involucrado en las conversaciones?
¿Qué trabajos se requieren realizar?
¿Qué conversaciones todavía quedan pendiente?

En mis talleres suelo usar una versión del Canvas estratégico “tuneado” en relación a la versión original de Jason. Pero de eso se trata, que cada uno lo pueda ajustar cómo crea más oportuno. Dejo en enlace para descargar el Canvas estratégico original LCM.

Pongo a continuación alguna foto como ejemplo de una sesión con directivos.

Alineamiento con una perspectiva más táctica

Hay otro Canvas que suelo utilizar para trabajar a nivel de equipos, ya que es importante entender que crear alineamiento no es cuestión de un solo taller. Al contrario, crear alineamiento es una actividad continua durante todo el proceso de cambio, para garantizar que la organización interiorice la importancia del cambio y su participación en su puesta en marcha.

A nivel de equipos, suelo usar otro modelo propuesto por Jason, con el objetivo que los equipos puedan participar en la identificación de qué cambios se van implantar o en la estrategia de implantación. Una vez conversado con los equipos sobre el propósito de los cambios, suelo introducir un Canvas más operativo de tal modo que todos puedan participar de manera más táctica. Mi sorpresa, en general, es encontrarme que normalmente los equipos suelen tienen conocimiento para saber qué cambios aplicar. En caso de no existir ese conocimiento, entonces ayudo a los equipos a identificar necesidades de formación.

A efectos de facilitar este tipo de taller, suelo usar la lista de evaluación de Adkar para ayudarme a facilitar un taller de tipo operativo. Esta lista me permita ir validando aspectos necesarios o que tengo que aflorar durante el taller.

Según Adkar, si alguna de las condiciones de la lista es débil el cambio no prosperará.

Hay conversaciones muy potentes que se tienen que dar con este lienzo, tales como:

¿Qué personas o procesos de negocio son de apoyo al cambio que se quiere acometer?
¿En dónde van a aparecer resistencias?
¿Qué puede hacer nuestro equipo para apoyar este enfoque? O ¿qué ayuda se requerirá y de quién?

Este Canvas va a requerir mediciones, ya es ideal llevar al equipo a pensar en cómo medir el progreso y el éxito, y siempre y cuando se pueda, recomiendo que sea el equipo quién defina los indicadores no los directivos.

No quisiera que el lector se quede con la idea que este Canvas sólo se utiliza en una especie de “one shot” workshop, de hecho, mi recomendación es que este Canvas se convierta en la herramienta que tenga el equipo para que se haga responsable de los cambios que les afecta. Esto es algo que insisto mucho para lograr escalar los cambios. Aquí dejo el enlace al Team Change Canvas.

¿Informes de seguimiento del cambio? ¡No! ¡Por favor!

Cuando nos iniciamos a usar LCM en nuestros proyectos, seguimos la sugerencia de Jason de dejar de hacer informes de seguimiento, y en su lugar usar un Canvas que fuese un sistema vivo, y que sirviese de mecanismo de comunicación entre los diferentes equipos. En LCM, este Canvas se denomina “One Page Change Plan” y es una herramienta muy potente para visualizar el estado de los cambios que se están implantando. Este Canvas sustituye perfectamente los informes de seguimiento. Dejo en este enlace para acceder al formato de One Page Change Plan.

Por último…

Como he mencionado al principio de este artículo, desarrollar una estrategia de cambio o crear alineamiento ente los equipos no es nada nuevo. Es posible que, para muchos la novedad consista en crear entornos de conversación para que tanto los directivos, el equipo de gestión del cambio como las personas afectadas por el cambio puedan compartir sus perspectivas.

Este proceso lleva más tiempo que un modelo prescriptivo, en donde todo viene predefinido por consultores externos, pero el resultado de este último modelo es mucho más incierto. La ventaja de usar un modelo como LCM es que vamos recogiendo el feedback de los cambios que se van introduciendo, y por ende, cualquier conversación que genere con los equipos serán fuente de hallazgos, y como no, de cambiar el eje de las opciones y experimentos si fuese necesario. La potencia de usar Lean Change Management es crear un entorno evolutivo de cambios que permita que los equipos de personas puedan ir absorbiendo los cambios de una forma mucho más productiva para el resultado que se busca.

Autor: José Antonio Ortega Barros