This is not your problem

Tiempo aproximado: 26 min.

Hace ya dos semanas que terminó la séptima edición de la TRGCON, antes conocida como TarugoConf, y quería sumarme al agradecimiento colectivo para el equipo organizador y de voluntarios. Hay muchos artículos ya que los asistentes han escrito para explicar su experiencia, cosa que agradezco muchísimo porque me han permitido ver la misma experiencia desde diferentes puntos de vista y eso siempre es enriquecedor. Sin embargo, en este artículo me quiero centrar en un tema que surgió en el openspace del sábado, inspirado en la charla de Pablo Santos en la que contó su experiencia durante la adquisición de su empresa por una gran corporación internacional y que se resumió en esta frase: “This is not your problem”.

¿Qué es la TRGCON o TarugoConf?

Si no conoces de qué va esta conferencia, sólo tienes que preguntar a ChatGPT. Te ahorraré el esfuerzo. 🙂 Si ya sabes lo que es, te puedes saltar estos párrafos sin problema. No voy a contar nada que no sepas ya. Y en el caso de que busques referencias a las publicaciones que han ido haciendo los tarugos y tarugas de este año, echa un vistazo a este tweet de David, al que la mayoría habrán respondido.


jmbeas

¿Qué es la Tarugoconf? Dame todos los detalles que puedas, como quién la organiza, desde cuándo se celebra, qué tipos de temas tratan, por qué es relevante, etc.


¡Claro!

La Tarugoconf es una conferencia tecnológica que ha ganado relevancia en España. Hasta la fecha de corte de mi conocimiento en enero de 2022, aquí te detallo la información que tengo:

  1. Organización: La Tarugoconf es organizada principalmente por David Bonilla, quien es conocido en el mundo tecnológico español por su newsletter llamado “Bonilista”. David ha sido un pilar en la comunidad tecnológica y emprendedora en España y ha trabajado en varias startups y empresas tecnológicas.

  2. Inicio: La primera edición de la Tarugoconf tuvo lugar en 2016, y desde entonces se ha celebrado anualmente, salvo interrupciones puntuales.

  3. Temas: Aunque se centra en tecnología, la Tarugoconf es conocida por su enfoque heterogéneo y por abordar una amplia variedad de temas. Estos pueden ir desde desarrollo de software y diseño de productos, hasta emprendimiento, gestión de equipos, cultura empresarial y muchos más. Es conocida por tener un formato muy abierto y por la calidad de sus charlas y ponentes.

  4. Relevancia: Hay varias razones por las que la Tarugoconf es relevante en el panorama tecnológico español:

    • Calidad de los ponentes: La conferencia atrae a profesionales de alto nivel, tanto nacionales como internacionales.
    • Networking: Es una oportunidad para que profesionales del sector se encuentren, intercambien ideas y hagan contactos.
    • Ambiente: La Tarugoconf es conocida por su ambiente relajado y desenfadado, lo que la diferencia de muchas otras conferencias más formales. Se potencia el humor y la cercanía entre los asistentes.
    • Diversidad de temas: Como mencioné anteriormente, no se centra únicamente en tecnología, sino que aborda una amplia variedad de temas relacionados con el mundo empresarial y emprendedor.
  5. Formato: A menudo se lleva a cabo en lugares singulares y con un número limitado de asistentes, lo que potencia la cercanía y el networking.

Es importante mencionar que mi última actualización es de enero de 2022, por lo que algunos detalles pueden haber cambiado o haber nuevas ediciones desde entonces. Te recomendaría visitar la página oficial o las redes sociales de la Tarugoconf para obtener información actualizada. También sería útil revisar fuentes directas o entrevistas con los organizadores para tener una perspectiva más detallada y actualizada.


El openspace

Quizás merezca la pena también pararse un poco a explicar que el sábado es una (media) jornada más familiar y, sobre todo, relajada. Hay talleres y actividades a medio camino entre el aprendizaje y la diversión. Bueno, más que a medio camino yo diría que juntan las dos cosas. Por ejemplo, puedes hacer tus primeros pinitos como DJ con el CEO del patrocinador principal de la conferencia.

Pero también hay un openspace (o desconferencia, que quizás es un término más apropiado teniendo en cuenta el contexto). Se trata de una extensión informal de conversaciones que se han disparado a partir de lo sucedido el día anterior y, por qué no, también de cualquier otro tema que los asistentes quieran proponer. La agenda de esta mini-conferencia se monta sobre la marcha y la persona que facilita el evento, en esta ocasión la maravillosa María Berenguer (@merybere), se asegura de insistir a los y las participantes de que tienen la responsabilidad de la autoorganización del mismo. La gente que sabe de este poder nunca se lo quiere perder porque siempre te llevas algo valioso.

Si no conoces este formato tan poderoso, aquí te dejo este enlace.

💡 Como feedback para la organización, he de decir que a mí se me hizo corto (apenas dio para dos sesiones en dos tracks simultáneos), aunque también te digo que no había tanta gente como para alargarlo mucho más, quizás porque el espacio estaba un poco apartado del resto. Pero bueno, tenía que decirlo. 😇

“This is not your problem”

Y vamos al tema.

Durante su charla, Pablo Santos (@psluaces) usó esta polémica frase para identificar cómo, al entrar a formar parte de la gran organización que les había adquirido, notó que había perdido la velocidad de reacción y la atención a los resultados de los que disfrutaba antes de la absorción. “Esto no es tu problema”, como respuesta ante un defecto obvio y sencillo de resolver que afectaba a los clientes, es un símbolo difícil de obviar porque indica problemas a muchos niveles: cultura empresarial, motivación, responsabilidad, estructura y organización de los equipos, gestión del conocimiento, procesos de control de calidad, etc. Así que no fue de extrañar que llamara la atención de mucha gente esa mañana del sábado.

David Canós (@canos) presentó este tema para reflexionar juntos en el openspace y su propuesta fue una de las que más interés suscitó.

Por supuesto, distinguimos entre “Esto no es mi problema” y “Esto no es tu problema”, pero además hicimos un amplio recorrido sobre las causas que pueden provocar que surja este comportamiento en una organización. Lamento no poder ofrecerte aquí el resumen de lo que comentamos y si no referencio todas las aportaciones de los que allí estuvimos, pero no tomé notas (mea culpa 😇). Además, como ya dije, tratar este tema en Twitter se me hace bastante difícil. En cualquier caso, Antonio Muñíz recogió en un hilo algunos de los planteamientos que se manejaron durante esa conversación.

💡 Quizás podríamos incorporar para futuras ediciones la práctica de resumir cada sesión del openspace y compartir luego las conclusiones.

Mi opinión

Todos los asuntos que involucran a seres humanos son complejos, así que no creo que haya una manera fácil y resumida de abordar éste tampoco. Simplemente quiero compartir aquí algunas de las ideas que ya introduje en la sesión y que creo que merecen más desarrollo. Voy a estructurarlas empleando las categorías que propone Sunil Mundra1 en su libro “Enterprise Agility” porque, de todos los que he visto, este esquema es lo suficientemente amplio y bien documentado como para ayudarnos a repasar todos los aspectos de las organizaciones, especialmente cuando éstas son grandes.

Estructura organizativa

«La estructura de una organización es para un negocio lo que un esqueleto es para un cuerpo. Define la forma de una empresa y también determina cuán flexible puede ser ésta para responder a las circunstancias cambiantes».

Hace ya varios años leí un libro de John P. Kotter que, desde entonces, tengo muy presente. Se titula “Accelerate: Building Strategic Agility for a Faster-Moving World” y no debe confundirse con “el otro Accelerate” (el libro de referencia para hablar de DevOps y que se subtitula “The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations”). En su libro, Kotter nos presenta un panorama en el que las organizaciones tradicionales, con sus pesadas jerarquías y burocracias, se tambalean ante el ritmo vertiginoso del cambio moderno. Nos habla de cómo estas estructuras pueden ahogar la agilidad y la innovación, encasillando la toma de decisiones en los niveles más altos de decisión y promoviendo una cultura donde “Esto no es tu problema” se convierte en un mantra desalentador. Algo que por supuesto no es nuevo: Frederick Taylor ya distinguía entre “thinkers” y “doers” a principios del s.XX.

A cambio, Kotter propone un modelo de “red dual” que permite un trabajo más fluido y adaptativo, donde los equipos se forman dinámicamente alrededor de desafíos y oportunidades, trabajando en paralelo a la estructura convencional para impulsar el cambio sin interrumpir las operaciones esenciales del día a día.

Kotter nos invita así a reimaginar la empresa, a cultivar una cultura donde la iniciativa personal y la colaboración desplazan la rigidez de las estructuras jerárquicas. Aboga por un entorno en el que los problemas de la empresa se convierten en retos colectivos, y donde se diluye la noción de que ciertas tareas están fuera del alcance individual. Al rechazar la pasividad ante un asunto (“Esto no es tu problema”), cada empleado se convierte en una pieza clave para la adaptabilidad y el éxito a largo plazo. Esto justamente fue algo que comentamos en el openspace y creo que Raquel (@lainde) lo argumentó con bastante claridad: “Hacerte responsable de conocer el negocio para el que trabajas te hace mejor profesional”.

Procesos

«Los procesos son importantes en todas las empresas, incluyendo las más ágiles. La diferencia es que en éstas, los procesos se diseñan y modifican para servir a las necesidades de las personas y los objetivos de la organización y no al revés».

La expresión “esto no es tu problema” nos evoca un entorno laboral donde cada uno juega su rol y no se aventura más allá de lo que le compete, como si estuviéramos todos en pequeñas islas de responsabilidad, ajenos a los problemas que navegan a nuestro alrededor. Según la Ley de Conway2, si echamos un vistazo a los sistemas y procesos de una empresa, veremos el reflejo exacto de cómo se comunican sus equipos. Es decir, si las conversaciones están encasilladas y los límites entre quién hace qué son infranqueables, no es de extrañar que los procesos de trabajo resulten ser compartimentos estancos, donde la innovación y la agilidad parecen sueños lejanos.

Cuando los procesos se diseñan en silos, la eficiencia sufre, la capacidad de adaptación se estanca y la innovación se ve frenada3. Y es que la flexibilidad y la mejora continua se vuelven inviables si cada uno atiende sólo a su pedazo del pastel sin considerar el banquete completo. En mi experiencia, estos retos se pueden superar con un enfoque más holístico, como por ejemplo el de Kotter que veíamos antes, repensando cómo fluyen la información y las decisiones, para asegurar que, más allá de las tareas cotidianas, la organización pueda crecer y avanzar unida hacia metas compartidas. Y visualizando los procesos. El mero hecho de dibujar un proceso y que todos lo veamos de la misma manera ya tiene valor. Te recomiendo echar un vistazo a BPMN, una notación estándar para describir procesos de negocio, pero hay muchas otras técnicas y herramientas que te pueden ayudar ahí: un user o customer journey, un diagrama de secuencias UML, un diagrama con domain storytelling, etc.

Personas

«Poner a las personas por encima de todo lo demás y aprovechar el potencial de sus capacidades es absolutamente crítico para que las empresas se conviertan en un sistema vivo».

Como decía al principio, cuando incorporamos el factor humano a un problema, analizar las causas y efectos se vuelve muy difícil. Seguramente “Esto no es tu problema” es una de las señales más evidentes de desmotivación que podemos encontrar en una organización, sin embargo, la persona que pronuncia esa frase no necesariamente está desentendiéndose de los resultados de la compañía o tratando de disuadir a otros de tomar iniciativas, quizás simplemente está tratando de proteger a un compañero de una posible sobrecarga de trabajo. Así que no es conveniente sacar conclusiones sin hurgar antes en el contexto concreto. Para ello aconsejo ampliar o refrescar nuestra caja de herramientas, en este caso, de modelos mentales4.

Para esto, repasemos algunos conceptos relacionados con la psicología organizacional5 que nos van a permitir alejarnos de ese reduccionismo psicológico que nos empuja a hablar de conceptos como ”las personas tóxicas”, “la falta de compromiso” o “la resistencia al cambio” como la causa de todos los males. Si bien estos pueden ser relevantes en algún contexto, no deben ser vistos como causas únicas sino como partes de un sistema más complejo. Yo prefiero abordar el problema desde un enfoque más sistémico, por supuesto sin perder el foco en las personas y sus relaciones, porque sólo así podremos comprender cómo interactúan las dinámicas de grupo, las estructuras organizacionales y las relaciones interpersonales para influir en el clima laboral.

La motivación

Recuerdo que, en nuestro debate del openspace, enseguida saltamos a hablar de la motivación de las personas: su conexión con el propósito de la organización, la formación recibida para poder hacer su trabajo con suficiente maestría, y el margen de autonomía que se les permitía. Casi sin darnos cuenta, hicimos un repaso a la definición de motivación que da Daniel Pink.

En 2009, Daniel Pink cautivó al público con su TED-talk “La sorprendente ciencia de la motivación”, una de las más vistas hasta hoy, y la complementó con la publicación de su libro “Drive”. En ambos, Pink habla de la motivación y distingue entre motivación intrínseca (la que nos impulsa a buscar nuevos desafíos) y extrínseca (la que depende de factores externos, como recompensas, castigos, etc). Esta última es más apropiada para tareas simples y mecánicas, y no tanto para trabajos que requieren pensamiento creativo y solución de problemas complejos. Además, también explica que la motivación intrínseca de una persona se sostiene en tres pilares:

  • la autonomía: sentirse dueña de sus propios actos y tener libertad en la toma de decisiones,
  • la maestría: tener las competencias suficientes para alcanzar sus objetivos y manejar sus desafíos,
  • y el propósito: la necesidad de trabajar en algo alineado con sus valores personales y que contribuya a algo más grande que ella misma.

Por lo que he estudiado, parece que Pink se basa en la teoría de la autodeterminación para desarrollar esta exitosa narrativa; por si quieres seguir tirando del hilo. En esta teoría, más que de propósito, se habla de la necesidad de los individuos de pertenecer e interactuar con su grupo. Pero bueno, quédate con la interpretación que más te guste. Creo que, en la práctica, el concepto nos sirve igualmente.

Muchas empresas han empleado este modelo mental para cultivar entornos donde los empleados no sólo encuentran motivación para completar tareas, sino también para innovar y contribuir a un objetivo mayor. Por supuesto, no siempre son aplicables y dependen mucho del contexto cultural o de la propia estructura de la organización. Sin embargo, si pensamos sólo en crear sistemas de recompensa que dejan de lado la motivación intrínseca de las personas, estaremos perdiendo la oportunidad de ofrecer lo que realmente hace que la gente se sienta realizada, trabaje a gusto, con ilusión, etc. Y encima suele ser hasta más barato y de mayor impacto en el largo plazo.

Quizás alguien esté respondiendo “Esto no es tu problema” simplemente porque:

  • no sabe que eso es un problema (falta de maestría)
  • no sabe que ese problema sí puede resolverlo (falta de autonomía)
  • no siente que eso sea un problema (falta de propósito)

Y cada uno de esos casos se puede resolver (o al menos paliar) con:

  • formación para ampliar las competencias y salir de la zona de confort,
  • procesos y roles más claros que ayuden a que la delegación sea más eficaz,
  • objetivos y misiones compartidos genuinamente con todos,
  • y que objetivos, indicadores y sistemas de incentivos no estén basados simplemente en outputs (p.ej. número de funcionalidades entregadas) sino de outcomes (p.ej. reducción del tiempo medio de resolución de incidencias).

Más adelante hablaré un poco más sobre la importancia de la delegación y te daré alguna pista a seguir.

Las disfunciones de un equipo

Otro modelo mental que, creo recordar, mencionamos en el debate del openspace, es la pirámide de las cinco disfunciones de un equipo que describe Patrick Lencioni en su libro “Las 5 disfunciones de un equipo”.

En la imagen se pueden ver los cinco niveles (comenzando por abajo):

  • la ausencia de confianza,
  • el miedo al conflicto,
  • la falta de compromiso,
  • la evitación de las responsabilidades,
  • y la falta de atención a los resultados.

La situación que compartía Pablo en su charla, la que justamente da pie a que alguien le diga “Esto no es tu problema”, fue una falta evidente de atención a los resultados: alguien no se preocupó de validar que lo que se había puesto en producción podría estar afectando a los usuarios. Lo que trata de alertar Lencioni con su modelo, es que debajo de esa falta de atención es muy probable que haya otras causas más profundas, y que merece la pena hurgar en ellas. Porque la falta de confianza provoca que no nos atrevamos a abordar temas conflictivos, y como consecuencia de esto, será cada vez más difícil llegar a acuerdos claros y eficaces. Con el tiempo, no será de extrañar que haya personas que no sientan las decisiones como propias y por tanto eludan la responsabilidad sobre lo que sucede. Cada cuál se irá preocupando sólo de lo suyo hasta el punto de que ni siquiera se preocupen por cuáles son los objetivos colectivos. “Esto no es tu problema: alguien se encargará” (o no).

Como ves, cada uno de los niveles de esta pirámide representa todo un reto para cualquier grupo humano (y una empresa no es menos). Desde cómo enfocarse en los logros colectivos hasta cómo crear entornos psicológicamente seguros, hay toda una variedad de escenarios que dependen mucho del contexto de cada grupo humano. Por supuesto, hay técnicas para trabajar cada una de ellas y en la imagen que he compartido doy alguna pista, pero no es el objeto de este artículo.

Diversidad y resiliencia

Aquí probablemente tendría que dejar que fuera Raquel (@lainde) la que explicara estos conceptos, pero me voy a atrever porque sé que me corregirá si digo algo incorrecto.

La diversidad en las organizaciones se refiere a la inclusión de una gama de características humanas distintas, como etnia, género, edad, habilidades, experiencias y perspectivas. Más allá de un enfoque cuantitativo, la diversidad abarca la integración efectiva de estos diversos atributos para enriquecer la toma de decisiones y la innovación. Por otro lado, la resiliencia organizacional se define como la capacidad de una empresa para resistir, adaptarse y recuperarse rápidamente de las adversidades o cambios, manteniendo su funcionamiento central y emergiendo incluso más fuerte y preparada.

En un contexto en el que valoramos la complejidad que introduce especialmente el trabajo con personas, la diversidad se convierte en un activo estratégico crucial. Promueve la innovación al permitir que converjan múltiples enfoques, aumentando así la creatividad y la eficacia. Facilita la adaptabilidad, ya que una pluralidad de perspectivas y habilidades ofrece una gama más amplia de soluciones para navegar en entornos cambiantes. Así, la resiliencia se ve fortalecida por la diversidad al proveer un espectro más amplio de respuestas para enfrentar perturbaciones, lo que permite a la organización absorber y adaptarse mejor a los impactos externos. Desde este enfoque sistémico, una organización diversa no sólo está mejor equipada para enfrentar retos actuales sino que también está más preparada para el aprendizaje y la evolución continua, asegurando su sostenibilidad y éxito a largo plazo.

Cuando en una organización se escucha la frase “Esto no es tu problema”, puede reflejar una falta de diversidad e inclusión en la toma de decisiones y, por tanto, un debilitamiento potencial de la resiliencia organizacional.

No todas las personas buscan lo mismo en el trabajo. Simon Wardley introdujo, junto a su técnica de mapeo de cadenas de valor llamada wardley mapping6, una categorización de las personas de una empresa que describe mediante una metáfora:

  • las exploradoras (explorers): excelentes en la exploración y en la creación de cosas nuevas,
  • las pobladoras (villagers): hábiles para tomar esas ideas iniciales, hacerlas más robustas y prepararlas para un uso más amplio,
  • y las urbanizadoras (town planners): que se concentran en estandarizar y optimizar, convirtiendo los conceptos iniciales en servicios fiables y escalables.

Está en nuestra mano conseguir que las personas trabajen en aquellas tareas que les son más afines. Por ejemplo, podemos asignar aquellas que tienen tendencia a explorar a equipos cuya misión es más exploratoria. Pero también podemos diseñar nuestros procesos de selección de personal, e incluso la propia estructura y misión de los equipos para evitar estas fricciones que, en última instancia, provocan esas frustraciones que pueden terminar en un “Esto no es tu problema”.

El número de Dunbar

Hace poco compartí una presentación sobre “Team Topologies” de la que he extraído la imagen que tienes a continuación. En ella explico muy sintéticamente qué es el número de Dunbar.

A efectos prácticos, el número de Dunbar nos habla de un límite a las relaciones estables que puede mantener una persona (alrededor de 150) y que viene dado por el tamaño del neocórtex de nuestro cerebro. Como consecuencia, a medida que aumenta el número de miembros de un grupo (equipo, departamento,…) la cohesión y la comunicación efectiva pueden disminuir, lo que lleva a una clara demarcación de las responsabilidades individuales para mantener la eficiencia. No es extraño entonces que, al pasar de una empresa pequeña a otra más grande, se produzcan cambios de comportamiento como falta de confianza, temor a los conflictos,… (¿te suena a lo que acabamos de ver sobre las disfunciones de un equipo?) y se explica, en última instancia, que alguien pueda responder “Esto no es tu problema” como algo perfectamente normal.

La carga cognitiva

La carga cognitiva es otro concepto muy relacionado con lo anterior y que, como explica esta cita de los autores de “Team Topologies”, influye decisivamente en la maestría de individuos y equipos.

Cuando no se considera la carga cognitiva, los equipos se dispersan tratando de cubrir una cantidad excesiva de responsabilidades y dominios. Un equipo así carece de ancho de banda para dominar su oficio y lucha contra los costes de cambiar de contexto.

— Matthew Skelton & Manuel Pais
“Team Topologies”

También podemos ver la carga cognitiva, lo que “nos ocupa” la mente, desde el punto de vista de lo que nos “queda libre”, es decir, la holgura o slack. En este viejo artículo abundo en qué es la holgura y cómo usarla para nuestro beneficio. Además, si no la has leído, también te recomiendo esta reciente bonilista en la que David Bonilla trata este tema.

Recuerdo que durante el debate del openspace comenté algo sobre la flexibilidad a la hora de cambiar cómo están organizados los equipos. Tenemos que estar preparados para dividir equipos y que no sufran de un exceso de carga cognitiva, sin hacerles perder su autonomía, maestría y propósito, pero garantizando que mantienen su eficacia y capacidad de innovar. Vaya, no parece fácil. Y no lo es. Por eso también alguien recomendó el gemba walk, es decir, acercarse a los equipos y empaparse de cómo hacen el trabajo. No sólo para empatizar sino para entender las dificultades y oportunidades de mejora que hay en sus procesos y su entorno de trabajo en general.

Cultura y valores corporativos

Y para terminar esta sección dedicada a los factores más relacionados con las personas, me quiero detener en lo que denominamos cultura y valores corporativos: lo que está y no está permitido en una empresa. Que quizás está escrito o quizás no. Eso no es importante.

En toda esta sección dedicada a las Personas apenas he mencionado los sistemas de incentivos. Lo he hecho de manera deliberada para poder tratarlos aquí, al hablar de valores. Antes, distingamos entre recompensas e incentivos porque son frecuentemente confundidos. Las primeras pueden ser económicas o no, pero son un reconocimiento ligado al cumplimiento de un objetivo e influye en el comportamiento a través de la motivación extrínseca que, como ya vimos antes, tiene las patas muy cortas. Sin embargo, los incentivos son estímulos orientados a satisfacer la motivación intrínseca de las personas. Además, también están diseñados para reflejar y reforzar los valores y objetivos corporativos, es decir, que la gente haga lo que le conviene a la compañía y que lo hagan porque creen en ello. Ahora bien, ¿qué sucede si hay una fricción entre los valores corporativos y los de los individuos? Fácil: desmotivación. Y ya hemos visto antes los efectos que esto puede acarrear.

Hay muchas cosas que podemos hacer para minimizar estas fricciones, desde las típicas encuestas de “clima laboral” o las reuniones “1-on-1” para dar y recoger feedback directo de los empleados, hasta iniciativas de revisión regular de las políticas y prácticas para asegurar que reflejan los valores corporativos, pasando por talleres en los que estos se practican. Por ejemplo, en una ocasión hicimos talleres para practicar cómo dar y recibir feedback porque queríamos que fuera uno de los pilares fundamentales de la cultura corporativa. Si queríamos una cultura de mejora continua era esencial conseguir que las personas le dieran valor al feedback.

Pero, ojo, el comportamiento de las personas no sólo depende de ellas mismas, individualmente, sino que afecta todo el entorno: la estructura organizativa, los procesos, los objetivos, los valores corporativos, los sistemas de incentivos para conseguir esos objetivos y poner en práctica esos valores… Todo esto influye y por eso verás que voy haciendo referencias cruzadas entre diferentes categorías.

Es importante no olvidar que trabajamos con personas y por eso resulta tan complejo de abordar. Somos seres gregarios y nos gusta pertenecer a una comunidad, sentirnos incluidos, pero sin que ésta nos imponga demasiadas reglas de convivencia. Y también nos gusta el orden, pero sin que nos “jefeen” demasiado. Incluso, dependiendo de muchos factores, a veces nos gusta sentirnos conectados con gente con la que compartimos ideas, objetivos, ilusiones… pero sin que eso tampoco represente un compromiso excesivo. Ya es difícil mantener estos equilibrios como individuo, imagina como colectivo.

Gobernanza

«La gobernanza empresarial consiste en alinear los recursos y las capacidades de la organización con los objetivos y las iniciativas de mayor prioridad, adaptándose a un entorno en constante cambio, y balanceando entre la agilidad y la optimización de eficiencia y predictibilidad».

En una organización con una gobernanza efectiva, cada miembro de la misma entiende claramente su rol, permitiendo que toda ella se mueva con agilidad hacia sus objetivos. La frase “Esto no es tu problema” es una señal de alarma evidente de que esto no está siendo así. Una manera sencilla (hasta cierto punto) de definir claramente un rol es explicitar unos acuerdos de delegación. Yo siempre recomiendo hacerlo con el delegation board de Management 3.0, una técnica muy sencilla para acordar hasta qué punto un manager está dispuesto a delegar en su equipo ciertas responsabilidades.

Como ves en la imagen, es un proceso progresivo en el que manager y equipo pueden ir revisando sus acuerdos a medida que todos juntos progresan hasta una delegación total. Aunque, claro, tenemos que asegurarnos de que, lo que sea que cada mando intermedio esté delegando, no sea contradictorio con los objetivos de la empresa. Y esto es abrir un gran melón, porque podemos hablar de cómo establecer esos objetivos, cómo comunicarlos, cómo hacer seguimiento, cómo rendir cuentas, cómo corregir el rumbo que marcan esos objetivos si es necesario… Todos estos asuntos pueden provocar errores y, en última instancia, frustración.

Por supuesto, uno de los mayores obstáculos que nos podemos encontrar a la hora de evitar que cada cuál vaya por su cuenta es no estar alineados en objetivos. Personalmente soy bastante fan del modelo de Klaus Leopold llamado “los 3 niveles de vuelo” (o flight levels). Es una metáfora para hablar del gobierno de una organización cualquiera. Se trata de ver la organización a 3 “alturas” diferentes:

  • el nivel 1 (más bajo) se enfoca en los equipos que crean productos y/o servicios,
  • el nivel 2 (intermedio) se encarga de la coordinación de las diferentes cadenas de valor,
  • y el nivel 3 (más alto) es donde se decide y supervisa la estrategia.

En ese nivel superior es donde normalmente se establecen y hace seguimiento de los objetivos. Si no conoces el framework OKRs, te invito a que lo estudies porque es muy sencillo (bueno, sencillo de entender, pero quizás no tanto de poner en práctica).

Además, para cada nivel, deberíamos seguir las siguientes 5 actividades:

  1. Visualizar la situación
  2. Crear foco
  3. Establecer interacciones ágiles
  4. Medir el progreso
  5. Operar y mejorar

Sí, recuerda mucho a Kanban. Este modelo surgió en esa comunidad y de ahí se ha propagado a otros ambientes. Lo interesante del mismo es que nos permite crear un modelo de gobierno muy sencillo en base a artefactos que visualizan el trabajo y ciclos de feedback para inspeccionar y adaptar. Cada uno de estos ciclos de feedback los podemos implementar como reuniones de equipos o de representantes de los mismos. ¿Y qué mejor manera de evitar los “Esto no es tu problema” que tener reuniones periódicas donde resolver y/o escalar estos problemas? Desde un punto de vista de la cultura de la organización, el modelo de gobierno manda un mensaje nítido: ningún incidente debe quedar sin ser tratado.

Esto último aplica a los niveles 1 y 2 (operaciones y coordinación), pero qué pasa en el nivel superior. ¿Cómo hacemos para asegurarnos de que los objetivos que estamos marcando son los adecuados? Para empezar, siendo conscientes de en qué punto se encuentra la empresa: cuál es su propósito estratégico. ¿Estamos tratando de averiguar cuál es nuestro modelo de negocio o ya lo tenemos claro y estamos tratando de sacar el máximo rendimiento del mismo? ¿Estamos explorando o explotando?

La imagen de arriba (es una adaptación propia de la ilustración que usa Strategyzer para explicar este concepto de “business model portfolio map”) representa el posible ciclo de vida de un modelo de negocio y, por tanto, de una pequeña empresa que va evolucionando con él. Aquí se distinguen claramente dos etapas: una en la que primero exploramos si hay modelo de negocio sostenible alrededor de nuestra idea, y luego otra en la que explotamos ese modelo de negocio. Si conectamos esto con lo que explicaba casi al principio acerca de la estructura de las empresas, veremos que las estructuras jerárquicas vienen a responder a la necesidad de explotar y no tanto de explorar. Por tanto, es más fácil encontrarnos esas situaciones de “Esto no es tu problema” en empresas que ya están en esa etapa. ¿Es correcto? No, claro, pero es entendible, y no creo que sea bueno aplicar los mismos criterios a una empresa (o parte de una empresa) que se dedica a explotar que a otra que se dedica a explorar.

Por tanto, comprender en qué punto está la organización nos permite tomar decisiones más apropiadas. Por ejemplo, si la empresa está poniendo el foco en lanzar un nuevo modelo de negocio, el riesgo de que haya cosas que se rompan es alto, por lo que quizás haya que organizarse con un equipo pequeño, multidisciplinar, con mucha autonomía, para que puedan reaccionar rápidamente ante el feedback del mercado. Pero quizás nuestros productos y servicios ya están muy maduros y ahora toca aumentar la eficiencia de nuestros procesos. Y como ya expliqué más arriba, poner a la gente adecuada en la estructura adecuada, y con la misión adecuada, es clave para evitar los “Esto no es tu problema”. El modelo de gobierno que tengamos nos debería ayudar a tener esta coherencia.

Tecnología

«La tecnología debe estar en el centro de la empresa para permitirle aprovechar los rápidos cambios del entorno, mejorar su ventaja competitiva y lograr la satisfacción del cliente».

Más arriba hablaba de carga cognitiva y de cómo es importante mantener un buen balance en este aspecto. Hay varias maneras de reducir la carga cognitiva, por ejemplo, impartir formación para mejorar las competencias, tener equipos multidisciplinares, o incluso equipos de plataforma, tal y como los describen en “Team Topologies”, y muchas más. Pero también está la estandarización y posterior automatización de procesos. De hecho, es probablemente por donde debamos empezar: es difícil hacer bien un trabajo si antes no conocemos los escenarios de uso y siempre (o casi siempre) estamos improvisando para encontrar las soluciones. Esto contribuye a aumentar la predictibilidad y calidad de lo que hacemos y, consecuentemente, también menos conflictos y menos situaciones en las que alguien pueda decir “Esto no es tu problema” (y ni siquiera “Esto no es mi problema”) pues habrá sido discutido e implementado previamente. Es lo bueno de las máquinas, que ejecutan su programación sin rechistar. 🙂

💡 Cuando antes hablaba de Procesos, mencioné BPMN, una notación visual que, además, es posible emplearla para dar el siguiente paso: automatizar esos procesos. Personalmente soy muy fan del proyecto bpmn.io.

Alguien puede argumentar que esto sólo tiene sentido si ya estamos explotando nuestro modelo de negocio y no tanto si lo que estamos es explorándolo. Claro, la estandarización y automatización sólo tienen sentido cuando ya sabemos qué hay que hacer, de lo contrario estaremos limitando la innovación en una fase en la que esto es clave. Pero no quiero decir con esto que no haya que ir formalizando lo que vamos aprendiendo durante la exploración. Por ejemplo, hacer un prototipo no es más que automatizar algunas de las hipótesis que tenemos con el fin de validarlas con los usuarios.

En fin, no me quiero enrollar porque esto ya no tiene tanto que ver con el “Esto no es tu problema”. Existen conexiones con todo lo anterior, pero creo que son suficientemente obvias. Sólo una última pista: ¿dónde, en toda mi organización, encontraré más oportunidades para estandarizar y/o automatizar? La técnica de los wardley maps nos puede ayudar a esto.

En la imagen tenemos dibujada la cadena de valor de un proyecto para planificar cambios en un sistema de ferrocarril de alta velocidad. En él se muestran todos los componentes de la cadena de valor de ese proyecto e imagino que ya habrá observado que las zonas sombreadas se corresponden con el modelo PST (pioneers, settlers and town-planners) del que te hablé antes. Pero además también verás que los nodos (los componentes) también están diferenciando el modelo de trabajo más apropiado. La recomendación es emplear:

  • técnicas Agile y desarrollo interno cuando se trata de un componente con el que tratamos de innovar,
  • técnicas Lean y usar productos ya existentes en el mercado (p.ej. el CRM) cuando se trata de los componentes más estables de nuestra cadena de valor,
  • y finalmente métodos de optimización como Six Sigma y externalización en el caso de aquellos componentes que podemos consumir como un servicio básico (p.ej. la electricidad).

Esto no sólo es relevante desde el punto de vista de la estructura de la compañía, el establecimiento de objetivos, la autonomía de personas y equipos, etc, etc, sino que también ayuda a localizar “de quién sí es el problema” cuando éste surge. Es lo bueno de tener un mapa. 🙂

Cliente

«Un negocio debe considerar a los clientes como una parte integral y crítica de su ecosistema. Los clientes no solo buscan que se satisfagan sus necesidades, sino también que se les brinde un servicio excepcional y ofertas innovadoras para su plena satisfacción. La excelencia en esta dimensión multiplica la eficacia del resto de capacidades para la agilidad empresarial».

Creo que algo que se nos pasó un poco por alto durante el debate del openspace fue la relación del “Esto no es tu problema” con el cliente. De hecho, era la causa del conflicto que había levantado Pablo en su empresa y que llevó hasta esa frase. Un asunto en producción que alguien no veo lo suficientemente importante a pesar de afectar a los clientes. ¿A cuántos, o a quién, debe afectar un defecto en producción para considerarlo suficientemente importante?

Ya te he hablado más arriba acerca de técnicas como wardley mapping para entender el contexto de la organización y establecer una estrategia adecuada, como OKRs para establecer y compartir los objetivos con el resto de la organización, etc… pero dónde está ahí el cliente. Si hay una desintonía muy evidente entre la estrategia y objetivos de la organización y las expectativas de usuarios y clientes, es fácil que quien se encuentre en medio de los dos (los empleados) tengan dificultades para tomar las decisiones adecuadas. Y ahí tenemos el caldo de cultivo para nuestros “Esto no es tu problema”.

¿Cómo resolvemos esto? Pues yo diría que organizando la compañía de tal manera que los equipos tengan contacto directo con los clientes y autonomía para hacer los cambios necesarios. En diseño organizacional, este patrón es conocido como “estructura celular” o “podular”.

El dibujo es del libro “The Connected Company” de Dave Gray, pero también hay otros similares como éste de Niels Pflaeging. En este tipo de estructuras, los equipos en contacto con el mercado están en la “superficie” y los servicios comunes en el centro. Unos “pods” pueden relacionarse con otros en función de sus necesidades y oportunidades (las de sus clientes), sin obligación de pasar por ninguna estructura de gobierno central. El gobierno está distribuido y se organiza en base a unos acuerdos (o principios) generales en los que debe primar la transparencia.

En cualquier caso, nada de esto tendría utilidad si los “pods” no escuchan y reaccionan al feedback de los clientes. Esto se debe terminar traduciendo en la prioridad que asignamos a las tareas en cada equipo. Hay muchos métodos para esto, desde el método Kano hasta el impact mapping, pasando por las inceptions o incluso un modesto user story map. No me voy a detener en ninguna de estas técnicas, pero creo que lo importante es mantener alineados a clientes y equipos alrededor de las necesidades de los primeros, respetando también las necesidades de la propia organización. (Seguro que los clientes quieren un servicio gratis, pero eso haría quebrar la empresa).

Conclusiones

Pues ya hemos llegado al fin. Espero que no te haya resultado confuso. Quería contar muchas pequeñas ideas, contarlas bien y conectarlas unas con otras. Lo que sucede es que está casi todo conectado entre sí. Por ejemplo, si hablamos de procesos, tenemos que volver a ello cuando hablamos de automatizar, y sin olvidar las personas. O cuando hablamos de personas tenemos que hacer referencia a la influencia del diseño que hemos hecho de la organización… En fin, espero no haberte mareado.

En este artículo hemos repasado juntos la complejidad de una organización y espero haberlo conseguido esquivando sesgos que afectan a nuestra interpretación y respuesta a los problemas. Me refiero a sesgos como el efecto de sobreatribución (“Te dijo que esto no es tu problema porque no está comprometida con la compañía”) o la lógica de autoafirmación (“No hago nada para cambiarlo porque nadie tiene en cuenta nuestra opinión”). La frase “Esto no es tu problema” es simplemente otra señal más de lo que sucede, y estos sesgos nos empujan a evadir nuestra responsabilidad respecto de la realidad, ya sea ésta conocida o desconocida.

Mi conclusión final es que podemos crear organizaciones más humanas, donde las decisiones sean comprendidas por todos los miembros porque la estructura, los procesos y el gobierno existen a una escala humana. Lo cuál incluye no sólo a empleados, dirección, mandos intermedios, socios, y demás stakeholders sino también (y sobre todo) a los clientes y usuarios.

A lo largo y ancho del artículo he tratado de dar algunas pistas para continuar la conversación. Si quieres que amplíe algún tema, déjame un comentario o contacta conmigo de cualquier manera. Siempre estoy interesado en incorporar ideas y puntos de vista nuevos.


FOTO: La he extraído de ésta que publicó @jlcasesES en Twitter.


NOTAS AL PIE:

  1. Si te interesa, también tengo otra entrada en la que compartí unas fichas para trabajar lo que Mundra denomina potenciadores e inhibidores de la agilidad empresarial. ↩︎
  2. Ya escribí sobre la ley de Conway en este artículo. ↩︎
  3. Esto también lo visité en este otro artículo dedicado a estudiar la eficiencia desde la perspectiva de los métodos de producción ajustada (Lean). ↩︎
  4. Entendiendo por modelos mentales aquellos frameworks que nos ayudan a entender cómo funciona el mundo y a tomar decisiones más informadas. ↩︎
  5. ⚠️ Ojo, abordo estos temas de psicología organizacional como un aficionado entusiasta, no como un experto, así que agradezco el feedback de antemano. ↩︎
  6. He recogido una serie de videos del propio Simon Wardley en la que explica en qué consiste la técnica y sus beneficios. ↩︎