Autonomía vs. Determinación externa

Prácticamente todas las grandes empresas tecnológicas han subido al tren de los equipos de producto autoresponsables, comprometidos/estables, multifuncionales y colaborativos, y creo que eso está bien. Apenas se ve una empresa que aún utilice los viejos modelos (principalmente el modelo de pool). Sin embargo, a veces no es fácil encontrar la mezcla adecuada entre autonomía y determinación externa.

Los resultados hablan por sí mismos, pero atribuyo la mayoría de las ventajas al aumento de la motivación y a la verdadera comprensión del ownership que surge cuando los equipos sienten que pueden decidir sobre su propio trabajo.

Pero aunque los líderes de equipo generalmente me dicen que sus equipos son autoresponsables y autónomos, muchos miembros del equipo a menudo lo ven de forma diferente. Cuando ese es el caso, intento descubrir qué es exactamente lo que el equipo no puede decidir por sí mismo o en qué se siente limitado.

¿Dónde está la línea entre autonomía y determinación externa?

Normalmente se reduce a una de las dos respuestas siguientes:

O bien el equipo aún no disfruta plenamente de la confianza de la dirección y por eso la dirección no quiere realmente darles carta blanca a los miembros del equipo.

O bien el equipo quiere cambiar algo que la dirección considera parte de los fundamentos.

Básicamente, todos los equipos estarían de acuerdo en que hay algunas cosas que pueden decidir libremente por sí mismos, así como otras áreas que forman parte de los requisitos básicos comunes para todos los equipos.

Un ejemplo

En este último caso, sería muy inusual que cada equipo eligiera su propia herramienta de control de versiones. Si el equipo de desarrollo ha establecido GitHub como estándar, normalmente se considera parte de los requisitos básicos. Incluso si un equipo tuviera una fuerte preferencia por otra herramienta, los costes superarían con creces los beneficios para la empresa.

Este ejemplo es bastante claro, sin embargo hay muchos otros en los que no es tan evidente.

¿Debería cada equipo poder abordar la automatización de pruebas a su manera? ¿Deberían los equipos poder elegir individualmente el lenguaje de programación? ¿Y el framework de interfaz de usuario? ¿Y la compatibilidad con navegadores? ¿Qué pasa con funcionalidades costosas como el „soporte offline”? ¿Deberían poder decidir por sí mismos cuán „ágiles” trabajan? ¿Y realmente cada equipo debe estar involucrado en múltiples iniciativas de producto de la empresa?

Como suele ocurrir con los productos, al final se reduce a un compromiso – en este caso es un compromiso entre la autonomía y el cumplimiento de los fundamentos establecidos.

Aunque básicamente apoyo mucho el principio de equipos autónomos e independientes, admito que también soy un gran fan de invertir en unos buenos fundamentos. Con una base común sólida, los equipos pueden crear productos y experiencias excepcionales mucho más rápidamente.

Quiero detallar un poco más este compromiso. Pero también quiero enfatizar que no afirmo que haya una única respuesta a esta pregunta, sino que puede ser diferente para cada empresa y cada equipo. Todo depende de varios factores que explicaré a continuación:

Puntos a considerar:

– La competencia del equipo:

En términos generales, hay tres situaciones diferentes:

Equipo A – un equipo experimentado con mentes inteligentes y creativas, en quienes se puede confiar plenamente para que tomen buenas decisiones.

Equipo B – estas personas tienen las intenciones correctas pero en muchos casos aún no tienen la experiencia necesaria para tomar buenas decisiones, por lo que aún necesitan algo de apoyo.

Equipo C – un equipo junior que quizás ni siquiera sabe lo que no sabe. Sin una tutoría intensiva, estos equipos pueden causar grandes dificultades sin querer.

– Rapidez:

Uno de los principales argumentos a favor de las directrices fijas es la velocidad. La lógica detrás es que los equipos deberían poder construir sobre el trabajo de sus colegas para no perder tiempo reinventando la rueda. Sin embargo, en algunos casos es generalmente aceptado y habitual permitir a los equipos trabajar un poco más despacio y tal vez hacer algo de trabajo duplicado, si con ello se fomenta la autonomía. A veces, sin embargo, es esencialmente importante para el negocio que se cumplan las directrices.

– Importancia de la integración:

En algunas empresas, el portfolio consiste en productos relacionados pero en gran medida independientes, donde la integración y las directrices no son especialmente importantes. En otras empresas, el portfolio trata de productos altamente integrados, donde ciertas directrices generales son indispensables. Al final, depende de si un equipo debe concentrarse en una solución individual específica o si debe encontrar una solución óptima con respecto a toda la empresa.

– Fuente de innovación:

Si las principales fuentes de innovación futura ya se encuentran en los fundamentos, los equipos deberían tener más libertad para repensar estos elementos fundamentales. Si los orígenes de la innovación se encuentran en el nivel de las soluciones, el equipo debería concentrarse menos en los fundamentos y más en innovaciones creativas a nivel de aplicación.

– Tamaño de la empresa y ubicaciones:

La autonomía a menudo se complica cuando surgen problemas de escalado. Cuando las empresas crecen y sus equipos están distribuidos en diferentes ubicaciones, se vuelve más difícil pero también más importante establecer ciertas directrices básicas. Algunas empresas intentan resolver este problema con el concepto de un „Centro de Excelencia”, donde se reúne a un equipo que trabaja conjuntamente en una tarea en una ubicación específica. Otras lo intentan con roles más holísticos. Y otras añaden procesos.

– Cultura empresarial:

También en la cultura de equipo la relación entre autonomía y determinación externa juega un papel importante. Cuantas más directrices establece una empresa, más sienten los equipos que su autonomía está restringida. Para los equipos B y C eso puede ser aceptable, pero para los equipos A ya es algo más problemático.

– Madurez de la tecnología:

Querer establecer una base unificada para todos demasiado pronto es un problema frecuente. Si la base aún no está madura, no puede proporcionar el soporte para el que fue pensada. Presionar demasiado para implementar directrices antes de que los fundamentos estén realmente listos puede perjudicar a los equipos que dependen de esos fundamentos. Es como intentar construir algo sobre un castillo de naipes tambaleante.

– Importancia para el negocio:

Si asumimos que la base es sólida, existen más riesgos con un equipo que no utiliza esos fundamentos. En algunos casos eso puede no ser grave. Pero cuando se trata de productos o iniciativas cruciales para el negocio, hay que pensar bien en qué concentrarse.

– Grado de responsabilidad:

Otro factor es el grado de responsabilidad que acompaña a la autodeterminación e independencia. Si los equipos no tienen responsabilidad propia – y especialmente si no hay equipos A fuertes – los equipos tampoco tienen una razón real para prestar especial atención a este compromiso. Pero queremos que los equipos reflexionen sobre este compromiso. Si sé que el equipo es fuerte y está plenamente informado sobre los riesgos y consecuencias, y aun así quiere ignorar o reemplazar un componente esencial de los fundamentos, entonces apoyo a los miembros del equipo en esa decisión.

Resumen

Como puede verse, hay muchos puntos que deben considerarse. Sin embargo, en mi opinión, la mayoría de los equipos son muy razonables cuando se abordan estos temas abiertamente. A veces, unas pocas preguntas básicas sobre las consecuencias son suficientes para ayudar al equipo a tomar mejores decisiones respecto a este compromiso.

Sin embargo, si los equipos toman persistentemente malas decisiones al respecto, deberías reconsiderar el nivel de experiencia del equipo y quizás invertir más tiempo en asegurarte de que los miembros del equipo realmente entienden todas las relaciones de negocio.

Este texto proviene del Blog de Marty Cagan y fue traducido por nosotros al alemán.