Last year an article by Jeremiah Lee made the rounds in the Design community since it essentially demystified the whole concept of “Squads” which Spotify has popularized in the industry (you can read that article here). It’s a very compelling article, and the intent for this article is neither to be a pseudo sequel on that topic, nor a rebuttal. It’s simply a reflection on my experiences and perspective on this particular Design Organization strategy, its benefits, challenges, and how much like Design Thinking itself, Organizations and Teams, have to essentially adjust the concept to their reality and ultimately figure out what actually works for them. Hopefully this article is a catalyst for some productive discussions.

Squads, Ownership and Accountability. For those wanting to read more about the Spotify model, Mark Cruth from Atlassian wrote an interesting article on the topic and on their process, which you can read here. In my professional experiences and according to my own perspective, PODs (or squads), have always functioned as a means to aggregate smaller teams around a particular vertical/product/feature, with the intent for those teams to develop a tightly woven relationship between themselves and in the process, grasp at a better understanding of the ecosystem in which they operate, all the while increasing their productivity and efficiency. That ecosystem includes the entire breadth of what constitutes a Product Experience, from Research endeavors and venues, through Ideation/Incubation, Implementation, and of course, the overall Customer Experience that is crafted. In a way, and very similarly to what the Spotify model illustrates, these PODs have the responsibility to understand the Business Case sustaining a particular vertical or product, and subsequently strategically put in place a plan that will sustain those Business Goals. All of this of course, married with Optimal Customer and Product Experiences perspectives, while also aligned with the overall Design and Business Strategy of the Organization (more on this topic below).

PODs have the great advantage of being agile and limber, since they’re typically small groups, who ideally adopt a Lean UX/Product Design cadence, aiming to understand problems, focus on users, devise an activity centered systems approach and frequently prototype & test in order to rapidly ideate and validate what they’re either mining/refining or implementing. The fact that these PODs are rather small, also implies that the collaboration between all its members has to be effective, and everyone has to be accountable for their engagement, responsibilities and deliverables. It also means that every team member needs to have a clear understanding what the KPIs are, both for the process and for the project itself. Much like the topic of Design Strategy (which I wrote about as well and you can read here), being effective in PODs does walk hand in hand, with being accountable to your peers and ultimately demonstrating results.

One of the main qualms and reservations that are derived from this structure, is the fact that each pod may become too much of an insular type of experience, and that is something that the team management has a responsibility in clarifying and preventing from happening. Cross collaboration between PODs should be incentivized whenever possible, since while they do have their own projects to focus on, the ability to learn from others is and should always be an important consideration to also prioritize. I have witnessed firsthand the consequences of pods and teams embarking on processes in an insular manner. This type of behavior has translated invariably into product experiences and engagements that are diametrically opposed to what cross platform and cross suite product offerings are all about, namely: Consistent, Optimized, Seamless, Orchestrated and Collaborative. The most effective POD strategies that I have worked on and witnessed on a daily basis, have the following qualities at their core, and if soundly implemented, bring about fruits that can be witnessed not only on one particular POD, but actually across all Design/Product/Development experiences.

1. Transparency — Making sure to keep PODs well informed of their initiatives and what level of progress they find themselves in. Also, making sure that the PODs themselves and its members, understand what is expected of them, in terms of responsibilities, deliverables and timelines. It’s fundamental that transparency between different PODs occurs, since it allows for teams to visualize problem solving strategies, research outputs, interaction patterns discussed and implemented, to name but a few of the arresting information that can be derived from this type of knowledge sharing. Having an opportunity to matrix knowledge across the different PODs also allows for effectiveness of the process itself, diminishing iterative cycles and improving efficiency.
2. Autonomy & Ownership — One of the most rewarding aspects to the POD strategy, is the fact that these teams are empowered to implement the process as they see fit, but also and just as importantly, to focus on solving client/customer problems thoroughly and rapidly. The team members become more aware of the problems they’re aiming to solve, they have the opportunity to identify paths for innovation, while also familiarizing themselves with the journeys of the customers/clients/users on a deeper level. This level of knowledge, combined with their ownership of what is being crafted, allows for everyone to be more invested in its outcomes, not to mention, also solidifies the bonds between the team members themselves.
3. Accountability & Deliverability — As I mentioned above, and as Stan Lee wrote on his “Spider-Man” adventures, “With Power comes Great Responsibility”, and that is the same situation with PODs. With Autonomy and Ownership also brings the implication that team members are accountable and have to be aware of their responsibility to deliver results, on multiple levels. These levels include, team integration, solving customer/client/user problems, researching thoroughly what they’re proposing (which includes all levels of research, including contextual, ethnographic, usability testing, analytics, reviews, voice of the customer), collaborating with other PODs and accounting for the consistency narrative to be carried throughout all the Implementation that is taking place. This accountability and deliverability also walks hand in hand with creating a close relationship with Design/Product/Development Leadership and the strategy that exists currently to sustain all these endeavors.

Reality Check — The POD strategy is and has been implemented across a variety of Organizations currently on the market, even if articles such as Jeremiah Lee’s sheds light on how Spotify views this strategy they magnified on the market, and essentially they question its own validity. As I mentioned at the beginning of the article, much like Design Thinking, a process is only as good as the teams implementing it, and adjusting it to their own needs and constraints. The most successful POD experiences I’ve witnessed, always had a trifecta of team members, encompassing Design/Development/Product representatives, but with an array of other team members from diverse departments providing expertise and guidance in their own fields (such as Customer Support/Marketing/Sales/Inventory Management/Diverse Stakeholders). The PODs themselves have the power to distill the Design process, in a way that makes them both rapid and efficient when it comes to problem solving, but that also entails, knowing how to manage the process itself, how to bring the right team members to that same process, parse through the pertinent information and strategize the more fruitful collaboration stances. All those tasks and initiatives will in turn make them all the more successful in both their solution output and the process implementation itself. The number of people on these PODs will and can vary, but typically they’re teams ranging from 4 to 10 people, which once again reinstates the limberness of the structure and of how the process can be applied and finessed. However, and much like I alluded to previously, and have mentioned in other articles: a process has to be sensical with what an Organization can do, and where they are from a Design maturity perspective.

As the Nielsen Norman Group mentioned in one of their articles, there are different levels of Design Maturity in Organizations, including Absent, Limited, Emergent, Structured, Integrated and Design Driven. Before embarking on this process, it’s important that teams realize where they are on their journey, and how they can progressively embark on this type of strategy. For many that will include having a strategy that starts somewhat differently, for instance anchored on a consultancy/Design Agency type of approach. Typically this implies having a Design group which solves problems according to the different verticals they interact with, each problem/challenge on its own, until this POD strategy can actually be adopted. But once again, that takes time and it’s a process which also includes bringing further Design Literacy to the Organization. Ultimately, independently of what different articles reinstate or advocate for, the process itself starts with the Organization wanting to take the step in a direction of being more Product and Design Centric, which of course equates with being more Client driven. Getting there is something that teams can research, clarify and implement according to where their resources are and also what they establish as their goals on the path to the Design Centric Culture.

I’ll conclude this article with a quote from Molière on the topic of Accountability, which is mentioned throughout the article:

“It is not only what we do, but also what we do not do, for which we are accountable.”