--- title: Collaborative Org Design - How to Start (Even If You’re Not Spotify) description: If reorganizations so often suck, what is a better way to do it, and how can you start, even if you're not Spotify? date: 2025-05-25 author: Mikael Brodd keywords: reorgs, organizational transformation category: Product Development lastModified: 2025-05-25 slug: collaborative-org-design --- In the previous article, [Reorgs Don't Have to Suck - A Better Way Forward](https://www.betterproductwork.com/blog/reorgs-dont-have-to-suck), we discussed why re-orgs suck and how Spotify took another path than the traditional top-down, management driven approach. Most re-orgs fail due to: * **Misalignment with reality**: Leaders often lack day-to-day, ground-level understanding of how teams actually work. * **Lack of context & meaningful participation**: As reorgs happen *to* employees, not *with* them, employees are less inclined to actively support the result. The problem isn’t that employees “lack buy-in.” It’s that they’ve been excluded from the process. * **The Waterfall Irony: Fixed Plans for Agile Teams**: Traditional reorgs assume you can design the "perfect" structure up front, much like old-school waterfall project management. * **Unintended Consequences: The Reorg Death Spiral** Instead of solving problems, poorly planned reorgs often create new ones. Silos appear where none existed before. **What if, instead, the people closest to the work shaped how it’s done?** As we wrote in the previous article, Spotify took another path. Instead of designing a “perfect” org chart behind closed doors, they decided to involve everyone directly, which led to great results. Simply put, shared ownership creates engagement, accountability, and adaptability. Since then, over the years, we have done this repeatedly at different clients — media companies, Telcos etc. — and have now found a structure that we feel works really well. So well that the last time we did this, we received feedback such as: “*Usually, people are hesitant and resist this kind of change, but this time, they really welcomed and embraced it*” and “*This was the most uneventful re-org I’ve ever seen. I’ve never experienced a re-org go this smoothly.*” ## Why this works As we involve team members in the work of creating the new organization, we gain perspective and feedback from the people closest to the work. This helps us understand if we are missing something in how people collaborate and how value is created, which is important as we want to avoid breaking what works while addressing real problems. Since the people who are affected by the re-org are part of designing the new organization, they’re more engaged and feel responsible for making it work, because they’ve co-created the solution, not just given feedback on someone else’s plan. That means more people understand the bigger picture — the business and strategy context, the trade-offs involved, architecture and dependencies across teams — and feel ownership and agency, since they were part of the redesign. As a result, the company becomes capable of fine-tuning the organisation continuously instead of reverting to big bang re-orgs every other year. ## How to do it Beware! This is not a recipe or a model. It looks like there are sequential steps, but please remember that one of the common anti-patterns in re-orgs is using a waterfall approach to establish agility. Instead, we need to make sure that we collect and incorporate feedback from each activity, and course correct when needed. ### Understanding the Direction It is really important that all involved are aligned on the direction of the company. Where is it heading? What kind of company do we want it to become? For instance, are we a scale-up trying to grab a larger piece of the market, or are we a well-established company that needs to respond to new technology or new competition in the field? Understanding the direction is a big part of formulating the goal of the new organization, answering the question: what should it be optimized for? ### Show what great looks like A central part of aligning on the direction is to understand what the future could look like. It is no secret how the best product companies work, as there is an abundance of books, talks, podcasts etc. that describe how they operate. We use that as inspiration, and mix it with our own experience, having worked in the trenches at some of the best companies for a long time. That gives us a lot of examples of what great day-to-day work actually looks like. ![Examples of books describing how the best product companies work](image1.png) We typically teach classes, introducing the future way of working, how the best companies do it, and inspire participants to see what the aspiration is. ### Find constraints and heuristics It is impossible to create the perfect organization. All organizations have their pros and cons. So it is important to decide what pros we want. What are we optimizing the organization for? ![Design goals and heuristics](image2.png) As a part of that work, we co-create a list of constraints and heuristics that will guide what the new organization should look like. Things like * Team size - classical team research suggests a size around 7 * Ownership - what part of the product, or products, does the team own? * Autonomy - To what degree should a team be able to build, test and deploy independently? * Scalability - Fewer dependencies between teams makes it easier to scale employees in areas * Diversity - To what extent is it important that each team is diverse in terms of age, gender, experience, skill set, ethnicity etc.? * Geographic location - should teams be distributed, on-site, or hybrid? Since we are talking about a team-based organization, we already know some things to be true. Teams shouldn’t be too large. They should be cross-functional and self-managed and in general, more autonomy is better. So some constraints and heuristics are non-negotiable and given from the start. ### Introduce Team Topologies The book Team Topologies, from Matthew Skelton and Manuel Pais, puts names on many things we have felt throughout the years when designing different team organizations. Introducing Team Topologies often helps untangle some knots. Many believe that all cross functional teams should look the same and deliver customer value, which often is impossible because such teams would simply become too big. ![Team Topologies](image3.png) The model introduces four types of teams (stream-aligned, platform, enabling, and complicated sub-system) and three different interaction modes (collaborating, facilitating, and X-as-a-service). These give us more tools in our org design toolbox. The book also explains the concept of fracture planes, i.e. natural seams in the teams. When scaling the organization these fracture planes can guide how to split an existing team. Instead of spinning up entirely new teams made up of inexperienced hires, fracture planes help you identify where to split and blend new employees with experienced ones. We usually run a one-hour webinar-style introduction for the whole company, along with tailor-made sessions where needed. Things like book clubs, watching recordings from conferences where the authors talk about Team Topologies are other ways of getting more knowledge. While we often use Team Topologies as a practical lens, our thinking has also been influenced by Domain-Driven Design. As former developers, many of us instinctively look for natural seams in the domain, what DDD would call bounded contexts, when thinking about team structures. We don’t typically apply DDD as a formal method in these org design efforts, but the mindset has shaped how we identify meaningful boundaries for teams. ### The Team API A practical tip is to start documenting the ideas about teams in the new organization in “team APIs”. A Team API, introduced in the Team Topologies book, is a way of capturing essential information about a team, very much like team chartering. ![Team API template from Miroverse](image4.png) A Team API is primarily intended to be used by other teams, or the rest of the organization. It is a way of describing what the team is about. Things like * Mission * Code/System/Product ownership * Roadmaps and backlogs When you start out designing the new organization, keep the information in the team APIs limited. Start out with a draft mission, team type (from Team Topologies) and what competencies are needed to fulfill the mission. Do not add names/individuals to the Team API just yet. Populating teams is addressed later (see **Self selection to create new organization** below). It is of course ok to change the Team API template and make it your own. Many clients we work with simplify it, especially in the beginning. Add and remove as you see fit, it is after all your organization. ![Example of simplified Team API](image5.png) ### Involve all being affected by the change When we have established * Change Direction * Optimization goal with the new organization with constraints and heuristics * What great looks like * Team Topologies We have the main ingredients for organizational design. Now it is time to work together with selected stakeholders, making sure team representatives are included among them. The aim is to get an initial idea of the organizational design. When that’s in place, the next step is to involve more. We involve as many as possible from those who are being affected by the change, as is feasible. We run feedback workshops where we present the initial idea, and collect feedback. This work is highly iterative, continuously updating the design of the organization based on the feedback given. ### Self selection to create new organization When we have settled on an organizational design, the next step is to form the teams with the people involved. This is really a collaborative exercise, involving all those who are affected by the change. We strongly suggest using the concept of Team Self Selection, as outlined in the book “*Creating Great Teams - How Self-Selection Lets People Excel*” by Sandy Mamoli and David Mole. The basic concept is simple. We involve all the people who will be part of the new org design, and let them choose where they will make the best contribution, given a collection of constraints. ![Creating Great Teams](image6.png) It’s important to emphasize that this isn’t simply about picking the team you’d most enjoy being on. It’s a chance to think like an owner: What does the organization need? Where can I be most useful, given my experience and strengths? Personal preference is a factor, but so are the goals, constraints, and the needs of each team. When we introduce this concept, it is often met with some degree of skepticism. This goes back to the anti-pattern of management selecting who goes where, which is the traditional way of doing re-orgs. But when we involve people in problem solving, they take more ownership of the solution. This is also true when forming teams. Letting employees take a large part in deciding which teams we have, and individually choose which team they should be on, leads to greater motivation and engagement. Team members of course know the most about competence needed on a team to fulfill its mission. Therefore, letting people select the team they join will also result in better teams as people know what they can bring (competence, experience etc.). ## Summing up: Benefits of Collaborative Org Design Re-orgs don’t have to be disruptive, confusing, or top-down mandates that leave people disengaged and uncertain. As we’ve seen time and again, involving the people closest to the work doesn’t just make the process smoother, it makes the result better. When people co-design their organization, they understand the why behind it. They feel ownership over the solution, and they’re much more likely to make it succeed. That’s why we prefer Collaborative Organizational Design. It leads to stronger, more resilient organizations — not just because of the structure you land on, but because of the way you got there.