The CEO of Airbnb has a great quote: he describes himself as a designer, but unlike most designers, he designs the business model and the organization of a company. When interviewing different PMs, I also realized that every company has its own distinctive way of organizing work. In this blog, we will examine the organizational structures of three companies and the role of PMs within them.
First, Spotify. It is important to note that the structure discussed here reflects Spotify around 2012. Henrik Kniberg and Anders Ivarsson also emphasized that Spotify was constantly evolving, so this model should be understood more as a snapshot of the company at that time.
Guided by an Agile engineering culture, Spotify used Squads as its basic working units, with multiple squads forming a Tribe. There were also cross-squad groups for knowledge sharing and professional development, including Chapters and Guilds. These squads were long-term, mission-oriented teams, usually made up of engineers, designers, and people with different areas of expertise. The goal was for each squad to have most of the toolkits it needed to accomplish its mission.
Squads generally had a high degree of autonomy and could interact directly with different stakeholders. Each squad had a Product Owner, who was responsible for prioritizing the work and maintaining the product backlog. Product Owners from different squads collaborated with one another to maintain a high-level roadmap that showed where Spotify as a whole was heading.
Therefore, the PO was not a traditional manager, but more of a product and prioritization leader. The PO had relatively clear authority over questions such as “What should we prioritize next?” but did not decide exactly “how the work should be done.” Squad members participated in planning, chose specific tasks, and collaboratively decided how to build the product. Other roles, including Agile Coaches, Chapter Leads, System Owners, and Chief Architects, provided different forms of support and guidance throughout the process.
One advantage of this way of working was that it enabled a high degree of autonomy, speed, and flexibility. Squads did not need to wait for multiple layers of approval and could respond relatively quickly to users and stakeholders.
However, full autonomy also came with potential downsides, including a loss of economies of scale, as well as dependencies and coordination problems across squads. Roles such as System Owners and Guild Coordinators helped preserve squad autonomy through horizontal coordination. In this sense, Spotify distributed different types of authority across different roles rather than concentrating them in a single manager.
Airbnb also went through a process of restructuring. Right before the company was preparing to go public, Airbnb ran directly into Covid. Chesky described the company as having “lost 80% of our business” within eight weeks. This forced the company to rethink how it was organized. In order to help the entire company deliver in a more focused and faster way, Airbnb shifted toward a more centralized and integrated way of working.
More specifically, Airbnb moved from a business unit organization to a functional organization. Previously, different teams had their own roadmaps, and sub-teams even had their own sub-roadmaps. After the restructuring, the company moved toward one shared roadmap, with CEO serving as the keeper of the roadmap and continuously updating it. Chesky even described the shift as beginning to “pull decision-making like an orchestra conductor.” At the same time, the company reduced the number of projects on the roadmap to roughly 10% of them, and then concentrated its strongest people and major resources on those few important projects.
The responsibilities of PMs were redistributed in this process. Airbnb reduced the traditional product management function and combined part of product management with product marketing. Product marketing became involved early in product definition, starting from narrative, market insight, and user problems, and working with designers to define what the project actually was. At the same time, design was elevated into a major independent function, with significant influence over the overall product experience, rather than simply serving as a service function for PMs.
Therefore, at Airbnb, no single PM independently held decision-making authority over the entire product. Instead, work was pushed forward more through influence and cross-functional collaboration. The philosophy behind Chesky’s approach was that too much local autonomy can create fragmentation and bureaucracy.
My interpretation is that this transformation happened at a very particular moment, when Airbnb was facing an existential crisis while still hoping to eventually complete its IPO. In that sense, it was almost like a “shot in the arm” for the company: by reducing the number of projects, concentrating resources, and pulling some decision-making authority back toward the center, Chesky helped the company regain focus and coherence during the crisis.
Finally, Zappos also went through a process of transformation. The company realized that its previous way of operating partially under Holacracy and partially under the legacy management hierarchy was not efficient enough, so it decided to move more completely away from the traditional management hierarchy toward self-managed, self-organizing, business-centric circles. These circles are somewhat similar to Spotify’s squads in that they organize people with different areas of expertise around a business goal, rather than keeping everyone within traditional functional silos.
However, compared with Spotify, authority at Zappos is distributed even more broadly. The core idea is not to have a traditional manager or PO make decisions centrally, but instead to distribute different types of authority across different roles and accountabilities, allowing decisions to happen as close as possible to where the problem or work originates.
Zappos still needs clearly defined roles, decision processes, recruiting, compensation, and team structures, as well as specific accountability and conflict-resolution mechanisms. For example, when a conflict arises, employees are first expected to have a 1:1 conversation themselves. If the conflict cannot be resolved, it can be escalated to a peer council, and eventually even to the CEO.
Therefore, more accurately, Zappos follows a no-traditional-manager model. The responsibilities that were previously concentrated in traditional managers are instead broken apart and redistributed. Personally, I think this system relies heavily on trust. It requires employees not only to have greater autonomy, but also to be willing to actively take responsibility, handle conflicts, and be accountable for their own contributions.
Personally, I would most want to work at Spotify. One reason is that the responsibilities of the PO seem relatively clearly defined. Another is that Spotify’s combination of vertical and horizontal management feels especially worth learning from. The way it balances squad autonomy with cross-functional coordination strikes me as both creative and thoughtfully designed.
Sources:
https://agileanit.com/wp-content/uploads/2018/10/SpotifyScaling.pdf?utm_source=chatgpt.com
https://www.figma.com/blog/config-brian-chesky-airbnb/?utm_source=chatgpt.com
https://www.fastcompany.com/3044417/zappos-ceo-tony-hsieh-adopt-holacracy-or-leave?utm_source=chatgpt.com
