No more pizza teams
Introducción
Hace unas semanas, Justin Garrison publicó un artículo acerca de los recientes despidos en Amazon, profundizando en lo que él llamó "Silent Sacking". El artículo, "Amazon's Silent Sacking", es una gran lectura y cubre múltiples temas. Una de las secciones del artículo, "No more pizza teams", llamó mi atención y quería compartir mis reflexiones al respecto.
Cuando llevas un tiempo trabajando en la industria del software, como es mi caso, puede que no te hagas más sabio, pero sí que empiezas a reconocer tendencias y patrones que se repiten. Ya sean tecnologías, metodologías, arquitecturas o estilos de gestión, todas ellas surgen, tienen su momento y eventualmente ceden ante la siguiente ola. La cultura DevOps y la regla de los equipos de dos pizzas, popularizada por Jeff Bezos en Amazon, parecen estar experimentando este ciclo de ida y vuelta.
La regla de equipos de dos pizzas de Amazon
La regla de equipos de dos pizzas o equipos de dos pizzas es un concepto popularizado por Jeff Bezos en Amazon. Cuando Amazon comenzó, instituyó una regla que decía que ningún equipo debería ser más grande de lo que dos pizzas pudieran alimentar. Nótese que las pizzas americanas son lo suficientemente grandes como para alimentar a 4-6 personas y que la regla no es literal, sino una forma de mantener los equipos pequeños y ágiles.
We try to create teams that are no larger than can be fed by two pizzas...
We call that the two-pizza team rule...
Jeff Bezos
Este tipo de equipos se centran en el resultado y la entrega en lugar de en la actividad y el proceso. No están organizados en términos de las habilidades que proporcionan, como operaciones, desarrollo, aseguramiento de la calidad, y demás, sino en términos del producto o servicio que entregan.
Volviendo al artículo, Justin destaca acertadamente que es la implementación más pura de DevOps que ha visto nunca. Puedo ver perfectamente cómo este tipo de topología de equipos puede ser un gran facilitador de la cultura DevOps. La metodología DevOps trata de entregar valor y ser capaz de responder a las necesidades del cliente o usuario lo más rápido posible. Tener equipos pequeños y autónomos es un gran facilitador para que las organizaciones se desplacen hacia una cultura DevOps.
El éxito de Amazon llevó a empresas de todo el mundo a imitar este modelo, al igual que a la adopción más amplia de la cultura DevOps. La industria abrazó este enfoque, especialmente durante el apogeo de las arquitecturas basadas en microservicios.
Empresas de éxito como Amazon, Spotify, y muchas otras, hablaban con orgullo de sus topologías de equipos DevOps, autónomos y multidisciplinares no hace mucho tiempo. El resto de empresas siguieron su ejemplo porque "si es bueno para Amazon, ciertamente es bueno para nosotros". Así que todo el mundo hablaba de DevOps durante un tiempo.
El coste de DevOps
Desde el punto de vista de un desarrollador de producto, un panorama de empresas con equipos pequeños y autónomos que trabajan en una cultura DevOps suena idílico. No obstante, tal como señala Justin, este tipo de estructuras son bastante caras de mantener. Además, los altos costes operativos, exacerbados por la rotación frecuente de empleados, conducen a la pérdida de conocimientos valiosos.
La reciente política de Amazon de volver a la oficina (RTO) ha, como dice Justin, "emaciado" a sus equipos. Los equipos tienen problemas incluso para "intentar mantener las luces encendidas". Están tratando de bajar costes reduciendo la duplicación y centralizando el expertise. Organizando su estructura proporcionando servicios centralizados como platform engineering (¿suena familiar?).
Conclusión
En un período económicamente desafiante, especialmente para la industria tecnológica, podríamos ser testigos de más empresas que abandonan su cultura DevOps y vuelven a las estructuras en silos 😔. Mientras el sueño de los equipos pequeños y ágiles persiste, la dura realidad de los costes operativos y la pérdida de conocimientos puede llevar a reconsiderar las estructuras organizativas. El camino por delante probablemente implique un delicado equilibrio entre la eficiencia de los equipos optimizados y la practicidad del expertise centralizado.
Veamos qué nos depara el futuro.
Referencias
