Estimulación de la innovación y la velocidad con los “equipos de dos pizzas” de Amazon

Amazon, como muchas empresas que empezaron durante la era puntocom, se estructuró para lograr agilidad rápida y ofrecer valor constante a los clientes. En su primera carta a los accionistas en 1997, Jeff Bezos hablaba de la importancia de estar siempre atento a los clientes y ofrecerles valor continuo a largo plazo, incluso a expensas de los beneficios empresariales a corto plazo. Esta implacable obsesión por los clientes se basaba en la contratación y el mantenimiento de una estructura organizativa de creadores motivados que se levantaban cada día para resolver los problemas más peliagudos de los clientes e inventar para ellos.

«Poner el listón muy alto en nuestro enfoque de contratación», escribió Jeff, «ha sido, y seguirá siendo, el elemento más importante del éxito de Amazon.com».

Esto resultaba más fácil de conseguir en aquellos primeros momentos, cuando la empresa se centraba en el comercio electrónico y los equipos (así como la arquitectura técnica en la que se basaban para innovar con rapidez) estaban más centralizados y estrechamente vinculados. Pero con el tiempo, a medida que Amazon ampliaba el número de empresas y nuevas innovaciones para satisfacer las necesidades de nuestros clientes, empezamos a experimentar dificultades en la velocidad y agilidad con la que podíamos ejecutar. El deseo de seguir siendo una “máquina de inventar”, como señaló Jeff en su carta a los accionistas de 2015, una empresa capaz de “combinar las extraordinarias capacidades de servicio al cliente que ofrece el tamaño con la velocidad de movimiento, la agilidad y la mentalidad de aceptación de riesgo que normalmente se asocian a las startups”, empezó a verse afectado. Nuestra arquitectura y organización estrechamente vinculadas simplemente no nos ayudaban a avanzar tan rápido como queríamos, o necesitábamos.

Para hacer frente a la creciente lentitud e ineficacia, cambiamos radicalmente nuestra arquitectura técnica a lo que se conoce como arquitectura de microservicios. Desacoplamos nuestra arquitectura monolítica en una vasta red de servicios únicos e independientes. De este modo, pudimos lanzar rápidamente nuevas innovaciones y ofertas, iterar rápidamente los servicios existentes en función de las necesidades cambiantes de los clientes y experimentar constantemente con nuevas ideas para inventar en nombre de los clientes.

Pero no bastaba con revisar la tecnología que utilizaban nuestros creadores para impulsar la innovación. También necesitábamos reestructurar la forma en que se organizaban los equipos para maximizar su capacidad de permanecer cerca de los clientes y sus necesidades, lanzar rápidamente productos y servicios innovadores para ellos y aprovechar al máximo la agilidad y velocidad que podía proporcionar una arquitectura de microservicios. Esta estructura organizativa se conoció como los «equipos de dos pizzas» de Amazon.

El concepto de los equipos de dos pizzas de Amazon es sencillo: ningún equipo debe ser tan grande como para que se necesiten más de dos pizzas para alimentarlo. Dejando a un lado el número o la naturaleza de los ingredientes (este no es el lugar ni el momento de resolver el debate sobre si se debe poner piña en la pizza), lo ideal es que el equipo esté formado por menos de 10 personas: los equipos más pequeños minimizan las líneas de comunicación y reducen los gastos generales de burocracia y toma de decisiones. Esto permite a los equipos de dos pizzas dedicar más tiempo a centrarse en sus clientes y experimentar e innovar constantemente en su beneficio, la mayor prioridad de los equipos de alto rendimiento en Amazon.

Los equipos más pequeños también aumentan la implicación y la capacitación. Esto puede mitigar el efecto Ringelmann: una tendencia a la disminución de la productividad individual en grupos más grandes. A medida que aumentan los recursos del equipo, se presta menos atención al esfuerzo individual y las personas se apoyan más en los demás para asumir la carga. La magnitud de la contribución individual disminuye a medida que aumenta el tamaño del equipo. A la inversa, el esfuerzo individual aumenta a medida que disminuye el tamaño del equipo.

Los equipos más pequeños también aumentan la satisfacción de los empleados, una preocupación clave en el esfuerzo de las organizaciones actuales por atraer y retener a los mejores talentos. Un destacado estudio de Hackman y Vidmar demuestra que la satisfacción individual disminuye a medida que aumenta el tamaño del equipo. A menudo, en los equipos grandes, las contribuciones individuales son menos reconocibles y la implicación individual sobre áreas específicas se vuelve más difusa.

El estudio de Gallup The State of the American Workplace mostró que las organizaciones con menos de 10 empleados alcanzaban niveles de compromiso del 42 % o superiores, mientras que el nivel medio de compromiso de las organizaciones más grandes era inferior al 30 %.

Pero los equipos de dos pizzas de Amazon no son solo cuestión de tamaño. Un factor clave para permitir la innovación constante y la velocidad en una estructura de equipo de dos pizzas es dotarlo de un enfoque único.

► Escuche el pódcast: C-Suite Strategies for Leading Significant Change

Un equipo de dos pizzas no es solo una cuestión de tamaño, sino también de fomentar e impulsar la implicación y la independencia a nivel de equipo.

En Amazon y AWS, los equipos de dos pizzas tienen la responsabilidad exclusiva de un producto o servicio específico. En lugar de mantener sistemas complejos o resolver problemas que abarcan múltiples servicios, líneas de negocio o segmentos de clientes, los equipos de dos pizzas se centran en un solo servicio u oferta, y únicamente en los clientes que lo utilizan. Este enfoque único favorece la eficacia y la escalabilidad. La hoja de ruta de los equipos de dos pizzas (incluidas las compensaciones y las prioridades que deben establecer) se centra exclusivamente en innovar en beneficio de su servicio y del segmento de clientes que lo utiliza.

La estructura de dos pizzas también fomenta la responsabilidad del equipo. Los equipos de dos pizzas no entregan algo que han lanzado a otro equipo para que lo ejecute. Esta responsabilidad única se extiende a toda la experiencia del cliente y a todo el ciclo de vida del producto o servicio de un equipo de dos pizzas.

Por ello, los equipos de dos pizzas deben estar al tanto de cada parte de su servicio, con unos estatutos claros y una misión bien definida. Deben permanecer cerca de sus clientes y crear los mecanismos de seguimiento, las métricas y los indicadores clave de rendimiento adecuados para garantizar que su servicio aporte valor a los clientes de forma constante.

Esto también requiere que un equipo de dos pizzas cuente con los recursos adecuados (ingeniería, pruebas, gestión de productos y programas, operaciones, etc.) que le ayuden a gestionar su servicio de principio a fin.

A medida que crece la demanda de un producto o servicio, en lugar de ampliar el equipo a muchos más miembros, buscamos la manera de dividirlo en equipos separados de dos pizzas que trabajen en una subárea del servicio con un solo subproceso. Esta mitosis mantiene una estructura organizativa más sencilla que preserva la agilidad, la autonomía y la responsabilidad única.

Al fin y al cabo, un equipo de dos pizzas no tiene que ver únicamente con el tamaño, sino con fomentar e impulsar la implicación y la independencia a nivel de equipo, desde la concepción hasta la ejecución, desde la mejora operativa continua hasta la iteración y la innovación constantes de los productos. Permite a los equipos trabajar con rapidez, experimentar de forma temprana y frecuente, y aplicar rápidamente lo aprendido para aportar valor a sus clientes. La innovación y la experimentación más rápidas también contribuyen a reducir el coste del fracaso: se aprende más rápido y con menos riesgo que en fases posteriores del desarrollo.

Aunque la estructura de equipo de dos pizzas ha funcionado para Amazon y AWS, reconocemos que puede no ser adecuada para todas las organizaciones, o para todas las unidades empresariales. Los equipos de dos pizzas no son perfectos, y no son inmunes a las limitaciones; un ejemplo es que con tantos equipos autónomos, de un único proceso, que trabajan rápidamente para satisfacer las necesidades de sus propios clientes, existe el riesgo de duplicación y desarrollo en silos. Se necesita contar con la estructura de gobernanza adecuada para decidir cuándo y cómo combinar los esfuerzos que son puramente repetitivos, sin reducir la capacidad de los equipos para impulsar la innovación en sus áreas de responsabilidad.

La experimentación rápida exige también la colaboración entre equipos para multiplicar el éxito y racionalizar los recursos. Aún más importante es la capacidad de captar y compartir lo aprendido a partir de los errores para aplicar mejor esas lecciones a futuros experimentos y ajustar la dirección de la iteración y las futuras decisiones de inversión.

Un aspecto de la organización de Amazon y AWS que ayuda a promover la gobernanza y la supervisión al tiempo que permite a los equipos funcionar de forma rápida, independiente y autónoma, es el concepto de líderes de un solo enfoque.

El papel de los líderes de un solo enfoque es vital a la hora de instituir el nivel adecuado de supervisión para retener la capacidad de un equipo a la hora de innovar de forma independiente en beneficio de sus clientes.

Los líderes ejecutivos de hoy en día se dan cuenta del enorme beneficio que supone ser capaz de ofrecer innovación y transformación digital rápidamente. La capacidad de comercializar rápidamente nuevos productos y servicios no solo es crucial para ofrecer un valor constante a los clientes, sino que también puede convertirse en una ventaja competitiva diferenciadora para su empresa. Pero a medida que aumenta la escala y el alcance de la empresa, los ejecutivos deben asegurarse de que están creando la estructura y el liderazgo adecuados para garantizar que los equipos están capacitados para funcionar con rapidez.

La gobernanza y la administración de los equipos deben proporcionar «barrera de protección» (mecanismos que permitan a los equipos funcionar con rapidez y tomar decisiones de alta calidad a gran velocidad) en lugar de «barreras de peaje» que impidan la velocidad al aumentar las líneas de aprobación o coordinación antes de permitir que los equipos avancen con experimentos innovadores.

En Amazon y AWS, el papel de los líderes de un solo enfoque es vital a la hora de instituir el nivel adecuado de supervisión para retener el potencial de un equipo para innovar de forma independiente en nombre para sus clientes, a la vez que se crean mecanismos coherentes que permiten el nivel adecuado de inspección y visión direccional. Los líderes de un solo enfoque ayudan a proporcionar una visión estratégica para luego apartarse del camino de su equipo. Los líderes de equipo deben ayudar a eliminar obstáculos en lugar de ser una barrera por la que deben pasar todas las decisiones. Los equipos pequeños, ágiles y autónomos que se centran cada día en sus clientes son los mayores expertos en su servicio y segmento de clientes.

Los líderes de un solo enfoque necesitan preservar la autonomía de su equipo para tomar las mejores decisiones para la empresa. La función de los líderes de un solo enfoque en la toma de decisiones de su equipo suele ser ayudar a guiar al equipo en situaciones en las que, incluso con la instrumentación de datos adecuada y el juicio más elevado, el camino a seguir puede no estar claro.

Un mecanismo utilizado en Amazon para facilitar la supervisión de los líderes de un solo enfoque en estos puntos de control son las narrativas escritas. En estos casos, las narrativas ayudan a describir el problema que ha surgido de cara al cliente, aportan información procedente de análisis en profundidad y datos que el equipo ha recopilado para informar sobre los siguientes pasos, y formulan la decisión que el equipo recomienda, junto con las vías alternativas consideradas y los riesgos y beneficios de cada una de ellas.

Aunque dedicar tiempo a escribir una narrativa puede parecer contrario a una ejecución rápida y constante, el uso de narrativas en Amazon y AWS ha generado beneficios extraordinarios. Uno de ellos es que el equipo, las partes interesadas y los expertos en la materia de la oferta del equipo y el segmento de clientes suelen debatir y perfeccionar estos documentos incluso antes de que lleguen al despacho del ejecutivo. Esto fomenta la colaboración y la diversidad de perspectivas, pone en tela de juicio las suposiciones y sirve para perfeccionar las ideas y recomendaciones del documento. En última instancia, esto suele conducir a decisiones de mayor calidad.

Hay muchas narrativas diferentes en Amazon y AWS. Algunas se centran en el lanzamiento de nuevos productos, como nuestro documento PR/FAQ (que significa nota de prensa y preguntas frecuentes), producto de nuestro enfoque de ingeniería inversa del cliente. Otras son revisiones operativas de la empresa (a menudo con periodicidad semanal, mensual y trimestral) que proporcionan inspección y gobernanza sobre las métricas clave, tendencias, tensiones, riesgos y oportunidades que surgen en la empresa de un equipo.

Disponemos de narrativas que proporcionan rigurosas revisiones de la preparación operativa antes del lanzamiento de cualquier nuevo servicio, profundizando para garantizar que los aspectos de la arquitectura de un servicio, su calidad y procedimientos de lanzamiento, y los procedimientos asociados de gestión de incidentes y eventos estén bien formulados y documentados. Otras narrativas, como nuestro documento de corrección de errores, se realizan posteriormente cuando un servicio repercute negativamente en los clientes. Estos documentos están elaborados por el equipo propietario del servicio, no para echarle la culpa a nadie, sino porque, al ser el único equipo propietario del servicio, es el que mejor conoce el servicio y a sus clientes.

En estos documentos de corrección de errores (o COE), el equipo profundiza en la descripción completa de lo sucedido, aportando análisis cuantitativos y datos pertinentes sobre el impacto del error de un servicio y por qué se ha producido. Desgranan las capas para identificar las causas profundas, incluidos todos los factores contribuyentes, y describen no solo cómo se ha abordado la causa, sino también qué se seguirá haciendo para garantizar que no vuelva a ocurrir, a menudo actualizando o creando nuevos mecanismos de inspección y mejora continua. Estos documentos se conservan en una base de datos en la que se pueden realizar búsquedas, de modo que el valioso aprendizaje pueda compartirse entre todas las funciones.