¿Hay algún ejercicio para detectar como puede impactar un cambio organizacional a la motivación de las personas?

Recientemente asistí a un meetup del club de lectura de Madriagil en que hablamos sobre el libro de Management 3.0. Como taller basado en el libro, hicimos un ejercicio con los Moving Motivators que Jurgen Appelo inventó para reflexionar sobre la motivación y cómo se ve afectada por un cambio organizacional como lo es una transformación ágil. El ejercicio se basa en los diez deseos intrínsecos derivados de los trabajos de Daniel Pink, Steven Reiss y Edward Deci.

El ejercicio se hace en tres pasos:

Primer paso: ¿Qué motivadores son importantes para ti? Coloca las tarjetas en orden de izquierda (menos importante) a derecha (más importante).

Paso dos: ¿Cómo puede un cambio afectar a tus motivadores? Mueve la tarjeta hacia arriba para un cambio positivo y hacia abajo para uno negativo.

Paso tres: El cambio organizacional se refleja en tus motivadores. Cuando la mayoría de tus motivadores importantes aumenten y bajen los menos importantes, el cambio es bienvenido y positivo. Es una manera de identificar a las personas con las empezar e iniciar el cambio, ellos reforzaran e influenciarán a los demás.

Patrón de desplazamiento de los motivadores de un curioso y posible promotor del cambio

Cuando la mayoría de tus motivadores importantes disminuyan, o cuando suban los menos importantes, es posible que tengas que plantearte algo...

En el meetup aplicamos el ejercicio a un supuesto cambio organizacional que llevaría a nuestra compañía a una cultura como la de la empresa de desarrollo de videojuegos Valve, una de las empresas más ágiles del mundo, incluso teal según los paradigmas organizacionales descritos por Frederic Laloux.

Juego completo de cartas Moving Motivators de Managment 3.0

Cada participante averiguó los cambios en sus motivadores con una baraja propia, barajas cuyas tarjetas distribuimos cada uno en paralelo sobre sola mesa. El objetivo era saber cómo los cambios afectaban al grupo completo de participantes. Si el cambio concordaba potenciando los motivadores principales de la mayoría, el cambio sería muy bienvenido y fácil de implementar.

Después de los tres pasos cada participante "visitó" las tarjetas de los demás, y por turnos cada uno explicó a su orden de los diez motivadores. Esta técnica pone de relieve el interés del grupo y evita reuniones, además, nos ayudó entendernos y a aprender unos de los otros.

En general el cambio coincidió con los motivadores de los participantes, en muy pocos no fue así, me llamó la atención que no fuera así para aquellos en que las relaciones y la aceptación no son motivadores importantes. Por otro lado fue interesante percibir la diversidad que suele haber en los grupos, aunque pudiéramos pensar que todos los motivadores pudieran ser importantes, para algunos ciertas motivaciones no lo eran en absoluto, simplemente no les importan. Esa diversidad también se hizo patente porque las principales motivaciones resultaron bastante diferentes entre unos y otros. La diversidad es un de los factores que hace que los equipos sean mucho más que sus partes, y es muy valioso para un equipo conocer y entender las diferencias entre sus miembros, y ahí es donde el ejercicio puede resultar muy útil para un Scrum Master.

Descargas / Downloads

Un ejercicio con el escenario de la empresa Valve para probar como funcionan los motivadores.

¿Cómo centrar a los participantes para una reunión?

Un cuenco tibetano que con su sonido nos lleva a la meditación

Uno de los problemas que observo una y otra vez en la fase inicial de las transformaciones ágiles es que en las reuniones, especialmente en las de nivel de escalado como PO-Sync y POCLAC, los asistentes vienen corriendo, acelerados y pensando en lo siguiente a la reunión. La convivencia de culturas y de reuniones ágiles y no ágiles crean estrés, una sensación de caos e incertidumbre con la que hay lidiar.

Suelen abrir sus ordenadores durante la reunión para contestar frenéticamente emails o atender otras cuestiones con lo que no están realmente presentes... Una directiva me pidió ayuda, decidí pedir ayuda a mi compañera María para hacer una microsesión de 5 minutos de Mindfullness acompañada del sonido vibrante de un cuenco tibetano. Es sabido que esta vibración ayuda a reducir la ansiedad y aliviar el estrés, mejora la concentración, equilibra los hemisferios cerebrales, mejora la creatividad, alivia los dolores de cabeza, ayuda a equilibrar el sistema endocrino y equilibra y limpia el aura y los chakras de las personas. :-)

El cuenco que me ha encontrado a mi :-) - Gracias María

Antes de empezar la reunión dejamos el cuenco a la vista sobre la mesa para que todos lo vieran a medida que llegaran a la sala de reuniones; resultó que llamó la atención y preparó a los asistentes para abrir la mente a lo que vino después.

Un fuerte "gong" inició la sesión y todos se sentaron alrededor de la mesa de reuniones. Les invitamos a cerrar portátiles, poner los móviles en silencio y a sentarse de forma cómoda con los pies bien planos sobre el suelo.

Con un golpe suave y recorriendo el borde del tazón con un mazo o baqueta este vibró llevándolos a un estado de meditación. Con voz muy suave, apenas un susurro, guiamos a los asistentes en los diferentes pasos que deben seguir para lograr una relajación completa (técnica de modelado simbólico):

• Cerrar los ojos.
• Fijarse en la respiración, ser conscientes de las inspiraciones y expiraciones profundas con el diafragma; la respiración es la puerta de entrada de la meditación.
• Fijarse en como el aire entra y sale por la nariz, en la diferencia de temperatura.
• Entrenamiento autógeno, visualizando imágenes relajantes e imaginándonos en un lugar que nos relaje.
• Dejarnos llevar...

Después de 3 minutos los asistentes estuvieron relajados y centrados, la sesión:

• Cambia el cerebro de forma positiva.
• Reduce la actividad de la amígdala (ira, estrés…).
• Aumenta el funcionamiento de la corteza prefrontal (empatía, toma de decisiones).
• Incrementa el aporte de oxígeno al cerebro, lo que beneficia también al aprendizaje.
• No permite que nuestras emociones nos tomen de rehenes.
• Nos ofrece un cambio de perspectiva en la manera de manejar los conflictos.

La reunión fue más resolutiva y creativa que nunca, a algún directivo se le erizaron los pelos, jajajaja... pero más de uno nos pidió la sesión previa para sus reuniones.

Mis agradecimientos a Patricia por dejarme el cuenco y a mi compañera María, que me proporcionó material para el post :-*

¿Cómo incrementar la capacidad de un equipo ágil?

Los equipos ágiles son equipos ganadores - благодаря Sanya

Sabemos que no hay nada más potente que un equipo empoderado, autoorganizado, autogestionado y multifuncional que entrega software de valor, testado y funcionando con cada sprint y que opera bajo un marco ágil como Scrum. Pero, ¿qué hacer si quisiéramos aumentar la capacidad del equipo?

Los miembros del equipo son los responsables de ejercer influencia en la composición del equipo, haciendo recomendaciones sobre cómo incorporar o sacar personas del mismo. En cualquier caso si queremos aumentar la capacidad del equipo hemos de contar con ellos, al fin y al cabo sus miembros saben de la realidad de su entorno y son los mejores para encontrar soluciones. Para ello podemos plantear la necesidad en la siguiente retrospectiva, o también convocar una reunión ad-hoc.

Con una actividad de brainstorming el equipo propondrá ideas, quizá incorporar un miembro nuevo, una persona más de java o un maquetador, o quizá recursos o herramientas que puedan acelerar su velocidad.

Seleccionada una de las ideas habremos de indagar con recursos humanos o con ingeniería los costes que supone al incorporación de un nuevo técnico o de una nueva herramienta. El Propietario del Producto es el responsable de la presupuestación de personas y recursos, él habrá de analizar el impacto de los costes asociados que darán más capacidad al equipo y aprobarlo o rechazarlo, quizá, hecho el análisis, no haya necesidad de incrementar la capacidad del equipo.

Si la solución fuera ampliar el equipo, recordemos que no debemos de pasar de 9 miembros, deberemos de contar con recursos humanos para que provean de técnicos con las habilidades demandadas, pero debe de ser el equipo quien decida la persona a incorporar, al fin y al cabo son ellos los que van trabajar con ese nuevo miembro.

¿Cómo lograr la atención en un evento?

Cuando como trainers, Scrum Masters o coaches ágiles conducimos algún evento o actividad de equipo o tribu, es necesario que en ciertos momentos el grupo escuche una explicación, una instrucción u cualquier otra información que queramos compartir. Imaginemos que en un Town-Hall, una PI Planning, un bootcamp, un Open Space o una clase necesitamos llamar la atención, en esas situaciones gritar no sirve, necesitamos una herramienta para crear silencio de forma rápida.

Para ello quiero mostrar una técnica de coaching muy simple, llamada silencio viral o silencio autoorganizado. Explico a todos los asistentes al inicio del evento que si en algún momento necesito dirigirme al grupo, voy a levantar una mano, y cuando ocurra esto todos levantamos la mano y a medida que lo hacemos dejamos de hablar para prestar atención. Esto será valido para cualquier persona que quiera dirigirse al grupo.

• Una persona, trainer, coach o asistente que tenga algo que decir levanta su mano derecha.
• Los demás asistentes también levantan su mano derecha, los coaches suelen estar más atentos y son los primeros en reforzar al iniciador.
• Todos los asistentes colaboran para lograr el silencio dando un ligero toque a aquellos compañeros que todavía sigan hablando, puede que no se hayan dado cuenta o simplemente que sigan hablando pese a tener la mano levantada.
• Debemos de esperar a que todos tengan la mano levantada y haya absoluto silencio.
• Finalmente el iniciador baja la mano y expone lo que tenga que decir.

Silencio viral o autoorganizado - cortesía de Pixbay

Es una buena técnica que fomenta el respeto por otras personas que deseen expresar algo, y también hace que aprendamos a escuchar.

El uso continuado de la técnica crea una especie de condicionamiento, que cuando se produce el estímulo y alguien levanta la mano, se produzca automáticamente el silencio, muchos de los agilistas que acudimos a eventos y ceremonias de Agilidad ya lo llevamos incorporado. :-)

¿Cómo experimentar un proyecto con cascada y luego con Scrum?

Este es un ejercicio del curso Scrum de

El producto:
tarjetas de invitación de cumpleaños

Una de las formas más potentes para experimentar Scrum es hacerlo mediante la comparación. Primero experimentar la construcción de un producto por fases en cascada, para luego vivir la construcción del mismo producto mediante sprints que incorporen feedback y aprendizaje de forma natural.

Alexandre Magno ha ideado la simulación que expongo en este post, me parece excepcional, la hemos liderado juntos y la voy a incluir en mis cursos de Scrum. Para poner contexto explicamos a los asistentes que nuestro hijo quiere invitar a 12 amiguetes a su cumpleaños y necesita 12 tarjetas de invitación. Resulta que le hace mucha ilusión que las invitaciones tengan un payaso sonriente pintado en la portada.

Primera ronda de construcción en cascada

Dividimos a los asistentes en cuatro equipos, y a cada equipo le asignamos una tarea en concreto. Un quinto voluntario hará de tester.

Especialista de coloreado trabajando

• Equipo 1: dobla y corta una hoja A4 en 2 cuartillas
• Equipo 2: dibuja un payaso
• Equipo 3: colorea al payaso
• Equipo 4: prepara en la parte interior de la cuartilla áreas para el nombre del niño invitado, la fecha y la dirección de la fiesta
• Tester: le damos el payaso original y comprobará la calidad de cada una de las tarjetas construidas

Pedimos a cada equipo una estimación del tiempo que piensa que necesita para desarrollar su tarea específica para crear 12 invitaciones, y los tiempos los apuntamos en un tablero.

Las fases de construcción las harán de forma secuencial, el equipo 2 por ejemplo habrá de esperar a que el equipo 1 acabe completamente con su trabajo. En la simulación los equipos que no están trabajando estarán ociosos, no es buena cosa. En la realidad esos equipos, o sus miembros, probablemente estén trabajando en otros proyectos, situación que tampoco es deseable, porque cuando el equipo que está en curso haya acabado seguramente el equipo que les siga estará en otra cosa que no habrá acabado todavía. Lo que suele ocurrir en nuestras realidades es que estamos llevando a los equipos al trabajo, y eso no siempre cuadra, ya que planificamos los proyectos en función de la disponibilidad de las personas.

Tablero con los tiempos estimados, que suman 19
minutos, y los tiempos reales de ejecución que
suman aproximadamente 11 minutos

Cuando el equipo 2 haya terminado su trabajo, nos paramos y preguntamos a la sala cuál es el % de progreso. Según los tiempos estimados versus los hechos, suelen decir que están alrededor de un 30% de trabajo hecho, pero no es cierto ya que no probablemente no habrá ni una sola invitación terminada.

Es buen momento para trabajar la diferencia de enfoque entre proyecto y producto, por tanto que en la gestión de proyectos medimos el progreso por las actividades hechas, y que en Scrum medimos el progreso por los incrementos de producto terminados.

Una vez el equipo 3 haya acabado de colorear los payasos, introducimos un cambio, explicamos a los asistentes que resulta que los niños dicen que sería guay si algunas de las invitaciones tuvieran en su portada a Mickey Mouse.

Los asistentes a la simulación protestarán, dirán que habría que volver empezar desde cero, que no pueden ni aprovechar el trabajo del equipo 1, las hojas dobladas y cortadas en cuartillas, porque el proceso es en cascada y todas las cuartillas ya tienen pintadas al payaso...

Si insistimos en que los niños están demandando a Mikey dirán que es un cambio de alcance, y que es posible si como cliente estamos dispuestos a desembolsar una cantidad similiar al proyecto original. Como ocurre con nuestros clientes en la realidad, un cambio tan pequeño como introducir a Mickey, se convierte el inviable y como cliente nos conformamos con payasos en todas las invitaciones. :-(

Simulación en la que solo 1 de los 12 payasos pasó calidad

Los equipos siguen trabajando en el proyecto original y acaban por construir las 12 invitaciones.

Finalmente entra en escena el tester que comprueba las invitaciones una a una, comparándolas con la original. Como ocurre en un proyecto en cascada, no podemos obtener feedback hasta el último momento, y como no hemos tenido oportunidad de contrastar, las invitaciones no cumplirán con la calidad y este suele desechar muchas invitaciones... Mostramos y debatimos sobre las diferentes problemáticas que ha detectado el tester.

El equipo 1, cuya tarea es doblar y cortar, suele sentir que ha hecho un buen trabajo, que el fallo no está en ellos, su responsabilidad solo era doblar y cortar y eso está bien hecho.

Los que dibujan y colorean payasos probablemente se sientan mal, porque los fallos o carencias de calidad seguramente estén en sus tareas. En la realidad la situación empeora cuando para solucionar el problema las empresas segregan responsabilidades y definen nuevos especialistas con la idea de garantizar la calidad. Se crearán especialidades como el dibujador de caras de payaso, o el coloreador de pelo... en definitiva una sobrecarga de especialistas y de especialidades que reducirá toda colaboración en y entre los diferentes equipos.

Segunda ronda de construcción con Scrum

Definición de hecho y un cuadro con las
invitaciones que cada equipo estima por sprint

La segunda ronda trata de la construcción de las 12 invitaciones mediante 4 sprints, en los que cada equipo construye tantas invitaciones como considera le puedan caber en un sprint de minuto y medio.

Les damos una hoja A4 a cada equipo y le invitamos a que trabaje como equipo autoorganizado y multifuncional, y que construya invitaciones de principio a fin. En un tablero anotamos cuantas invitaciones creen que pueden hacer en el primer sprint. Es el momento de introducirles que el el primer sprint es de calibración y que trata principalmente de encontrar su capacidad real, su velocidad.

Suele ocurrir que en el primer sprint no hayan aprendido todavía a colaborar, y a final del mismo no haya ninguna invitación terminada.

Entre sprints hacemos una retrospectiva de medio minuto donde les invitamos a hablar sobre como han trabajado, que ha ido bien, que no y que busquen al menos una mejora para el próximo sprint. Es el momento en el que como trainer podemos incluir dos sugerencias:

Equipo coloreando verdaderamente de forma ágil,
todos focalizados a la vez en la misma invitación

• Introducir un límite WIP de 1, instarles a que hagan una invitación tras otra y no inicien varias invitaciones a la vez
• Y recordarles que el trainer es a la vez el Propietario del Producto, y que en cualquier momento pueden pedirle feedback

Ocurrirán cosas como lo que se puede ver en la foto de la derecha, los equipos encontrarán caminos para la colaboración, llamarán al Propietario del Producto para enseñar las invitaciones y tomar feedback, mejorarán las invitaciones con cada sprint y también mejorarán la forma de como colaboran. Se generará un ambiente alegre y colaborativo con un campo emocional muy energético... lo suelen pasar muy bien.

10 invitaciones exitosas resultantes de los 4 sprints, todas
ellas son un éxito desde la perspectiva del contento de los niños

En el segundo sprint introducimos la petición de los niños de pintar algunas invitaciones con Mickey en la portada. En este punto los asistentes descubren que introducir a Mickey no tiene coste añadido alguno, como mucho puede pasar que haya que descartar alguna invitación de payaso no terminada.

La disponibilidad del Propietario del Producto y la interacción con el mismo hace que florezca la creatividad de los equipos y se produzcan invitaciones cada vez mejores para su propósito: ser atractivas para los niños y animarles a venir a la fiesta de cumpleaños. :-)

Esta simulación permite introducir los conceptos subyacentes al proceso de Scrum y compararlos con los procesos en cascada que conocen de su día a día. A lo largo de la formación, o acompañamiento posterior, podemos referirnos a situaciones vividas en la simulación, referencias que en la mayoría de los casos son muy esclarecedoras y fáciles de comprender para los asistentes, y ayudan potentemente a fijar el conocimiento recién obtenido.

Mis agradecimientos a los asistentes al curso del noviembre de 2017 por ilustrar este post

¿Un coach ágil es un rol a tiempo completo?

Cortesía de Pixabay

Como ya hemos visto, un Scrum Master está comprometido con el proceso y las personas de los equipos, un coach ágil solo está involucrado con estos equipos, pero está comprometido con el equipo de equipos o tribu, y con la transformación ágil de la que forma parte.

Un coach ágil tiene sentido en una compañía cuando está al frente de al menos 5 equipos de desarrollo, de una tribu de alrededor de 50 personas. En ese escenario el coach ágil es absolutamente necesario a tiempo completo, por supuesto durante la implantación pero también durante toda la consolidación de la Agilidad, que suele ocurrir en alrededor de los primeros 21 sprints.

Empezará liderando los primeros pasos en Scrum, luego acompañará a aquellos equipos con más dificultades reforzando relaciones e involucrando a los interesados, lidiará con impedimentos mayores en las fronteras de la tribu, especialmente con directivos de otras áreas no ágiles. Ese tipo de impedimentos requieren mucho tiempo de un coach ágil porque ha de lidiar con directivos, que suelen ser muy ejecutivos, y con las frustraciones de los equipos. Finalmente establecerá y asentará los eventos a nivel de tribu, como reuniones de sincronización de Propietarios del Producto, planificaciones cruzadas con todos los equipos y otros como reuniones de desarrollo de tribu y sus equipos como lo es POCLAC por ejemplo.

Tiene que estar continuamente zambullido en el sistema desde una perspectiva holística, sentir el latido de cada equipo y conocer su campo emocional. En momentos de cambio, que son frecuentes en una transformación ágil, se hace necesario el acompañamiento de personas y coaching de los equipos ya que es cuando más conflictos y malentendidos se suelen producir. Si como coach ágil detectamos un problema de forma tardía, cuando te pones a ello, este ya ha iniciado su propio camino, ha divergido de la Agilidad y costará más tiempo y esfuerzos corregirlo.

Ha de asistir a todas las reuniones clave, cuando se produce una crisis ha de estar y las crisis son imprevisibles. Es especialmente importante que asista a las que no tienen su origen en la Agilidad, esas son peligrosas ya que en estas puede ocurrir que se tomen decisiones no alineadas con la Agilidad. Una disfunción importante es cuando el coach ágil confronta a otros con la realidad no ágil y luego no está parea acompañarlos en la resolución, como por ejemplo poner sobre la mesa la falta de entrega en las revisiones de sprint y luego no estar...

Una de las responsabilidades más importantes del coach ágil es redefinir las estrategias de transformación y redirección a todos los niveles en base a los resultados de la mejora continua, hacer seguimiento de la evolución y tomar las medidas adecuadas. Si el coach ágil no está a tiempo completo tendrá el foco en lo trivial, en los problemas más evidentes, en cosas como si se aplica correctamente Scrum, perdiendo de vista los problemas de fondo, donde realmente un coach ágil puede aportar valor y hacer que la transformación ágil sea un éxito.

La carencia más común en las empresas españolas es la gestión de personas. Es por ello que un coach ágil aquí es mas importante que en otros países, somos muy flexibles en cultura y sociedad, y aunque la Agilidad sea más fácilmente comprendida aquí, es mas fácil que los directivos diverjan y vuelvan a sus roles anteriores, como por ejemplo que en Chapter Leads y Propietarios del Producto emerjan comportamientos de jefe de proyecto. Un directivo alemán o inglés habrá aprendido su nuevo rol e intentará no salirse de sus responsabilidades con Agile, aunque no lo comprenda.

¿Cómo se coordinan los Propietarios del Producto en una PO-Sync?

Guía para la PO-Sync, gracias David Jiménez

Uno de los principios de escalado trata sobre la cadencia y sincronización, cuando escalamos con varios squads que construyen partes de un mismo producto o partes de productos relacionados, es necesario sincronizar a los diferentes Propietarios del Producto de la tribu. Para ello en varios marcos de escalado se lleva a cabo una reunión de sincronización de Propietarios del Producto, la PO-Sync. Pueden asistir también interesados en el producto y otros expertos si fuera indicado.

Esta reunión es timeboxed, con alrededor de una hora de duración, y se realiza con una frecuencia semanal, o mayor si fuera necesario. La facilita un coach ágil o un Propietario del Producto que haga de coordinador, rol que a veces se conoce como Product Manager.

El principal objetivo de la PO-Sync es obtener visibilidad sobre el avance de la tribu en la construcción del producto y con el cumplimiento de los objetivos OKR (Objectives and Key Results) acordados en la planificación cruzada Town-Hall:

• Hacer seguimiento de y actualizar las dependencias, y evaluar si el plan se ve afectado
• Actualizar los riesgos no resueltos, tratar los que puedan haber aparecido recientemente y evaluar si el plan se ve afectado
• Analizar problemas y oportunidades surgidas con el desarrollo de las features/epics
• Evaluar posibles ajustes de alcance y/o de prioridad
• Actualizar el tablero Kanban del equipo de Product Management
• Tratar otras cosas relevantes para compartir

La reunión también sirve para preparar el próximo Town-Hall y puede incluir el refinamiento y repriorización de elementos de la pila de producto escalada (features/epics).

Igual que en la reunión diaria pueden emergen temas que no son del interés de todos, en este caso debemos de tratar esos tema solo con los Propietarios del Producto interesados en una reunión posterior.

¿Cuál es el mayor reto para los directivos en una transformación ágil?

De autoridad a líder, un gran reto - cortesía de Pixabay

Uno de los puntos críticos para que sea posible una transformación ágil es el compromiso y la implicación de los directivos de la compañía en la misma. El éxito de la transformación dependerá esencialmente de su liderazgo.

Las compañías que inician una transformacion ágil son compañías en las que los empleados saben más del trabajo a hacer que los directivos que las lideran. Son compañías donde la fuerza de trabajo se basa en trabajadores del conocimiento, donde el trabajo implica la mente y no la fuerza mecánica de las personas.

Como directivos no podemos gestionar a personas que saben más del trabajo que hay que hacer que nosotros, lo único que podemos hacer es liderarlos.

Liderar implica:

• Confiar en ellos
• Darles autonomía y poder de decisión en todo aquello que ocurre y les afecta a su nivel
• Crear un entorno seguro para el aprendizaje continuo

El aprendizaje es importantísimo para una compañía competitiva, es la manera de innovar y mejorar de forma continua tanto sus productos como su proceso, la forma de trabajar. Este aprendizaje solo se adquiere mediante la experiencia y el feedback continuo. Ha de ser así para que el producto sea un producto que encuentre eco en mercado, y para que la forma de trabajar sea la más eficiente y motivante posible en consonancia con las singularidades de compañía.

Para aprender desde la experiencia hay que explorar continuamente, y fallar tempranamente para que cada fallo sea una oportunidad de aprendizaje, y por tanto una oportunidad de mejora que impulse la creatividad y la innovación.

El reto más importante para un directivo tradicional es transformar su entorno en un entorno seguro que fomente la colaboración y el aprendizaje. En un entorno tradicional nadie desea colaborar porque cuando a cada uno se le mide por sus responsabilidades individuales nadie quiere verse salpicado por un fallo que no es de su responsabilidad. En un entorno seguro fallar no está penalizado, fallar forma parte del aprendizaje y de la mejora continua.

Pensemos que los entornos tradicionales han llevado a las personas a tener miedo a fallar y su comportamiento se ha condicionado por las consecuencias que implica fallar. En un entorno así las personas no son capaces de tomar feedback, cualquier feedback se interpreta como una crítica y se sumergen en justificaciones y excusas.

En muchos caso sabemos que si las cosas no van bien nuestro directivo buscará responsabilidades en sus empleados. En las compañías con ese estilo de directivo las cosas no suelen ir bien y los empleados sienten que el directivo sacrificará a su gente por los números...

Ahí está el reto más importante para el directivo, lidiar con ese sentimiento, porque el permitir el sacrifico de su gente para proteger otros intereses se refuerza con el sentimiento de haber violado la definición de liderazgo, y que además puede hacer aflorar el sentimiento de la ofensa.

El reto para conseguir un entorno adecuado pasa por hacer sentir las personas a cargo del directivo que está para darles apoyo, y que cuando las cosas vayan mal, les protegerá, que sacrificará los números por su gente. Un líder cuida de su gente, cuando alguien tiene problemas con el rendimiento le hacen coaching y le dan el soporte necesario. Cando la gente se siente segura y protegida por el directivo la reacción natural es la de confiar y colaborar.

Hay una historia de un teniente que ante una situación de pocos víveres dijo que primero comieran los soldados, y luego ya comería el. No quedó comida para el... pero los soldados juntaron cada uno un poco de su comida y se la dieron al teniente.