Cómo liderar el cambio desde la base del organigrama

Este artículo está dedicado a los agentes de cambio que trabajan al nivel de implementación; los que ejecutan. Ya sabéis, ¡la gente que hace que el trabajo salga adelante! Espero que estas ideas os ayuden a identificar a profesionales dentro de vuestras empresas que estén teniendo dificultades para poner en práctica nuevas ideas. Si vosotros mismos trabajáis a nivel de implementación en una empresa con múltiples niveles de gestión y una cultura jerárquica, estas sugerencias pueden daros alguna que otra idea para vuestras iniciativas.

Veamos cuáles son las ventajas y desventajas de estimular el cambio desde esta posición. En lo positivo, al trabajar en implementación, podréis implementar los cambios directamente, algo que la gente que trabaja en gestión no puede hacer. También sois responsables de vuestra productividad y de la calidad de vuestro trabajo por lo que, con frecuencia, tendréis la capacidad de implementar cambios que mejoren claramente uno o ambos aspectos. En lo negativo, carecéis de control directo e influencia sobre la mayoría de la organización, por lo que difundir los cambios puede resultaros más difícil. Tendréis que pedir autorización para hacer la gran mayoría de las cosas que hacéis, especialmente si implican un gasto económico o van en contra de políticas ya existentes. Con todo esto en mente, vamos a buscar formas de sacar partido de los aspectos positivos y de superar los negativos.

El primer principio es empezar por cambios pequeños. ¿Cuál es el cambio más pequeño y rápido que podemos realizar para hacer progresar a nuestra empresa hacia la visión que nos apasiona? Con frecuencia, será un cambio que podremos hacer sin pedir permiso. En lugar de enzarzarnos en una pugna con la burocracia de la empresa buscando cambios de calado, es mejor dar pasos pequeños y evitar grandes transformaciones, que las empresas suelen percibir como riesgos para su futuro.

Por ejemplo, si trabajáis en desarrollo de software e intentáis que vuestra organización haga la transición a DevOps, puede que la mejor forma de dar un primer paso sea crear una serie de tests automatizados para vuestro propio código, utilizando las prácticas idóneas de testeo. Por supuesto, si lo hacéis correctamente, esto reducirá vuestro tiempo de testeo y mejorará la calidad del trabajo resultante. Es muy poco probable que alguien os ponga 'peros'. El siguiente paso podría ser la automatización de builds. Y el siguiente, tal vez, cambiar la estructura de vuestras branches. Y después, implementar una política de integración continua. Si no tenéis las herramientas necesarias, siempre podéis intentar utilizar soluciones de código libre para evitaros problemas de presupuesto. Seguid avanzando dando pequeños pasos hasta que topéis con un obstáculo inamovible.

El siguiente paso será sacar partido de las relaciones que hayáis ido creando, especialmente con vuestros compañeros de equipo más cercanos. Siguiendo con el ejemplo de DevOps, tal vez conozcáis a alguien en administración de sistemas que prefiera implementar los cambios mediante scripts. Tal vez podáis persuadir a esta persona para que os ayude a programar scripts para despliegues. O tal vez vuestro equipo acceda a adoptar una política de integración continua y una estrategia de branching más óptima. Como decíamos, seguid progresando hasta que topéis con un obstáculo inamovible.

Llegados a este punto, deberemos salvar el abismo que representa el convencer a los estratos superiores de la organización. La clave es dar con el siguiente cambio incremental y qué necesitamos para hacerlo realidad. Para lograrlo, deberemos tener dos cosas presentes. Para que vuestras ideas calen entre la jerarquía de la empresa, deberéis ser capaces de demostrar ventajas palpables y deberéis minimizar los riesgos para los gerentes. Deberéis optar por argumentos con peso: “Eh, directivo. Ya eres consciente de que tenemos que desactivar el sistema cada vez que hacemos un nuevo despliegue, ¿no? Pues he hecho mis mediciones y he descubierto que el 60% de nuestros despliegues dan problemas. Pero tengo la solución. Las compañías que siguen un modelo de despliegue continuo suelen ver problemas en menos de un 1% de sus despliegues. Tengo un plan prototipo para despliegues continuos; déjame que te lo enseñe”.

Esto posiciona vuestra nueva idea como algo que resuelve un problema real o aporta una ventaja clara y mensurable. Sin embargo, aún deberéis garantizar que estáis minimizando riesgos. El plan prototipo puede ser eficaz en la mitigación de riesgos, pero siempre conviene imaginarse todos los posibles escenarios de fracaso que el gestor puede plantearos. Y esto lo digo como un directivo con gran experiencia y mucha imaginación a la hora de pensar en estos escenarios. Vuestros argumentos tendrán mucho más peso si dejáis claro que habéis invertido vuestro tiempo y trabajo en anticiparos a ellos y que seguiréis haciéndolo. También contribuye a reducir riesgo, ya que el equipo de gestión tendrá la tranquilidad de que alguien seguirá trabajando en ese sentido y abordando los retos que pudieran surgir.

Imaginemos por un momento que habéis tenido cierto éxito llevando cambios a vuestra esfera de la empresa. Ahora llega el momento de extender el cambio a toda la empresa. Aunque esto puede requerir hacer propuestas a la junta directiva de la empresa, hay otras estrategias que podéis seguir antes de llegar a ese punto. Para conseguir crear cierto apoyo de bases entre el personal de la empresa, podéis crear un grupo interno de profesionales afines, organizar comidas informales para plantear vuestras ideas o colaborar con otros profesionales que muestren interés por vuestras ideas y os puedan ayudar a mejorar vuestras prácticas. También podréis asistir a encuentros fuera de la empresa para ver cómo otros profesionales han gestionado sus transformaciones.

Si sois capaces de crear cierto movimiento, un siguiente paso podría ser buscar la ayuda de expertos en la materia. Tal vez podáis invitar a profesionales con experiencia para que den charlas o moderen debates. Tal vez podáis distribuir libros y documentación o conseguir que vuestros compañeros asistan a las ponencias de líderes en vuestro ámbito. Es llegado este punto cuando podéis incorporar los argumentos de que "esto es lo que hace el resto del sector" o "estas son prácticas idóneas" para impulsar vuestras ideas. Vuestros esfuerzos están plantando semillas y cambiando poco a poco la cultura y el pensamiento establecido en la empresa.

Una vez logrado todo esto, habrá llegado el momento de llevar vuestras ideas a los directivos de la empresa. Tal vez no sea necesario pero, en mi experiencia personal, los cambios tienden a propagarse muy despacio salvo que cuenten con el apoyo del equipo directivo de la empresa. Siguiendo nuestro ejemplo, tal vez podáis incorporar prácticas de DevOps a la empresa, pero si esta no cambia su forma de invertir, planificar iniciativas y evaluar su éxito, no obtendrá los resultados que buscáis con la adopción de DevOps.

Sin embargo, llegado este punto, deberéis contar con cierto apoyo entre vuestros compañeros de trabajo y personal de gerencia intermedia. Es en este momento, cuando mucha gente cree que debería plantear una propuesta de negocio que ilustre cómo la nueva iniciativa ofrecerá sólidos beneficios para la inversión realizada. Aunque no es necesariamente una mala idea, mi opinión personal es que en muchos casos no es la táctica más acertada. Todo planteamiento centrado en el retorno a la inversión partirá de múltiples suposiciones, y los directivos de las empresas son expertos en desmantelar esas suposiciones. Los planteamientos centrados en el retorno a la inversión suelen ser o demasiado abstractos, o demasiado detallados.

Personalmente considero que lo mejor es centrarse en aspectos problemáticos para la empresa o en objetivos palpables y demostrar cómo los abordan vuestras ideas. Una conversación ideal podría ser como sigue: "Eh, jefazo. Quería ver si apoyarías una nueva iniciativa en la que estamos trabajando. Sé que consideras que nuestro planteamiento informático no nos permite responder lo suficientemente deprisa ante nuevas necesidades y oportunidades de negocio. La técnica en la que estamos trabajando parece ser capaz de solucionar el problema. Por ejemplo, en el caso de nuestra funcionalidad MuñecoCabezón.exe, hemos podido añadir dos patrones de movimiento de la cabeza en tan solo dos semanas. El fabricante de juguetes está muy emocionado con los resultados. Ya tenemos a 20 equipos utilizando este nuevo patrón y parece que funciona bien. Pero nos hemos encontrado con un obstáculo. Lo que realmente necesitamos es tu ayuda con…”

Si podéis realizar el trabajo que resulte en una conversación parecida a esta, podréis considerar que habéis dominado el arte de generar el cambio hacia arriba en una organización.

Por Mark Schwartz, Enterprise Strategist de Amazon Web Services