A smoother reorganization starts by letting teams design it

Joakim Sundén describes collaborative organization design, an approach developed at Spotify and later applied in other settings. He worked at Spotify as it grew from roughly eight teams to 200, and is now a founding partner at Better Product Work.

Asked for a word associated with reorganization, audience members offer layoffs, wasted time and chaos. Sundén asks why a process intended to improve an organization so often produces those reactions.

His explanation is that management often designs structures too far from daily work. An org chart organized around functions or business units can ignore system dependencies and actual collaboration, creating more handoffs even when it looks neat on paper.

People may resist a change because its purpose is unclear or they cannot influence it, not because they oppose all change. Sundén also criticizes treating reorganization as a large fixed plan: conditions can change before a lengthy design has settled.

He acknowledges why leaders choose a top-down approach. Leaders own strategy and accountability; budgets or layoffs may limit participation; and a management-only meeting can feel faster than involving a hundred people. He argues that apparent speed may conceal costly shallow analysis.

This is not an argument against leadership decisions. Leaders know the market and strategy, while people doing the work know daily collaboration, painful interfaces and technical dependencies. The design problem is how to combine those two kinds of knowledge.

The audience identifies motivation, time, knowledge, trust, communication and a shared goal as conditions for participation. Sundén groups the conditions into control, clarity, competence and context: people need authority, a clear destination and boundaries, relevant skills, and an environment that supports participation.

The model builds on submarine captain David Marquet’s work. Sundén’s team adds context and says the amount of control should match the clarity and competence available to a team.

Giving people control without sufficient clarity or skill can produce chaos or paralysis. Giving capable people a clear goal but no control creates frustration and bureaucracy. The productive zone is where responsibility is matched by the ability and information to exercise it.

A manager who responds to every prioritization question by ordering tasks A, B and C may feel helpful, but has taken control back. Sundén suggests asking which information, skill or condition the team lacks and developing it so the team can make the next decision itself.

Context can undermine nominal empowerment. A team may choose a button’s color while a stakeholder controls the actual product, or remain blocked by legacy systems and dependencies on groups with different goals. Authority must be considered alongside those constraints.

The case is a growing B2B company that had reverted to top-down priorities and task micromanagement under pressure. Rather than begin by drawing a new chart, Sundén’s group first changed how the organization would conduct change.

A cross-functional change team included engineering managers, developers, testers, people and culture, sales and executives. The facilitators modeled an outcome-focused process, worked alongside the team and then coached it to run the work itself, using leading and lagging indicators to assess progress.

They introduced a product operating model and discussed what successful empowered teams might look like. The change team then described a concrete future for its own company: what would be different in two years, and which decisions teams would actually own.

They taught Team Topologies through talks, recordings and a book club. Shared concepts included teams aligned to a value stream, platform teams and enabling teams that spread expertise such as test automation. The goal was a common language for discussing possible designs.

One useful concept was a “fracture plane”: a natural seam where a system or organization can be divided. Location, business domain, regulation or different rates of change can suggest possible boundaries; none determines the answer on its own.

The group agreed on what to optimize for and listed constraints and heuristics: diversity, geography, team size, ownership, scalability, autonomy, cognitive load and the company’s future vision. They weighted these criteria to compare alternatives and made the trade-offs explicit.

Small groups drafted initial team missions and structures. Leaders were disappointed because the proposals reflected the current organization rather than the future they wanted. Instead of taking the work back, they asked what strategic clarity was missing.

Leaders refined and shared the 2026 vision, product strategy, roadmap and expected hiring plans. Teams then returned to the design. This changed the information available for the exercise without removing leadership’s responsibility for strategy.

The next tool was a team API: a draft of each team’s mission, type, needed competencies, metrics, systems and likely work. Participants adapted the template and added an “anti-backlog” for work they believed belonged elsewhere. The documents were thinking tools, not merely records.

The design moved to a shared board so more people could participate asynchronously and compare options against the criteria. The group expanded to include development teams, incorporated their suggestions and iterated toward a design for both present staffing and future growth.

Because there were not yet enough people for every future team, the organization grouped work for the present but identified the seams where teams could later split as headcount grew. That made growth part of the design rather than an afterthought.

The group then invited people to select teams. Managers worried that personal conflicts or preferences would prevent a workable result. Sundén says the question was framed around the company’s agreed goals and constraints, as well as individual preference.

Management prepared a week of information, daily questions and answers, and standby meetings to handle difficulties. Instead, people largely put their names on teams by Monday afternoon, and few came to complain. Managers described it as unusually uneventful and smooth.

Sundén attributes that experience to participation from the beginning, which reduced surprises. He wants organization design to become a continuous capability that teams can refine, rather than a painful one-off event repeated only after organizational debt accumulates.

He summarizes the changes through the four conditions: create a collaborative context, clarify purpose and decision boundaries, teach design competence, and gradually give teams more control. Leadership retains strategy, vision, constraints and final decisions; teams shape missions, boundaries, interfaces and their own placement.

The sequence matters: change the environment before changing the chart, make the problem understandable before asking people to solve it, and expand participation as clarity and competence grow. Sundén’s aim is to create conditions in which people can keep improving the organization themselves.