Reteaming for Faster Flow: A Case Study

How do you design teams so they can continuously evolve while maximizing the value stream in your company? This question arises sooner or later in every growing software company. In many organizations, teams form the foundation upon which companies build their entire organizational design. In this case study, I explain how we chose a participatory approach for Pirate Ship to master exactly this challenge.

Together with Susanne Kaiser, the German founders of Pirate Ship, and the development teams, we put the Architecture for Flow approach, developed by Susanne, into practice and guided a reorganization process that actively involved the teams in all decisions.

What to expect from this case study:

• How we used Architecture for Flow as a holistic approach for team reorganization
• Which workshops and formats proved successful in the participatory redesign of teams
• How we worked with self-selection and consent-based decision making
• What learnings can be derived for similar reorganization processes

Pirate Ship is a company founded in 2014 that offers cloud-based shipping software for small and medium-sized businesses, making shipping as easy and affordable as possible for them. What makes it special: The software is free to use, with the business model based on partnerships with shipping service providers.

The company operates from two locations: the headquarters with customer support, marketing, finance, and partner management is in the USA. Software development is based in Hamburg, Germany, where around 30 developers are now employed.

The major growth spurt began in 2021. Until then, the Hamburg development department had worked as a single team — with the characteristic spirit of a startup crew: little structure, lots of freedom, everyone working on everything. When the team was split and an infrastructure team was additionally created in 2022, this meant a significant cultural change, especially for the "original crew." But the previous team setup had reached its limits.

In 2023, it became apparent that further growth was imminent. The existing teams were reaching their limits - both in terms of the size of their domains and workload. The two German founders & managing directors wanted to take a different approach this time: The new team structure should be sustainable and flexible to enable future growth. I accompany the German organization and its managing directors as a consultant and sparring partner and recommended collaboration with Susanne Kaiser as an expert in Team Topologies, Domain Driven Design, and Wardley Mapping and her Architecture for Flow approach derived from these methods.

In 2023, there were three feature teams and one infrastructure team. At the center was a PHP monolith that had grown over the years. The teams were struggling with several challenges:

• Overload: The teams were at their capacity limit
• Domains too large: The teams had to handle too many different tasks, which led to knowledge silos and made knowledge exchange difficult
• Unclear ownership: Responsibilities for components used across teams were often unclear or historically tied to individuals
• Development bottlenecks: These made further team growth necessary

While Pirate Ship was already working with vertically sliced, cross-functional teams, the first team divisions had occurred without in-depth analysis of the domain. This time it was to be different: The goal was not only to integrate ten more developers but above all to create a sustainable team structure. Through a thorough analysis of the domain, teams should be created that can deliver value independently and effectively despite the complex monolith. Limiting teams to a maximum of seven people was intended to enable close collaboration and prevent the emergence of new knowledge silos.

An important context for our approach: Pirate Ship maintains a very participatory culture. The teams work in an agile manner and are responsible for their own work processes. They work with quarterly goals, and besides the teams, there are self-managed working groups for areas such as recruiting, onboarding, and DevOps.

In a world of rapid changes and growing uncertainties, organizations must continuously adapt to remain competitive. But how do you design systems that can evolve and thrive in constant change? The Architecture for Flow approach developed by Susanne Kaiser offers a holistic approach that combines business strategy, software architecture, and team organization.

The strength of Architecture for Flow lies in the combination of these three approaches:

• Wardley Maps help us understand the strategic landscape and identify value chains
• Domain Driven Design helps us translate these value streams into manageable bounded contexts
• Team Topologies gives us the tools to optimally organize teams around these bounded contexts

At Pirate Ship, this combined approach helped us create an adaptive organization that can not only respond quickly and sustainably to changes but also consciously shape its further growth.

Wardley Mapping is a business strategy framework developed by Simon Wardley. At its center is the Wardley Map - a visual representation of an organization's business landscape. This map presents two central dimensions:

• The vertical axis shows the value chain including visibility: At the very top as the anchor of the Wardley Map are the users and their needs, below are all components that contribute to fulfilling these needs
• The horizontal axis shows the evolution stage of the components:
  • Genesis: Completely new, innovative components
  • Custom Built: Specially developed solutions
  • Product: Available products or open-source solutions
  • Commodity: Standardized services

This visualization helps organizations with important strategic decisions: Where do we need to develop ourselves? Where can we use ready-made products? What should we outsource?

Domain-Driven Design (DDD) is more than just a technical approach - it's a collection of concepts and practices that help understand complex business domains and map them in software. Central to this is the close collaboration between domain experts and development teams to develop a common language and understanding.
DDD distinguishes three types of domains:

1. Core Domain: The area that provides the essential competitive advantage. At Pirate Ship, this is, for example, intelligent shipping processing. This domain should be developed internally.
2. Supporting Subdomains: Areas that support the core business but do not offer a direct competitive advantage. For example, the evaluation of shipping statistics. These can be covered by existing solutions or developed internally with less effort.
3. Generic Subdomains: Standard functions that every company needs, such as user authentication. Here, one should usually rely on existing solutions.

Another important concept is Bounded Contexts: They define clear boundaries within which a specific domain model applies. This not only helps with technical structuring, these bounded contexts are also excellent for identifying team boundaries. In practice, this leads to clearer responsibilities and reduced complexity.

A lightweight format for exploring domains and identifying bounded contexts is the EventStorming workshop method. During EventStorming sessions, teams visualize their business processes together by arranging all important business events (Domain Events) on a large board. The method is particularly effective because it brings development teams and domain experts together on an equal footing and, through its visual nature, helps to recognize patterns and natural boundaries in the domain.

Team Topologies is a concept for organizing software development teams, developed by Matthew Skelton and Manuel Pais. The approach aims to enable fast and sustainable value creation by designing teams and their interactions in such a way that they can focus on their core tasks. For this, the framework defines four team types and three interaction modes that together enable an adaptive organization in which teams can deliver value independently of each other.

The four basic team types are:

1. Stream-aligned Teams: These teams are the heart of the organization. They are aligned to a continuous stream of work and end-to-end responsible for specific business functions.
2. Platform Teams: They provide internal platforms as self-service products that can be used by stream-aligned teams. This reduces dependencies and accelerates development.
3. Enabling Teams: These teams act as internal consulting units and help other teams build new capabilities. They are particularly important in phases of change.
4. Complicated-Subsystem Teams: They take care of specialized components that require special expertise.

For these teams to work together effectively, Team Topologies defines three central interaction modes:

• Collaboration: Close, time-limited collaboration, ideal for innovation and exploration
• X-as-a-Service: One team uses the services of another team
• Facilitation: Active support in building new capabilities

With this methodological foundation, we set out to implement it practically at Pirate Ship. The challenge now was to translate these theoretical concepts into a transformation process that considers both the domain complexity and the human aspects of reorganization. How we approached this in practice is described below.

The reorganization at Pirate Ship followed an organic, three-phase process. Instead of a radical restructuring, we pursued an evolutionary approach: The existing teams would serve as seedlings for new teams. This "cell division" allowed us to preserve existing domain knowledge and minimize handover efforts.

The kickoff was a series of workshops facilitated by Susanne on Wardley Mapping, Domain Driven Design, and Team Topologies. These workshops had three central goals:

1. Create a methodological foundation: All teams received training in the three core methods
2. Deepen domain understanding: The teams analyzed their business areas, the business domain, and the software architecture
3. Develop future visions: The teams jointly developed ideas for possible bounded contexts

A core component of this phase were EventStorming sessions. In EventStorming, teams jointly visualize their business processes by arranging all domain events (important business events) on a large wall or digital board. At Pirate Ship, Susanne worked intensively with Miro boards as the workshops were predominantly held remotely.

The result of this phase was not yet a final structure, but rather a kaleidoscope of different perspectives: Each team had identified several options for possible bounded contexts and their grouping. This diversity of views later proved valuable for shaping the final structure.

Two teams started the cell division phase. The baseline was clear:

• The teams had already grown beyond their optimal size
• The workload had reached critical levels
• The product strategy foresaw further growth in these areas

For the cell division workshops, we developed a blueprint that proved to be a very effective basis for the 2-day workshops. One team workshop was completely remote, the other team met on site.

1. Hopes & Fears

• Openly addressing and documenting hopes and fears
• Creates psychological safety for the change process

2. Domain Division

• Presentation of an initial proposal by the founder & CTO – based on the bounded contexts developed in Phase 1 and the patterns emerging from them
• Presentation of the product strategy for the area. This helped to distribute the workload of the identified bounded contexts evenly between two teams.
• Discussion and adjustment of the proposal with consent decision making

3. Skill Mapping

• Definition of the skills needed for the new teams
• Analysis of existing and still needed competencies

4. Clarifying Framework Conditions

• Number of planned new hires, team size requirements
• What expectations does the management and the organisation have for the teams?

5. Self-Selection

• The team members divide according to the self-selection principle. We recorded the decision for the desired team concealed on post-its.
• Check: Does the distribution fit in terms of skills or are adjustments necessary?
• Consent-based decision making

6. Next Steps

• Definition of concrete next steps
• Creation of a rough timeline

An interesting aspect: The two teams chose different timeframes for their cell division. The first team started in the new constellation just a few weeks after the workshop, as new team members had already been found. The second team decided to carry out the division only after onboarding the newly hired colleagues.

After three months, we conducted a cross-team retrospective. This showed that we had successfully addressed many of the original challenges:

The most important improvements:

• The team overload was reduced through smaller, more focused units
• The too large domains were successfully divided, which led to fewer context switches (and thus less cognitive overload)
• The unclear ownership was at least partially replaced by clearly defined responsibilities
• The teams could delve deeper into their respective subject areas

New challenges:

• Technical limitations: The historically grown PHP monolith did not optimally reflect the new domain structure
• Necessary investments: There was an increased need for refactoring work
• Knowledge transfer: The handover of domain knowledge needed more structure than originally assumed
• Shared Components: New coordination needs arose for components used across teams

The last point led directly to Phase 3: Focus on shared components.

A central insight from the cell divisions was the need for clear responsibilities for components used across teams. While we had created clear responsibilities for domain-specific components, there were still ambiguities with the Shared Components.

The Initial Situation

Several components are used by different teams, for example:

• Frontend components
• Database adapters
• Monitoring solutions
• ...

The responsibilities for these components had grown historically and were often tied to individuals. This led to several problems:

• Unclear responsibilities
• Dependencies between teams
• Delays in changes
• Knowledge lies with individual developers

The Path to the Platform Team

With the Platform Teams, we adopted a concept from Team Topologies. Platform Teams have a special role: They provide services to other teams as self-service platforms. This reduces dependencies and accelerates development.

For the conception of the Platform Team, Susanne and I planned another workshop.

Preparation:

• Asynchronous inventory of all shared components
• Collection of current responsibilities
• Open invitation to all interested parties (In the end, almost 20 participants were there)

1. Hopes & Fears

• Expectations and concerns regarding the establishment of a Platform Team

2. Status Quo Analysis

• Mapping of current pain points
• Inventory of shared components
• Identification of dependencies

3. User Needs of the Stream-aligned Teams

• What do the teams need from a platform?
• Which services are critical?
• What requirements exist for self-service components?

4. Team Design

• Development of different team constellations
• Discussion of the options
• Consent-based decision

5. Transition Planning

• How do we get there?
• What questions need to be clarified next (e.g., number of new hires)?

Where necessary, there were brief recaps on User Value, Value Chain & Wardley Mapping in the workshop - the initial workshops of the teams on these topics had already taken place several months earlier.

Results and Next Steps

The workshop led to concrete results:

• Vision for the first iteration of the Platform Team
• Prioritized list of Platform Services
• Rough implementation plan

Particularly valuable was the joint development of the solution: All participants could contribute their perspectives and participate in the design. This created broad acceptance for the new Platform Team.

The actual establishment of the Platform Team is still ongoing at the time of publication of this article. An important aspect: This is not a completed process, but the beginning of a continuous evolution. The Platform Team will evolve based on the needs of the stream-aligned teams and the learnings from practice.

After several years of experience with team reorganizations - both as a team member, tech lead, and as a consultant—several success factors have become particularly evident from my perspective at Pirate Ship:

A fundamental understanding of the domain is the most important factor for a successful reorganization. This may sound self-evident but is often neglected in practice. Often teams are restructured without really penetrating the underlying complexity of the domain. With complex products and architectures that have grown over years, this approach takes revenge: Teams remain bound to each other through dependencies and cannot deliver value independently of each other.

A decisive success factor at Pirate Ship was the continuous support from the leadership team. The German founders and managing directors not only initiated the process but actively supported it:

• They provided the necessary resources and time for workshops and reorganization
• They set clear framework conditions but allowed the teams freedom for self-organization within these boundaries
• They were present and approachable at critical workshops without dominating the participatory process

This balance between strategic orientation and trust was evident in three central guidelines:

• Team Topologies as guiding framework: The decision to align the organization according to the principles of Team Topologies with stream-aligned teams and platform teams
• Maximum team size: Teams should not be larger than seven people to enable effective collaboration
• Recruiting: Team formation took place through self-selection, while the management set the framework for new hires

An important learning for future reorganizations: The timeframe for implementation should be defined more clearly from the beginning. At Pirate Ship, the teams could decide for themselves when to divide, which allowed flexibility on the one hand but also led to uncertainties in the overall process on the other.

Investing in a participatory process takes time—time that pays off in multiple ways:

• Better solutions: Involving different perspectives makes it possible to capture the complex domain in its entire depth. Teams contribute their specific knowledge - from technical details to business processes - which leads to more well-founded structures that do justice to the actual complexity
• Higher acceptance: When teams co-design the new structure, they actively support the change
• Sustainable change: The jointly developed understanding forms a solid basis for future adjustments

To ensure that participation does not lead to paralysis, several practices have proven successful at Pirate Ship:

• Consent instead of consensus: While consensus means that everyone must actively agree, with the consent principle, it is sufficient that no one has a serious objection. This accelerates decisions without neglecting participation. A serious objection means that the person can justify why the decision would harm the team or the organization.
• Clear framework conditions: Early clarification of boundaries and possibilities with the leadership
• Prepared decision templates: They serve as a discussion basis and accelerate the process.

The continuous work with visual models — be it in Miro boards or other formats — has proven indispensable:

• It makes complex relationships tangible.
• It creates a common language.
• It documents decisions and their foundations.
• It serves as a basis for further discussions and adjustments.

The concept of cell division has proven itself as an evolutionary approach to team reorganization and division in our case. Instead of a radical upheaval, this organic process allows existing domain knowledge to be preserved within the teams and passed on. The gradual division also significantly reduces the effort for knowledge transfer and handovers, as not all know-how has to be redistributed at once. This evolutionary path allows organizations — if this fits the speed of growth — to grow at a healthy pace. The teams can transform evolutionarily, and the company can cautiously expand its capacities while preserving its technical expertise.

A central insight from the process at Pirate Ship: With each step, change becomes easier. The first team division was particularly challenging — especially for the "original crew." For a company in the pioneering phase, the realization that not everyone can work in one team anymore represents an important development step. It's the farewell to the startup phase, where everyone does everything and structures are rather informal.

But with each further division, trust in one's own ability to change grows. The organization learns from its experiences, develops routines, and gains confidence. What initially seems tough and difficult increasingly becomes a natural process of further development. Meanwhile, one team has even initiated another cell division process on its own.

The experiences at Pirate Ship show: Reorganization is not a one-time project with a defined end, but a continuous process. Teams and organizations are constantly evolving — be it through new product requirements, technological changes, or personnel growth.

Architecture for Flow has offered us a valuable framework that can be flexibly adapted to different situations. Especially the combination of methodological foundation through Wardley Mapping, DDD, and Team Topologies on the one hand and real participation on the other has proven itself. It makes it possible to approach even complex changes step by step.

At Pirate Ship, it also becomes clear what happens when the teams themselves take initiative: They suggest adjustments and actively shape their work areas. This confirms Peter Senge's insight: "People don't resist change, they resist being changed." When teams have the opportunity to co-design change, this opens up space for sustainable solutions and organizational learning.

Articles & Books
Brandolini, Alberto: Introducing EventStorming, 2021.
Evans, Eric: Domain-Driven Design: Tackling Complexity in the Heart of Software, 2023.
Kaiser, Susanne: Adaptive, Socio-Technical Systems with Architecture for Flow: Wardley Maps, DDD, and Team Topologies, https://www.infoq.com/articles/adaptive-socio-technical-systems-flow/, 2023.
Pais, Manuel and Skelton, Matthew: Team Topologies. Organizing Business and Technology Teams for Fast Flow, 2019.
Vernon, Vaughn, Domain-Driven Design Distilled, 2016.

Websites & Online Resources
Learn Wardley Mapping, https://learnwardleymapping.com
EventStorming, https://www.eventstorming.com/
Domain-Driven Design Starter Modelling Process, https://github.com/ddd-crew/ddd-starter-modelling-process