--- title: Reorgs Don’t Have to Suck - A Better Way Forward description: Reorganizations. We have all been in them. How come they so often suck? date: 2025-05-02 author: Joakim Sundén keywords: reorgs, organizational transformation, category: Product Development lastModified: 2025-05-02 slug: reorgs-dont-have-to-suck --- ## Re-orgs Suck (and Why It Matters) If you’ve worked at a company for more than a couple of years, chances are you’ve been through at least one reorg. Maybe more than one. Maybe so many you’ve lost count. But how do these experiences usually feel? When we talk to people about reorgs, we mostly hear words like confusing, frustrating, and chaotic — though occasionally also alignment and opportunity. That’s the paradox: reorgs promise clarity, but often deliver confusion. If reorgs are supposed to make things better, why do they so often feel... like this? ![Reorgs are often confusing](reorgsareconfusing.png) The root cause is that most reorgs follow a top-down, management-driven approach — one that often backfires. Let’s look at why. ## Why Most Reorgs Fail ### Misalignment with reality Leaders often lack day-to-day, ground-level understanding of how teams actually work. A reorg based exclusively on business units or functional departments, without taking real workflows into account, can accidentally increase dependencies and slow everything down.~~ ~~Team Topologies and Conway’s Law show that organizational structures shape software architecture — bad structures create friction, delays, and frustration. ### Lack of Context & Meaningful Participation People don’t resist change just for the sake of it. They resist when the purpose isn’t clear, when change feels arbitrary, or when they have no say in shaping it. The problem isn’t that employees “lack buy-in.” It’s that they’ve been excluded from the process. Reorgs happen *to* them, not *with* them. ### 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. But the world moves too fast. By the time a year-long reorg is rolled out, business conditions have often shifted dramatically. Teams end up stuck in a structure that no longer fits. ![The Waterfall Irony: Fixed Plans for Agile Teams](comicagile.png) ### Unintended Consequences: The Reorg Death Spiral Instead of solving problems, poorly planned reorgs often create new ones. Silos appear where none existed before. Cross-team collaboration gets harder, not easier. People spend more time figuring out the new structure than delivering customer value. The result? Another reorg... and another... and another. ## Why Top-Down Reorgs Persist If top-down org design is so flawed, why do companies keep doing it? Because change is hard. Because uncertainty is scary. And because, in moments of disruption, the instinct is often to ‘fix the org’ from the top down. Most managers simply haven’t seen another way. Traditional reorgs are what they’ve experienced themselves. It’s what’s taught, what’s modeled, and what many consultants still recommend. More collaborative approaches are, in a sense, a secret hidden in plain sight. There’s another reason too. Some leaders see designing the organization as their responsibility, something they must decide and announce. After all, if you are accountable for the results, shouldn’t you control the structure? It’s understandable. But there’s a better way. **What if, instead, the people closest to the work shaped how it’s done?** ## How Spotify Took a Different Path At Spotify, we started asking ourselves a simple question: if we trust our teams to make product and architectural decisions, why wouldn't we trust them to shape how we’re organized? After all, no one understands the work better than the people doing it. So instead of designing a “perfect” org chart behind closed doors, we decided to involve everyone directly. First, we made sure teams had real context. Not just a list of objectives, but the why behind them. Whether it was expanding into new platforms like tablets, responding to new competitors like Alexa, or sharpening our existing missions, everyone needed to understand the bigger picture. Sometimes an extended leadership group sketched out rough proposals to kick things off; other times, we opened up the discussion without predefined proposals, letting teams explore new possibilities within the real-world constraints they faced. Either way, the process was open, not top-down. Teams then participated in a series of collaborative workshops. Together, they shaped team missions, discussed the systems and assets each mission would own, the skills required, the likely stakeholders and success metrics. Some team members focused only on areas where they had deep expertise; others joined more broadly to bring valuable perspective across different domains. Slowly but surely, a structure emerged — not designed by executives alone, but co-created by the people who would live and breathe it. ![Teams collaborating on the new org design](collab.png) Once the missions were defined, we didn’t simply assign people to teams. Instead, we asked everyone: “Given this mission, this context, and your strengths — where would you have the biggest impact?” Over a few days, people self-selected into teams. Some decisions were obvious, others needed conversations and support. But the result was an org designed with ownership built in from the start. Of course, questions always came up: what if everyone wanted the same mission? What if no one picked a critical area? We’ll cover those common what-ifs (and how we handled them) in a future post. (Until then, if you're curious, we recommend Creating Great Teams by Sandy Mamoli and David Mole, which was allegedly at least partly inspired by us at Spotify.) At the time, we didn’t call it anything special. Looking back, though, it’s a good example of what we at Better Product Work now call Collaborative Org Design: involving the people closest to the work in shaping how teams are structured. Done thoughtfully, it leads to designs that better fit the work and goals, stronger alignment, and a deeper sense of shared ownership. In a follow-up article, we’ll share more about how we apply these ideas with clients today and how you can start using Collaborative Org Design to support your own teams.