No more pizza teams
Introduction
A few weeks ago, Justin Garrison panned a thought-provoking article on Amazon's recent layoffs, delving into what he called "Silent Sacking". The article, "Amazon's Silent Sacking", is a great read and covers multiple topics. One of the sections of the article, "No more pizza teams", caught my attention and I wanted to share my thoughts on it.
When you've been working in the software industry for a while, such as myself, you might not get wiser, but you do start to see trends and patterns repeating themselves. Whether it's technologies, methodologies, architectures, or management styles, they rise, have their momentum, and eventually yield to the next wave. The DevOps culture and the two-pizza team rule, popularized by Jeff Bezos at Amazon, seem to be experiencing this cyclical ebb.
Amazon's two-pizza team rule
The two-pizza rule or two-pizza team is a concept that was popularized by Jeff Bezos at Amazon. When Amazon started, he instituted a rule that no team should be larger than what two pizzas could feed. Note that American pizzas are large enough to feed 4-6 people and that the rule is not literal, but a way to keep teams small and agile.
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
This kind of team focuses on the outcome and delivery as opposed to the activity and process. They aren't organized in terms of the skills they provide such as operations, development, quality assurance, and so on, but in terms of the product or service they deliver.
Coming back to the article, Justin rightly highlights it as the purest implementation of DevOps he's ever seen. I can perfectly see how this kind of team topology can be a great enabler for the DevOps culture. The DevOps methodology is all about delivering value and being able to respond to the customer's or user's needs as fast as possible. Having small, autonomous teams is a great enabler to shift organizations towards a DevOps culture.
Amazon's success prompted companies worldwide to emulate this model, much like the broader adoption of the DevOps culture. The industry embraced this approach, especially during the peak of the microservices architecture trend.
Successful companies such as Amazon, Spotify, and many others, were proudly speaking about their cross-functional, autonomous, DevOps-based, team topologies not so long ago. Every other company followed their lead because "If it's good for Amazon it certainly is good for us". So everyone was talking DevOps for a while.
The cost of DevOps
From a product developer's standpoint, a landscape of companies with small, autonomous teams working in a DevOps culture sounds idyllic. However, as Justin points out, these types of structures are pretty expensive to maintain. In addition, high operational costs, exacerbated by frequent employee turnover, lead to the loss of valuable knowledge.
Amazon's recent policy shift towards returning to the office (RTO) has, as Justin puts it, "emaciated" their teams. Teams are having trouble "just trying to keep the lights on". They are trying to reduce costs by reducing duplication and centralizing expertise. Organizing their structure by providing centralized services such as platform engineering (sounds familiar?).
Conclusion
In an economically challenging period, especially for the tech industry, we might witness more companies abandoning their DevOps culture and reverting to siloed structures 😔. While the dream of small, agile teams persists, the harsh reality of operational costs and knowledge loss may prompt a reconsideration of organizational structures. The journey ahead will likely involve a delicate balance between the efficiency of streamlined teams and the practicality of centralized expertise.
Let's see what the future holds for us.
References
