ORG TOPOLOGIES 

Context of my engagement as a coach At the beginning of 2024, the main project of InternetCo was experiencing a convergence of organisational and delivery-related challenges that significantly constrained its effectiveness. From a delivery perspective, the team struggled with unstable velocity, limited predictability, and recurring misalignment between technical solutions and evolving business requirements. This misalignment was exacerbated by insufficient transparency around timelines and dependencies, making it difficult for both stakeholders and teams to develop a shared understanding of progress and expectations. At the beginning of my engagement in 2025, I had an assumption that beneath these surface-level symptoms, there were way deeper systemic issues. More specifically, I hypothesized that the challenges observed were not primarily caused by individual performance or execution discipline, but by an organizational design that constrained how work was defined, how decisions were made, and how skills were allowed to develop. From an organisational topologies perspective, I suspected a misalignment between the Scope of Work Mandate and the Scope of Skills Mandate, resulting in teams optimising for activity and utilization rather than for end-to-end outcomes and learning. This hypothesis shaped my choice to explore the system before proposing any delivery or framework-level changes. I observed the following: Processes were either unclear or inconsistently applied, which led to frequent handoff friction and communication gaps across roles and teams. Team members reported a diminishing sense of achievement, as work often felt reactive rather than purposeful, and successes were rarely made visible or celebrated. At the same time, opportunities for professional growth and career development were limited, contributing to reduced engagement and long-term motivation. Compounding these challenges were persistent prioritization problems and an ever-expanding backlog. Work was frequently initiated without sufficient alignment on value or urgency, resulting in context switching and unfinished initiatives. Technical debt, particularly within operational domains, continued to accumulate further slowing delivery and increasing cognitive load for both development and operations teams. Together, these factors created reinforcing bottlenecks that affected not only throughput but also morale and trust in the system. I learned that throughout 2024, these challenges were addressed through a series of deliberate, collaborative interventions aimed at stabilizing the system and creating conditions for sustainable improvement. The approach I took A key focus set as my priority was the development and implementation of a clearer, more explicit workflow for the development team. However, I decided to take a bigger picture approach and see if the elements of the system were aware of the current organization and the results it brings. Introducing or scaling a delivery framework such as Scrum, LeSS, or any other agile method without first understanding the underlying organizational design would have risked local optimization. Without addressing how work was defined, who had authority to make decisions, and how skills were expected to evolve; any framework adoption would likely reinforce existing constraints rather than resolve them. Therefore, organisational design awareness was treated as a prerequisite for any sustainable delivery improvement, not as a consequence of it. From a transformational perspective, my work was grounded in a structured approach to data collection and analysis, aimed at understanding how the system actually functioned — not only how it was described—so that leaders could design strategically rather than optimize locally. The process began with reviewing relevant organizational documents and artifacts. While I am aware that formal documentation rarely reflects lived reality, in this case, it served two important purposes. First, InternetCo historically took pride in its extensive documentation practices and standard operating procedures; reviewing these artefacts was therefore a way to acknowledge the organization's identity and respect its historical investments. Second, documents provided insight into the declared governance model: how authority, responsibilities, and workflows were formally designed. These artifacts were treated not as reliable representations of behavior, but as expressions of intent and structural assumptions. The gaps between documented processes and actual practice later became diagnostically useful. This document review was followed by structured interviews and surveys with executives, employees, and cross-functional teams, allowing multiple lived perspectives on the system to emerge and enabling comparison between formal design and operational reality. In the surveys and interviews, my key questions were aimed at: 1) Understanding the need behind optimization (basically, what are we optimizing for, but not asked bluntly). Examples of questions were: What gets celebrated, promoted, or rewarded? When trade-offs arise, what usually wins: speed, utilization, predictability, or impact? Where do we still deliver activity instead of customer-relevant outcomes? Which work feels “done” but creates little real value to users or to the business? 2) Understanding the Scope of Work Mandate: Who decides what work gets done? And what source of inflow to backlog exists? What problems are teams not allowed to solve? Where do handoffs occur because “this is not our responsibility”? What work requires coordination across many units to complete? 3) Understanding the Scope of Skills Mandate: What skills are people expected to develop over time? Where do specialists wait for other specialists to act? How easy is it to learn adjacent skills while doing real work? Workshops part 1 The primary intention of the workshop series was not to design a future organization immediately but to create a shared understanding of the current one. By involving cross-team representatives in mapping the system, the goal was to enable collective sense-making, surface implicit assumptions, and ensure that any transformation backlog would be perceived as emerging from the system itself rather than being imposed externally. The first workshop was adapted from the Estuarine Mapping tool from Cynefin to see the system they operate in and visualize the organizational landscape. (Practically this is Butterfly Stamping, a prelude to Estuarine Mapping) with attributes and objects from the organization. Pictures A and B show the current state. current state current state Pictures C and D show the desired state. Desired state desired state The middle zone of Estuarine Mapping has been selected as things that can be changed and are worth changing. Estuarine Mapping The Estuarine Mapping workshop revealed structural tensions between declared intent and enacted behavior. Participants identified multiple forces shaping the current state: strong functional identity, historical investment in specialization, centralized prioritization, and implicit incentives favoring utilization over end-to-end ownership. I observed several key results: 1. Many elements placed in the “stable” zone were functional departments and expertise pools, indicating structural inertia around skill-based grouping. 2. Units positioned in the “changeable” middle zone often related to coordination mechanisms (backlog structure, ownership clarity, sequencing practices), suggesting that the organization experienced friction primarily at interfaces rather than within functions. 3. Desired-state mapping consistently moved elements toward clearer product-level ownership and reduced cross-functional dependencies, signaling collective recognition that mandate fragmentation and not lack of competence was constraining flow. Workshops part 2 The second part of the workshop was dedicated to mapping the current organizational design. I used a two-phase approach. In the first phase of the workshop, the intention was to examine how the organization distributed and exercised the four core organizational functions described in Org Topologies: Directing, Doing, Delivering, and Driving. Rather than treating these as abstract categories, we used them as diagnostic lenses to understand how mandate and authority were actually distributed. Delivering Intelligence Where is the flow smooth, and where does work pile up? What slows work down more: lack of skill or lack of coordination? Driving Intelligence Who understands customer impact end-to-end? Where are product decisions disconnected from delivery reality? Directing Intelligence Who can explain why this org is designed this way? How often is strategy revisited based on learning, not planning? Adaptive Intelligence How easy is it to change direction once work is underway? These conversations allowed participants to observe whether the organisation behaved closer to a Resource topology (strong Doing, centralised Directing), a Delivery topology (stable Delivering units), or an Adaptive topology (distributed Directing and expanded Scope of Work Mandate). Do people primarily move between initiatives, or does work move to stable groups? Are teams formed around skills, around delivery goals, or around evolving problem spaces? Where does coordination happen: managers, meetings, or shared artifacts? In the next stage of the workshop (afternoon), we were focused on mapping the current state of affairs, following the principle of Complete/Incomplete and Output/Outcome focused. Study boundary: whole organization High-level view Note: I also used this visualization to explain the why behind mapping the current design before starting any transformation; hence, both OrgTopologies and my approach were framework-agnostic, but focused on the design and how people interact. Detailed view The collected data were then synthesised to identify recurring patterns, systemic tensions, and opportunities for improvement. The conclusion, as referenced in the Primer, suggests that: “Grouping individuals into functional units results in a more reliable system of staged development across functional silos. In this paradigm, we group the individuals of a similar skill, creating functional departments or functional groups. Although we didn’t break the functional silos yet, these departments are better at balancing workload than single individuals. Here, the hand-offs and information scatter create an increased coordination need, resulting in a slow product development system.” The organization predominantly operated in a Resource topology. Individuals and teams were grouped by function and specialization, and work flowed across those units through sequential handoffs. Scope of Skills Mandate was deep but narrow: specialists optimized within their domain (e.g., backend, operations, infrastructure), with limited horizontal capability overlap. Scope of Work Mandate remained constrained to partial solutions; most units delivered components, services, or expertise rather than complete, customer-relevant outcomes. Directing authority was centralized, with prioritization and sequencing decisions occurring outside of delivery units. Delivering relied heavily on cross-functional coordination rather than stable end-to-end accountability. As a result, flow depended on negotiation between functions, and ownership of outcomes was diluted across multiple roles. Coordination cost, dependency management, and escalation patterns were structural features rather than exceptions. These characteristics align with Resource topology patterns described in the Org Topologies Primer: optimization around resource utilization, functional workload balancing, and governance-driven sequencing, rather than outcome-centered, stable delivery units. The desired state of transformation looked like this: desired state A potential early result, as stated in the Primer, would be: “In comparison to managing tasks, working with features at the second level makes managing product development easier. Each work unit at this level is likely to have an independent set of goals, a roadmap, and a backlog at the feature level. This setup creates clear responsibility for whose those features are.” Next steps and transformation backlog Combined results have been digested into a set of recommendations and short-term and long-term goals, together with the implementation of Elevating Katas. Some recommendations included: Improve the vision and goals with 1) Creation and communication of annual objectives and/or quarterly key results with Vision and Roadmap 2) Map out dependencies and allocate resources Quarterly planning together Insights and transparency on status 3) Use prioritisation techniques 4) Introduce the feature owner as a role responsible for why-what-how alignment. 5) Set up a Kanban board to visualize work and encourage collaboration for all teams. 6) Establish stand-up meetings to increase alignment and help address bottlenecks. 7) Integrate retrospectives to encourage a culture of continuous improvement and develop innovative solutions. 8) Choose and implement agile delivery workflow (scrum, scrum at scale, less, etc.) 9) Set up knowledge sharing and technical COPs so that leaders are not centralizing knowledge and creating a bus factor. Short-term goals: Reorganize the operations team into a Kanban workflow Clarify roles and responsibilities Establish a regular feedback loop Set up refinement practices and coach the team in agile principles Develop a prioritization and estimation method Set up and configure task tracking and planning tools Long-term strategies: Formalize an approach to project management and document key processes Implement a quarterly planning cycle (set OKRs). Regularly review and prioritize the project backlog Break the organizational silos through team coaching Reach effective collaboration through team and leadership coaching Create end-to-end fast flow teams Ensure the whole organization's business focus According to the Primer, Elevating Katas exist to systematically push the organization toward the upper-right of the Org Topologies map, higher Scope of Work Mandate, and Scope of Skills Mandate without breaking the system. Each kata targets one or more org design elements simultaneously: Structure (how work is grouped) Governance (who decides what) Roles (what authority people really have) Events (how coordination happens)Artifacts (what makes work visible) The selected Elevating Katas were chosen to incrementally expand both the Scope of Work Mandate and the Scope of Skills Mandate without destabilising the system. For example, elevating Product Ownership and introducing feature-level responsibility, targeted governance, and role clarity, enabling clearer alignment between why, what, and how. Merging product backlogs and establishing multi-team backlog refinement addressed structural fragmentation and reduced coordination overhead. Introducing shared definitions of “Done” and visual flow artefacts increased transparency and supported outcome-oriented conversations. Each kata was designed as a learning mechanism rather than a fixed solution, allowing the organisation to adapt based on feedback rather than enforcing a predefined end state. elevating kata mapping The timeline for short-term goals has been selected as Q1 2026 and long-term as Q4 2026. Some short-term results as of Jan 5, 2026: Stable agile cadence embedded across teams (scrum for dev teams and reorganized operations team into Kanban workflow) Business–IT dialogue significantly improved Delivery transparency on incidents and releases increased Openness to training and structured learning strengthened Clarified roles and responsibilities Established a regular feedback loop Elevated Product Ownership and trained POs Set up refinement practices and coach the team in agile principles Developed a prioritization and estimation method Set up and configure task tracking and planning tools Started holding Multi-Team Product Backlog Refinement (PBR) Merged Product Backlogs for 3 directions Defined shared “Done. These outcomes indicate that team-level agility was successfully established and is no longer theoretical. However, as predicted by Org Topologies, improvements in rituals surfaced deeper systemic constraints. Five systemic challenges became clearer: Fragmented end-to-end ownership (handoffs still slow flow) Weak systemic follow-through (structural problems reappear) Vision insufficiently translated into daily work Underinvestment in technical foundations (CI/CD, infrastructure) Incentives misaligned with outcome ownership and growth These tensions are consistent with an organization transitioning from Resource toward Delivery topology: improved Doing and Delivering expose constraints in Directing and Driving. Importantly, the visibility of these constraints was interpreted as progress rather than failure. In a Resource topology, structural issues remain obscured by functional buffering. In transition, they become explicit and therefore actionable. The next phase of transformation was designed as a deliberate shift from team-level agility toward organizational agility, meaning expansion of mandate, structural alignment, and governance clarity. Rather than introducing additional rituals, the focus of 2026 was structured around three evolutionary horizons: Horizon 1 (Months 0–3) Actions together with Elevating Katas in this horizon target structural bottlenecks: Establish a weekly organizational impediment forum to surface cross-team constraints so that it is possible make structural blockers visible and assign executive ownership Create a temporary DevOps enablement squad to unblock flow Elevate CI/CD stabilization to a top organizational priority Support cross-team alignment without hierarchy (and Lead with OBEYA strategically). Horizon 2 (Months 4–6) Define and publish initiative charters with explicit product outcome ownership Ensure strategic alignment and adaptability (and Expand the “Product” Definition) Clarify WHAT (business intent) versus HOW (implementation decisions) Expand Scope of Work Mandate from task execution to feature-level accountability Horizon 3 (Months 7–12): Institutionalize Capability and Ownership The final horizon focuses on embedding sustainability rather than introducing new mechanics. Key Actions: Launch Communities of Practice to expand horizontal skill mandate Introduce Individual Development Plans aligned with evolving topology Integrate HR into transformation governance Protect 5% innovation capacity to enable adaptive experimentation Conclusion By deliberately slowing down at the beginning of the engagement and focusing on understanding how the organization actually functioned, rather than how it was described, I was able to surface the implicit rules, incentives, and constraints that governed behavior. I am glad I got to combine OrgTopologies with Cynefin tools so I could reach more participants and get multi-dimensional perspectives. The combination of document review, interviews, surveys, and participatory workshops created a shared mirror for the organization, allowing leaders and teams to see not only what was happening but also why the system was producing the results it was producing. This shared understanding proved to be a critical prerequisite for change. More precisely, the organization operated predominantly in a functional (resource-oriented) topology , characterized by a limited Scope of Work Mandate and a specialized, function-bound Scope of Skills Mandate. Individuals and teams were grouped primarily by skill and function, while work flowed across those units through handoffs and coordination mechanisms. While this topology provided a sense of workload balancing and role clarity, it also increased coordination cost, slowed feedback loops, and diluted ownership of customer-relevant outcomes. Scope of Work Mandate was limited to partial solutions; most units contributed components rather than complete customer-relevant outcomes. The intended shift toward a Delivery topology did not imply abandoning functional expertise, but reorganizing work around stable, end-to-end accountable units. In a Delivery topology, Scope of Work Mandate expands from partial contribution to complete solution ownership, while Scope of Skills Mandate expands horizontally — enabling multi-skilled collaboration within stable groups. Importantly, the organization did not need a radical or disruptive redesign (their initial scope was only focused on the delivery framework, and they would be satisfied with “just” setting up scrum teams); instead, it needed a series of intentional, safe-to-try shifts that would gradually redesign the organization while not being tied by any framework they thought they needed at the moment. The selected recommendations and Elevating Katas were therefore not treated as a transformation “plan,” but as mechanisms for learning. The early results achieved by January 2026 demonstrate that meaningful progress can be made without destabilizing the system, provided that organizational change is grounded in transparency, participation, and respect for existing constraints. Beyond the visible structural changes, the most significant outcome of this engagement was a shift in how the organization reasons about problems. Leaders and teams began to distinguish between delivery issues and design constraints and to approach improvement as an ongoing learning process rather than a one-time reorganization. For me as a coach, this case reinforced the value of organizational topologies not as a prescriptive framework, but as a sense-making discipline that enables deliberate, context-sensitive change. Rather than asking “Which framework should we implement?”, the organization learned to ask, “What kind of system do we need to become to achieve the outcomes we care about?”

Background This case study documents an ongoing organizational design journey within the IT department of one of Europe’s largest and most complex technology companies—a global high-tech systems manufacturer operating at the frontier of precision engineering and software development. The IT organization is structured around the Scaled Agile Framework (SAFe), with Agile Release Trains (ARTs) organized primarily around business capabilities—planning, Procurement, Materials Management and so on—rather than around value streams or end-to-end solutions. This blueprint, common in large enterprises, creates capable delivery engines for their respective domains but also embeds structural patterns that make speed, autonomy, and genuine business-IT integration difficult to achieve at scale. The focus of this case study is one particular ART working in the planning domain. It currently consists of three distinct units: One development team is responsible for a separate, standalone product—not directly related to the platform described in this case study and not part of the Paradigm initiative. Two DevOps teams are maintaining and operating the current planning platform, which is approaching end-of-life. Their primary mandate is operational continuity, not feature development. Into this context arrives Paradigm —a next-generation planning solution that will eventually replace the current platform. Paradigm is not simply a technology refresh. It is, as we will explore, an opportunity to redesign the organizational structure around it from the ground up—before the patterns of the existing organizational structure extend to Paradigm. I came into this engagement as an Org Design Consultant, initially coaching the project lead before the scope broadened into participatory design workshops with business and IT leadership. My aim throughout has been to bring the language and tools of Org Topologies to a group of leaders who are genuinely motivated to do things differently—and to help them make that ambition concrete and shared. Design Timeline The design process is structured across four stages, moving from assessment through to implementation: R0 involved the initial mapping and assessment workshops—bringing together the Release Train Engineer, Chief Product Owner, IT group leads, Head of Product, and senior business representatives, placing their teams on the Org Topologies map, and naming the gap between where they are and where they want to be. The candor in those sessions was striking. Business leaders acknowledged the distance between themselves and the teams building for them. IT leaders acknowledged the narrowness of the work mandate their developers were operating under. That shared diagnosis became the foundation everything else is built on. A Brief Introduction to Org Topologies To make sense of the maps that follow, a short primer on the Org Topologies framework is useful. Org Topologies provides a visual language for describing and designing organizational structures—not in terms of job titles or org charts, but in terms of mandates: what a team is empowered to work on, and how broad or narrow that mandate is across two distinct dimensions. Horizontal axis—Scope of Skills Mandate How broad is the range of skills within an organizational unit? Units to the left are functional—single-skill and highly dependent on other teams to deliver. Units to the right are end-to-end capable—they hold all the skills necessary to deliver value without asynchronous handoffs to others. Vertical axis—Scope of Work Mandate How close is the unit to the customer and the full solution? Units at the bottom are task-focused—they receive discrete tasks to execute. Units at the top operate at a whole-solution or unbounded scope—they can respond to business and customer problems directly, end-to-end. The intersection produces sixteen recognizable archetypes, grouped into four families: Doing Archetypes (lower-left, high dependency), Delivering Archetypes (lower-right, technically strong but narrow work scope), Directing Archetypes (upper-left, broad scope but incomplete skills), and Driving Archetypes (upper-right, the ideal: complete skills, broad mandate). “The map reveals not just where you are, but the distance — and the nature of the effort — required to get where you want to be.” Most large enterprise IT organizations cluster in the lower half of the map—a natural consequence of scale and specialization pulling toward functional boundaries and narrow mandates. The value of the map lies in making the direction of travel legible and surfacing the specific interventions needed at each step of the journey. Mapping the Current State The R0 mapping workshop placed the Paradigm-related units on the Org Topologies map for the first time. The result was a clear and somewhat sobering picture of how fragmented the current structure is—five distinct units spread vertically across the map, with limited horizontal integration between them. Map + Assess—Five units placed across the OT map, from Business Owner down to DEVs Reading the map from top to bottom: Business Owner —positioned at the WHOLE-1/WHOLE-2 boundary (where “whole” refers to the complete Paradigm solution scope within the larger enterprise context): whole-solution scope, operating as a Directing Archetype. Close to business strategy, but separated from the delivery layers below by several organizational tiers. Central Solution Team (Architects and Business)—at WHOLE-2 / PART-2: multi-skill, combining IT architecture and business understanding. A directing layer providing strategic coherence, but not yet a delivery unit in its own right. Functional Workstream —at PART-2: multi-skill , partial solution scope. Functional and domain experts are beginning to coalesce around Paradigm, building toward end-to-end delivery capability. Expert Consultants and BPAs —at CAPS-2: multi-skill, capabilities-focused. External Paradigm platform expertise and business process analysts delivering capabilities within a narrower work mandate, with solution outcome accountability set to grow as the design evolves. DEVs —at TASKS-2: multi-skill, task-focused. Technically capable developers operating with the narrowest work mandate on the map, working from discrete tasks and at a distance from business context and solution ownership—the core constraint the design is built to resolve. The stack is tall and the layers are distinct. Business and IT operate in parallel streams with limited integration at the delivery level. The DEV team sits at the very bottom—capable, but disconnected from context, customer, and solution ownership. Feedback loops are long; decisions travel upward before they travel back down. This pattern is consistent with the wider ART landscape in this organization. What makes the Paradigm initiative distinctive is the explicit intention—backed by management on both sides—to design the team structure deliberately from the outset, building on a shared diagnosis of what needs to change. The Paradigm Opportunity The arrival of Paradigm in this ART is more than a platform replacement. It is, in organizational design terms, a greenfield moment: an opportunity to build the team structure around a new solution before the constraints of legacy working patterns, reporting lines, and coordination habits have time to calcify. Business leadership has been through design workshops to understand the need for bridging the gap between business and IT. Leadership across both functions is on board to elevate the design. The Org Design Consultant has worked closely with the project lead to develop the shared language and direction that now underpins the initiative. This groundwork—the investment in shared diagnosis before shared design—is not accidental. It is the first Elevating Kata of the journey. The design ambition for the Paradigm teams goes further than anything currently in place elsewhere in the ART landscape of this organization. Where other ARTs have worked to integrate competences on the IT side, the Paradigm design targets something more fundamental: bringing business stakeholders directly into multidisciplinary delivery teams, alongside developers, architects, and platform engineers. This challenges several of the organization's deep structural norms: Reporting lines—Business staff joining delivery teams typically still report into functional business management. Formal agreements around time allocation, accountability, and career development within a non-traditional team structure must be made explicit. Role identity—Business Process Analysts and functional workstream leads are accustomed to being consulted. Becoming a team member—sharing a sprint, contributing to a Definition of Done, co-owning a solution outcome—is a different orientation entirely. Feedback loops—When business and IT share a team, the distance between a discovered insight and a delivered solution collapses dramatically. Achieving this is the central prize of the design; it also requires new habits, new trust, and new working ceremonies. Compliance and security—This organization operates in a regulated, high-security environment. Any team design must respect non-negotiable requirements around data governance, audit trails, and system access—constraints a good design accommodates, not obstacles it ignores. The optimizing goals for the Paradigm design were surfaced explicitly in the workshops: The design is also explicitly inspired by federated development — the idea that a loosely coupled network of empowered, semi-autonomous teams, held together by shared goals and standards rather than centralised control, can outperform a tightly coupled hierarchy in a complex environment. A critical enabling condition: management alignment One of the most significant features of this initiative is the breadth of leadership support it has secured. Multiple management layers on both the business and IT sides are actively engaged and aligned on the direction of travel. This is not a bottom-up experiment running under the radar; it has genuine organizational permission. In my experience as a design consultant, this kind of top-down enabling is frequently what determines whether a design reaches implementation. The workshops run to date have been important not just for their outputs, but for the alignment they have built. Business and IT leaders have sat in the same room, placed themselves on the same map, and agreed—sometimes for the first time explicitly—that the current structure is not the structure they want. The Intermediate Design: R2 Organizational redesign rarely succeeds as a single leap. The distance between a TASKS-2 development team and a PART-3 end-to-end, partial-solution team is real—measured not just in the structure on paper, but in the habits, trust, skills, and governance that need to develop along the way. The R2 design is a deliberate intermediate stage: ambitious enough to represent genuine progress, grounded enough not to require everything to change at once. R2 is targeted for Q3–Q4 2026. By that point, the R1 design work—currently underway—will have established the organizational structure needed to deliver Paradigm. R2 then represents the first stable operating configuration: the moment when the new structure begins to be lived, not just planned. Design—Three emergent Partial Solution teams forming, with DEVs continuing their upward journey The R2 map shows several significant movements from the current state: Three emergent partial solution teams begin to form—each focused on a distinct planning domain. These teams are positioned between CAPS-2 and CAPS-3, building end-to-end capability and progressing toward the PART-3 archetype as their skills broaden and their work mandate expands. Critically, each team begins to include both business and IT members. The DEV team continues moving rightward—from TASKS-2 toward TASKS-3, as developers broaden their technical and contextual skills and begin working against goals rather than tasks. They are moving toward full integration into the partial-solution teams as their mandate and skills grow. The Central Solution Team remains at WHOLE-2—continuing to provide architectural direction and strategic alignment, but with the gap between it and the delivery layer beginning to narrow as teams grow in capability. Three practical levers drive the movement from R0 to R2: Lever 1 — Skills Broadening Developers are supported in building understanding of the business processes their work serves. Business analysts and functional workstream members begin participating in sprint ceremonies and technical discussions. The goal is informed versatility—enough shared understanding between IT and business that the team can work as a whole rather than as adjacent specialists. Lever 2 — Work Mandate Expansion Teams shift from receiving capability specifications to receiving partial solution goals. Teams are given a slice of the solution space and trusted to determine the best path to an outcome. Product Ownership evolves accordingly: less tasking, more goal-setting. Lever 3 — Dependency Resolving Explicit attention is paid to the handoffs currently flowing between separate Paradigm sub-teams. Where a dependency can be internalized—through skill transfer, co-location, or team merging—it is. Each dependency removed shortens the cycle from requirement to delivery and reduces the coordination overhead carried by management. The R2 state is designed to be stable enough to operate in through 2026 and into early 2027, while the organizational capability required for the optimal design continues to develop. The R2 stage gives teams the time and space to build the habits, trust, and governance the optimal design will require—a deliberate investment in organizational readiness. The Optimal Design: A Team-of-Teams at PART-3 The optimal design is the most progressive configuration under consideration and the one that most directly challenges the prevailing organizational blueprint. Reaching this state is not guaranteed—it requires sustained commitment, deliberate investment, and continued management alignment across both business and IT. But it is the clearest articulation of what the Paradigm teams are designed to become. Design (optimal) — Three Partial Solution teams consolidated at PART-3, Business Owner at WHOLE-2 The optimal map shows a striking consolidation around the PART-3 archetype: Three Partial Solution teams at PART-3 —end-to-end skilled, partial-solution mandated, and—the defining structural feature—containing both business and IT members. Each team owns a partial solution within the Paradigm planning domain. Each partial solution represents a distinct value stream end-to-end—business and IT together, working toward shared outcomes. Business Owner and Central Solution Team remain at WHOLE-2 —providing strategic direction and architectural coherence. In the optimal design these roles become fully enabling: setting direction, holding the strategic picture, and creating the conditions for teams to thrive. The DEV team is fully absorbed—developers who have grown in mandate and skills are embedded within the three partial-solution teams. Developers are fully integrated into the partial-solution teams, contributing as end-to-end members with expanded mandates and skills. “When business and IT share a team with a genuine partial-solution mandate, the distinction between ‘IT delivering for the business’ and ‘the business building its own capability’ begins to dissolve.” In the optimal design, the dynamics between teams change qualitatively. At the CAPS and TASKS level, coordination is typically imposed from outside—a manager or RTE facilitates alignment because the teams themselves lack the scope to self-organize. At PART-3, with genuine partial-solution ownership, teams begin to coordinate themselves—around the solution, the user, and the outcome. This is the Team-of-Teams dynamic: instead of coordinating teams from above, you coordinate the topology of teams. Operations: Embedded from the Start One area given deliberate early resolution in this design is the role of operations. The intention is to include Ops capability within the Paradigm teams from the earliest lifecycle stages as an integral part of each delivery team from the outset. Why embedded Ops matters Embedding operational expertise inside the partial-solution teams serves two goals simultaneously. First, it closes the feedback loop between production behavior and development decisions—operational insights inform the backlog directly, without translation through an external team. Second, it ensures that quality support is designed in rather than added after the fact. A team that owns and runs a building has fundamentally different incentives to one that only builds. In Org Topologies terms, including Ops within the PART-3 teams reinforces their end-to-end skills mandate and prevents the re-emergence of a new dependency at the bottom of the stack—exactly the pattern the overall design is working to eliminate. Why this design is progressive in this context Most ARTs in this organization operate at CAPS-2 or below on the work mandate axis, with IT-only team composition. The optimal Paradigm design targets PART-3 with mixed business/IT/Ops teams. This is a qualitatively different model of how enterprise IT relates to the business it serves—treating the Paradigm planning capability as a jointly owned, jointly operated product, built and run by the people closest to it on both sides of the traditional divide. Elevating Katas for the Paradigm Journey Elevating Katas are structured, repeatable routines that turn organizational design intent into lived behavior. Rather than one-off transformations, they create safe, deliberate ways to reshape structure, mandates, and ways of working while learning from real work. The Paradigm initiative applies several Elevating Katas from the official Katalog , organized by the dimension of organizational design they address. Katas Currently Applied Strategy Dimension: Adopting Strategic, Outcome-Based Backlog Teams currently work from team-level backlogs derived from the ART program board. The intention is to transition toward outcome-oriented goal-setting, where teams work toward measurable solution outcomes—adoption rates, process cycle times, error reduction—rather than lists of features or tasks. Re-Centering Product Ownership on Strategy and Outcomes Evolving the Product Owner role to focus outward on stakeholder engagement and outcome framing, while teams take increasing ownership of tactical delivery decisions within their partial-solution mandate. Structure Dimension: Expanding Units Toward End-to-End Outcome Ownership Deliberately broadening both the skills mandate and work mandate of teams—moving from narrow, task-focused units toward PART-3 teams that own partial solutions within the planning domain. This includes embedding business staff directly into delivery teams with formal agreements on time allocation, accountability, and career development. Forming a Team-of-Teams Building the three partial-solution teams as a coordinated Team-of-Teams structure. Rather than coordinating teams from above, teams coordinate themselves around the shared planning solution space, with leadership providing strategic direction and removing obstacles. Processes Dimension: Expanding and Sharing the Definition of Done Across Teams Including operational readiness and production ownership in the Definition of Done from the earliest stages. Ops expertise is embedded in teams so that quality, monitoring, and support concerns shape decisions from day one. Holding Multi-Team Product Backlog Refinement Establishing regular refinement sessions where the three partial-solution teams align their understanding of upcoming work, surface dependencies early, and coordinate around the shared planning domain. People Dimension: Using Synchronous Teamwork to Expand Capability and Ownership Supporting developers to build understanding of business processes through participation in sprint ceremonies, backlog refinement, and stakeholder conversations. Business analysts gain technical context through pairing and mob sessions. The goal is reducing hard boundaries between IT and business understanding within shared teams. Potential Future Katas As the Paradigm teams mature and the design stabilizes, additional Elevating Katas could be introduced to deepen the transformation: Merging Product Backlogs : If multiple product backlogs currently exist across the planning domain, merging them into a single shared backlog would reduce competing priorities and ensure all teams work from the same strategic view. Designing Tailwind Career Paths : Creating career progression models that reward breadth and multi-skill growth while adhering to the larger organizational design framework. While functional job families remain fixed within the enterprise structure, roles within teams can be more flexible, enabling multi-skilling and versatility that supports the teams’ end-to-end mandate. Holding Product-Level Reviews : Moving beyond team-level sprint reviews to product-level demonstrations where all three partial-solution teams showcase integrated progress. With business embedded in the teams, these reviews naturally attract important stakeholders and clients, creating direct feedback loops with the people who use the planning solutions. The selection and sequencing of Elevating Katas should be driven by the actual constraints the teams encounter in their work. The katas listed above represent a starting point; the real power comes from iterating on them as the organization learns what works in its specific context. Open Questions The design process has surfaced a set of important decisions that deserve deliberate attention as the journey progresses. Each one represents a genuine choice point—where the answer will shape the team structure, the governance, and the pace of change. How much work lies ahead? The gap between the current TASKS-2/CAPS-2 state and the PART-3 target is real. A detailed change roadmap—with milestones, owners, and review checkpoints beyond the high-level stage gates—is the next planning task. Is this sustainable mid/long-term? Mixed business/IT teams with partial-solution mandates are genuinely new in this organization. What governance protects their composition under workload pressure? How do career paths work for business staff embedded in delivery teams over years, not months? How to embed in ART / SAFe? PART-3 teams operating within a SAFe ART need a clear model for PI Planning, backlog ownership, and dependency management. The standard SAFe playbook was designed for lower-mandate teams—adapting it and deciding who decides how needs explicit resolution. How stable will the teams be? Business staff in delivery teams are particularly vulnerable to reallocation under pressure. What structural agreements—and what management commitment—protect the organizational structure once it is established? What is Paradigm’s lifecycle and roadmap? The current platform is at end-of-life, with decommissioning planned as Paradigm matures. The transition timeline—from today’s operational continuity work through Paradigm maturity and legacy retirement—shapes the urgency and sequencing of every design decision. How does this design scale if Paradigm grows? A 50–100 person organization operating as three partial-solution teams is manageable. What happens when the solution expands or new domains are added? Building in the design principles for scaling—without defaulting back to the capability-ART structure—is worth naming now. Conclusion The Paradigm initiative sits at a rare intersection: a new solution, a deliberate design process, and an unusually aligned leadership environment—all arriving together in one of the most technically and organizationally complex companies on the continent. That combination doesn’t happen often, and it is being met with genuine ambition. What has struck me most in this engagement is the quality of the shared diagnosis that the design workshops produced. The leaders in the room during R0 did not need to be convinced that the current structure has limitations—they already knew. What Org Topologies provided was a shared vocabulary for naming those limitations precisely, and a map for reasoning about how to address them systematically rather than anecdotally. The three-stage journey described here—from the current fragmented stack through the R2 consolidation to the optimal Team-of-Teams at PART-3—is a clear direction of travel. It does not ask the organization to abandon what it does well; it asks it to extend its best instincts further than they have been taken before. The cross-functional ambition is already present. The business engagement is already underway. The appetite for speed and autonomy is real. The design work is making those instincts structural. The open questions are crucial decisions that will shape how the design lands in reality. The Elevating Katas are the specific, repeatable practices that build the organizational muscle the design requires—embracing them is what carries the topology from the map into the team room. The journey ahead is substantial, and the conditions for success are unusually well aligned. Immediate next steps To move from design to implementation: complete the R1 design specification, including team scope and initial composition; formalize the governance model for business staff participation; resolve the SAFe integration model for partial-solution mandate teams; and initiate the Ops embedding process in parallel with the first Paradigm delivery sprint. This experience report presents a personal perspective on an organisational design journey currently in progress, written by the credited consultant. Details have been generalised to preserve confidentiality. The Org Topologies maps reproduced here are working documents from the design process and reflect the state of thinking at the time of writing. Should you have alternative views or additional details about this change story, please do not hesitate to contact Org Topologies and submit your version for publishing.

Introduction Any organization can be analyzed using the Org Topologies™ map. On this map, the Holy Grail is at the top right, representing an organization capable of adapting ultra-rapidly to face any opportunity thrown its way. An organization also capable of delivering value to its customers quickly and efficiently. Figure 1 : Org Topologies Map Startups generally fall into this category, and if they don't, they don't last very long in this highly competitive world, where it's crucial to perform at a very high level. A level where the consumption of the few resources available enables you to quickly find the product that the first customers will love and that will keep the adventure going. As a small organization grows, the general tendency is to segment responsibilities. Departments specializing in different areas are created (marketing, sales, after-sales, etc.), with a consequent reduction in adaptability and in the ability to deliver value quickly and cost-effectively. The growth of an organization tends to take it towards the lower left-hand zone of the map, where the teams and individuals making it up no longer have a holistic vision of what is best to do for current customers and to continue to prosper by reaching new markets, for example. In this article, we'll follow the story of Paul, a consultant specializing in digital application testing at the start of his career. On an assignment, Paul joins an organization with multiple departments, scattered teams and individuals, that require a lot of coordination to ultimately serve the company's customers. In this story, you'll see how this organization, and more specifically the business unit Paul joins, embarks on a path to regain the holy grail, notably by relying on the Kanban strategy. Chapter 1 : The beginning The business unit Paul joins, delivering digital services to its customers, is a collective of around 50 people. These 50 people cover all the skills needed to deliver a digital product to some of the company's customers (Business, IT, Marketing, Sales, Hotline, etc.). This business unit is located within a larger company serving other products and services, for a wider panel of customers. Using the 4 vertical strata of Org Topologies mapping (tasks, capabilities, partial and whole solution), this would give this form of representation: Figure 2: The company as a whole in the vertical hierarchy of org topologies The story that will be told throughout these chapters focuses on the business unit X that Paul joins. The organizational situation of this business unit when Paul joins the company is represented on the following Org Topologies™ map: Figure 3: Representation of the business unit Paul joins, with mapping of Org Topologies™ Links between individuals or teams (pseudo-teams) are represented by connectors. This organization is highly siloed, with no member of the sales group (WHOLE-1), who is closest to the customer, ever communicating with the product development group (CAPS-1). To act as an interface between the salespeople busy in the field selling the various products and services the company offers, and the people developing the product, the organization has chosen to place several business contacts (PART-1), each with their own area of responsibility (marketing project manager for X-type customers, another for Y-type customers, etc.). There isn't one coherent unit sharing knowledge, but X number of distinct interlocutors with their own dedicated business knowledge. These people find themselves without a global, customer-oriented vision, but with a partial vision centered on their business domain, their customer domain. The hotline (PART-1) has a broader, more shared knowledge base, with its members dealing with all types of customers and all kinds of problems, but it responds and unblocks situations on a case-by-case basis, without having the decision-making power and capacity for action to bring about lasting changes that benefit customers. In this situation, a lot of coordination is required between these different actors, and inevitably a lot of useful information is lost so that the right decisions can be made for the business and the best possible service can be provided to customers. These people don't have the skills to maintain and develop the product. They will rely on an IT department, generally divided into two parts, Business Analyst and Coders. In this case, a group of people with skills linking business and IT will analyze the problems and needs raised by the Hotline or by business contacts. It's also not uncommon for this group to consist of people who are highly specialized in specific business fields, but who can't all address the issues of different customer groups. The organization presented here is such a case, with its Business Analysts (PART-1) specialized in specific fields. Paul is assigned to join a group specialized in testing, the QA unit (CAPS-1). This group acts as a reinforcement, freeing up the BAs' bandwidth so that they can focus on understanding needs and issues, and manage "big" projects as IT project managers. A group of testers with missions often specific to non-regression test batteries. A frenetic pace of testing that leaves no room for knowledge sharing, leading people to specialize in parts of the application. Paul has a hard time getting to grips with his mission, as his colleagues are not available to help him understand how the application works and all its subtleties. Fortunately, there's a lot of documentation available, and after a few weeks he's able to find his way.  In view of future developments, an IT project manager asked him to focus on one part of the application. Obviously, the organization has equipped itself with IT developers (the digital product isn't going to be built by magic!), these developers form a unit often siloed into specific areas of competence (CAPS-1). This is the case in the organization Paul joins, where knowledge sharing is rare and peer-programming non-existent. A unit where each developer, according to his or her specialization on the application, takes bits and pieces of the specifications written by the BAs in order to code the evolution or the correction. The organization has chosen to call on an external technical skills center (TASKS-1) to manage fluctuating IT development skills requirements. The company's strategy is to control the increase in its payroll for technical skills, fearing a drop in activity around these skills in the future. They do not want to have dozens of employees to whom no activities can be entrusted. Between poorly drawn-up contracts and IT security constraints, this technical skills center finds itself carrying out corrective rather than evolutionary tasks, and submitting deliverables that must then be integrated by the internal development team. Finally, to deliver the application in production, carry out technical monitoring and ensure infrastructure maintenance and evolution, the organization has specialists in a dedicated unit (TASKS-1). Paul regrets not being in touch with the business contacts or the hotline. Instead, it's the BAs and IT project managers (PART-1) who receive the problems and, when necessary, pass them on to Paul's unit. He sincerely believes that he could better understand the bugs found and more easily reproduce them to help developers correct them. He's already mentioned the subject several times, but nothing has changed. An organization that sets up numerous committees to coordinate the various teams and individuals, requires many hours of reporting preparation and spends many hours in these meetings. Paul has to keep track of the bug counters, the percentage of remaining test cases, and an assessment of the time remaining to complete the tests he has been asked to perform. A complicated task for him since, if he detects a bug, he is often unable to continue because the bug needs to be fixed first. Since he has no idea how long the fix will take, he commits himself to other test work. As a result, it can take a long time to get back to what was interrupted a few days later. At least, he says to himself, " I'm becoming more and more proficient across the entire application. " He wonders on what basis the IT project managers communicate landing dates for the various projects. It seems to him that this is done on a gut feeling rather than on factual elements. Of course, there are Gantt charts and schedules, but there are always unforeseen events, such as bugs or setbacks, which he detects and which upset the plans. A type of organization that you may have known, or in which you are currently involved in some way. An inefficient, ineffective, and unpredictable organization. For this organization, schedule slippages are constant. Announcements of corrections and new features are communicated to customers but are hardly ever kept. Customer dissatisfaction is on the rise, to a level that is becoming critical to the business, and this is not something that management can afford to ignore. It is absolutely vital for this organization to increase its ability to respond faster and more predictably. We'll continue Paul's adventures in this organization in the next chapter... Chapter 2 : Redesign project and initial organizatio nal changes What's more, the organization, which was far from efficient, had dragged the digital application into a major technical debt. Customers were suffering the consequences, with critical incidents becoming increasingly frequent. Paul was also paying the price, with more and more non-regression tests being pushed to the tester unit, hoping to avoid bringing major problems into the hands of users. With this in mind, and with increasing feedback that the organization was not efficient, management decided to launch a major overhaul project.  They took the opportunity to make a few organizational changes to bring together the people whose objective was to carry out this project. The BAs/IT Project Managers (PART-1) merged with QA (CAPS-1), to form a functional unit (PART-1) (For the time being, this unit will be referred to as the BA unit). Paul, who had acquired a great deal of knowledge in the area, was offered the chance to join the team and terminate with consultancy. The idea appealed to him all the more as, at the business contact level, management had taken steps to federate a customer knowledge unit around one person, a business project manager (WHOLE-1).  Figure 4: Representation of the business unit after the first modification Through her work with sales, marketing, hotline staff and, of course, customers, this person would quickly acquire a broad knowledge of customer expectations and issues. She would also work closely with Paul's team to bring meaning to the work carried out and prioritize the most relevant developments in relation to what was expected by customers. Paul had never had the opportunity to talk to someone who made him so aware of customer expectations, and his motivation, and that of his colleagues quickly became much greater. In his previous experience, Paul had seen teams using physical visual management to manage their projects. He suggested that the rest of his BA unit implement visual management. Paul's idea and the collaboration with the rest of the unit led them to set up a simple "To do", "In progress", "Pending", "Finished" workflow. The development unit had also heard about this approach, and Paul remembers that they had implemented much the same thing. Paul discovered a little later that they had initiated the implementation of a Kanban strategy (see here for the official Kanban guide : https://kanbanguides.org/english/ ), however : " We were clearly not in a Kanban strategy, simply because at that time nobody knew what had been set up at Corbis* and the emergence of Kanban for the product management field. If that had been the case, we certainly wouldn't have had this column ("Pending"). Moreover, we didn't have any very explicit rules for pulling elements to the next states, so there was a lot of implicit in this workflow. Finally, we lacked all the other elements of a true Kanban strategy. How to control work-in-process? Explicit pull policies, a service level expectation, etc. At that time, we could and should have merged our workflows to have a global view of what was going on, because in the end, when we (BA) finished something, it was a specification, an explanation of a bug that we gave to the dev team, and which for them would then appear in their "To Do" list.  When they finished, it would come back to us (BA) for testing. We would then enter a test ticket that would go through our workflow (hence the pending column we used when a bug was found and we were waiting for a fix to be delivered to resume testing). " *If you want to know more about the birth of Kanban for product management that happened at Corbis (a Bill Gates company), the story is very well told in the Kanban pocket guide ( https://prokanban.org/kpg/ ). If these two units had juxtaposed their workflow, they would have obtained something like : Figure 5: The initial workflow and the evolution of the elements after a few weeks This juxtaposition made it difficult to get an end-to-end view of how long it took the team to complete a project that customers were waiting for, or that was useful as part of the application redesign.  Paul explains: " We sometimes had as many as 4 or 5 round trips with corrections to be made and new tests to be run, as many post-it notes circulating on our visual management. We had added creation dates to our tickets, but if we wanted to know how long it had taken to develop, test and correct the Dev A, we had trouble getting this information. The simple implementation of this had a significant gain in terms of visibility in each unit of what needed to be done, of what was in progress. Collaboration within our units had become better, and people were increasingly able to intervene globally on the existing application, but also on the new one we were building ". On the other hand, Paul reports that the business project manager was regularly annoyed because it was impossible for him to get clear information on when a subject was going to be completed. He could see that a lot of work had been done, and that progress was being made, but if he wanted to communicate to management or customers when the F functionality was going to be released, he still couldn't get accurate answers. This meant that he had to revisit his communication on a regular basis. The time actually taken to complete a feature was often well in excess of the initial estimate... and unfortunately not in the right direction, often taking several weeks. Management, for its part, was beginning to doubt the team's ability to successfully complete the redesign project, with numerous schedule slippages occurring again and again. Paul: "The increasingly frequent irritation of the business project manager and the doubts of management (which came down to us in the form of pressure) made us feel strongly that we had a major area for improvement to implement quickly. In discussions with colleagues from the BA unit and the development unit, we saw the need to break down our silos and become a single, multi-skilled unit, aligned around a single short-term objective, in order to reassure ourselves of our ability to complete the project successfully. We also hoped that this would give us an overview that would enable us to be more reliable in our answers to the “When?” questions we were often asked... " Chapter 3: The birth of a Scrum Team This willingness of two separate units to work together to improve the overall performance of digital product creation was somewhat accepted by management. Not without a considerable effort, particularly on Paul's part, to convince everyone that the experiment was worth trying. This new unit was obviously expected to deliver on the expected results of this experiment, particularly in terms of improving Time to Market (T2M).  This T2M was clearly the cycle time, but the team used this name, better understood by management, to sell the experience they wanted to achieve. Figure 6: Representation of the business unit after the second modification Paul relates that this organizational evolution brought about two things: "The "business" project manager more or less integrated the team into a Product Owner accountability. I say more or less because we were in the early days of Scrum. If today, in many places, Scrum is still not properly implemented, particularly around the PO role, I'll leave you to imagine what differences this PO role had at the time (and we're talking about the years ~2010) with that of a project manager (spoiler alert: nothing or almost nothing).  Together with the in-house developers, we (BA) formed the Scrum development team (yes, that's what it was called back then, so I'm allowed to say it!). We had a great ticketing tool. Great is ironic, because it's certainly responsible for a lot of the mistakes we made when defining our unified team workflow: Figure 7: Unified workflow following organizational change We finally had a more global, unified view of what we were doing to create value."   You may have noticed that the "pending" column was still present with this unification of workflows by merging the two entities.  Paul explains why: "Well, for us at least, it was very clear because we weren't yet a team, but just a group of people with almost all the necessary skills, but still talking about Business Analyst People, Technical People and passing the hot potato back and forth. So yes, we always had this pending column mainly meaning that we were waiting for the technical people to correct a detected problem."   A bad practice, at least if you hope to achieve a high-performance flow! (But so common in an organization with silos). In fact, each silo can be seen as a dependency, through which each element of potential value has to pass before finally reaching the hands of the end-user. Each dependency is a point where the flow breaks down, with elements potentially (and frequently) piling up and aging. As a result, these silos lead to an increase in the number of items in progress, as, for example, the "Business Analyst People" start additional work while awaiting either developments or corrections. Contextual changes are numerous, which also leads to a loss of efficiency, due to the not-inconsiderable cost in terms of time spent going back over elements. A serious study on the subject of context switching showed that by switching contexts between 2 subjects, around 20% of time was lost, and 40% of time was lost by pursuing 3 subjects at the same time (see: https://www.scrum.org/resources/blog/financial-cost-task-switching ).   Even so, after a few weeks of experimentation, this fusions began to show positive signs. Both in terms of T2M, as measured by the Product Owner-to-be, a downward trend was visible, but also on the quality of what was being produced. Indeed, this fusion had sometimes (unfortunately not yet regularly) led to collaborative workshops between the different skills to understand the expectations, the problems to be solved and to find the best solution together. Technical skills were thus able to better grasp what was expected, enabling them to make proposals (and no longer code without trying to understand why), which collectively enabled more qualitative increments to be implemented. However, there was still one notable point of inefficiency in this organization, and that was around an external development unit developing software for the service center. Paul makes the point very well: "In fact, in this workflow, if you zoomed in on "Development" you could see that things were no longer within our unified team, but on the side of this service center. The work they were doing had to be integrated. We added an integration stage before the acceptance stage to make this transparent. The data collected clearly showed a point of inefficiency, which helped us to support management's need to address the issue. "   When the opportunity arose to change the service center, Paul and his colleagues managed to convince management to make a few changes to the contract and internal process. Not without difficulty, they succeeded in getting this additional coding force to join their Scrum team and to work on the product in the same way as anyone else. This reduced dependency aligned these people with a common objective and increased the collective intelligence to come up with the best possible solutions. In the end, both the service provider and the people involved were more committed, because they were faced with problems to solve that made sense to end-users (instead of "peeing" code without understanding why).   A change that clearly paid off, as you'll discover in the next chapter. Ch apter 4: Ramping up the Kanban strategy With a little patience, a little effort, and a lot of dialogue, Paul and his team sealed a collective spirit of unity.  They were making progress in their understanding of Scrum, but also of the Kanban strategy. They began measuring cycle times and experimenting with WIP limitations in an effort to optimize their workflows. In creating the team's DoD, they unfortunately still were not allowed to go into production. This last step was always carried out by the infra-Prod people (TASKS-1) outside their team. Paul says: " We no longer saw work items as something we passed on to each other, but as something we had to finish as quickly as possible together. We helped each other, both functionally and technically, with whatever skills we individually had. For example, the functional people had learned how to carry out automated tests, and not just through the GUIs, we went as far as automating tests at API level. People with technical skills were invited to participate earlier in the design of the solution and contribute their ideas. Some of them carried out tests, when this was preferable given the state of our workflow. We were now in the same room, collaboration was very strong, pair programming had become a regular custom and pairs often functional & technical." Figure 8: Representation of the business unit after the third evolution The Scrum team's workflow* had thus evolved and was now :  Figure 9: Workflow evolution following this third upgrade * For the sake of readability, not all the elements of a workflow definition for a professional Kanban strategy are shown here (refer to the Kanban guide to understand what's missing). By checking with Paul, the team had established WIP limits on the refinement, dev and acceptance stages. The WIP limits were intended to help improve the team's focus by avoiding starting too many jobs in parallel, but also to avoid a "shortage" somewhere in the workflow. The team therefore established optimum WIP limits, i.e. both an upper limit not to be exceeded, and a lower limit to be maintained. Ultimately, the aim was to experimentally find the best limits to improve performance.  Paul: "The mistake we made at the beginning was not to also limit the stages of waiting for dev, waiting for test (or by grouping stages with the previous stage of active work)". This is a classic mistake, which often results in a pile of pending work, and ultimately more work in progress than the optimum level for the team. Paul reports that this problem was quickly detected and corrected, adding: " All this led to a clear improvement in our speed of processing. We didn't measure it very well before, but with the data that the project manager, hmm sorry our Product Owner, was communicating and the various reschedules, we were roughly between 30 days and 90 days to complete a feature. The data we're now collecting showed us a halving of the maximum cycle time and reduced variability (~25-45 days). " These now frequent measurements of cycle times, and the quest to improve their performance, led them to look at an even more interesting metric than cycle time: the age of the current elements in their flow. Why even more interesting? Because it informed them much earlier than the cycle time (calculated only once the item had reached the end of the workflow), enabling them to have the necessary conversations more quickly to best manage the performance of their workflow. Paul tells us how it came about: "We discovered this metric through the blog post: https://caroli.org/en/latency-and-banana/ . The idea seemed brilliant, but we preferred to count the number of days without hanging banana peels on our post-its... A little later, we learned how to visualize the cycle time of our various components on a scatter plot and, by adding percentiles, we discovered the distribution of the cycle time of our components... 70% under 24 days, 85% under 33 days. This will lead us to define a Service Level Expectation (SLE) based on our historical data and challenge us to do better: 20 days or less 85% of the time was the one we chose. We coupled that with tracking the age of our current elements and it was a game changer." The limits of WIP that the team had experimented with had brought a fairly minimal improvement in performance. The experiments carried out had sometimes brought improvements, but also sometimes regressions, except that it took little time to assess. Age control and the Service Level Expectation (SLE) the team had chosen, on the other hand, brought a substantial improvement. Better WIP limits even emerged quite naturally through the practice of age control and the focus on trying not to exceed the SLE. After a few months, the team had more than met its challenge and could even challenge itself to further improve its SLE. However, it also undertook another improvement, that of increasing the usability quality of its product, by training part of the team in UX Design. However, Paul tells us about one of his misadventures with UX skills: " We had succeeded in selling the contribution this skill could make to our customers' happiness, and therefore to our business. Management and our business representative (Product Owner) were so anxious to see the contribution this type of skill could make to the product, that they wouldn't let us apply our newly-acquired skills on our own. They called in a specialist consulting firm, and unfortunately this added a separate unit to our team, and therefore a unthoughtful dependency ". Chapter 5: A good idea that turned into a dependency for a while (thus a flow killer) This addition led to dependency and, unfortunately, an overall slowdown of the system. This team had its own workflow, disconnected from that of the Scrum Team. The Product Owner worked upstream with this external UX team to understand more precisely the customer's expectations and issues. They would produce prototypes, and carry out user tests with these prototypes. Unfortunately, this took up a lot of time. Figure 10: Mapping org topologies after the fourth evolution Paul remembers this period well, frustrated at not being able to put his newly acquired skills to good use:  "They were quite high-level in the macro-design of the solution, and we always needed when we got their work back to do some fine-tuning, chopping up the big features into smaller pieces to move forward iteratively and incrementally as we'd become accustomed to doing. What's more, it wasn't unusual for the prototypes they had tested with users to be a problem for us in terms of functional or technical feasibility. We were in a discovery/delivery silo." This desire to better understand customer expectations was commendable, because it's true that it's a shame to develop things that aren't expected by the customer, that aren't going to be used, that are going to create usability problems, but all this had a cost, and in the end T2M, the cycle time for delivering product evolutions, was much shorter before. Paul and the team had managed to find out how long it took before a subject reached them:  "You have to see that roughly with the addition of this external UX/UI team it was ~ 2 months of cycle time spent before we got the hot potato back (if not almost cold, considering the delay already passed). The real knowledge of what we were bringing in terms of value was thus delayed by ~ 2 months, but we potentially had something with a higher level of usability and a few low-value hypotheses discarded. The main problem, in my opinion, was the disconnect between discovery and delivery, accentuated by the fact that it was all upstream work and this UX Team never drew on the concrete in production and in the hands of users to close the learning loop leading to new UX reflections to improve the product." In this ultimately business-oriented positioning, in the sense that the service provider responded to the Product Owner's initial "discovery" order, but without closing the learning loop with the real product and real-life user behavior, the organization was far from reaping the benefits of UX design. Paul and the other team members who had been trained were well aware that the UX service provider could or should have offered more.  They had lost a battle with the arrival of this external UX team, but decided not to stop there. They installed a product analytics tool and began to discreetly analyze user journeys, feature usage and dropout points, and set up heatmaps to take a closer look at the pages where users were circulating in and where they were clicking... Paul tells us: "All this information was extremely valuable, as it enabled us to learn how users actually used our product. I still don't understand why the UX expert company didn't offer this and settled for this initial "discovery", but in the end it made us happy. Indeed, one day, we decided with a few other team members that we had enough marbles via product analytics to open discussions on unused functionalities, paths to be improved, and so on. Where we identified areas for improvement, we produced a few low-fidelity (and inexpensive) mock-ups to suggest improvements and provide a basis for discussion. These elements paid off, as they were much appreciated by the stakeholders and management, and enabled us to establish our expertise in this field too". The UX service provider's mission came to an end a few weeks later, and management and the Product Owner decided to rely on the expertise that the team had proven to have acquired, at least at a level where they weren’t seeing the benefit of paying for an external service. This led to an evolution of the team's workflow in two aspects. Firstly, the team (including the Product Owner) decided that the endpoint was no longer when the product went into production and was in the hands of the customer. The endpoint would now be beyond that and would be when the collection of feedback from the use of the functionality was deemed sufficient. Either to decide to finish, or to decide to finish but with a new input to the workflow linked to the feedback and learning gained from using the product. Second workflow evolution on "discovery" aspects. Paul had recently taken the Professional Scrum With UX (PSU) course and clearly understood the concept of agile dual track. In a nutshell, this concept is the delicate, ongoing mix between what needs to be learned upstream to avoid developing things that won't be used (or almost not used) and fast development, based on this learning, of small increments. Providing fast learning loop and enabling the refillment of idea and evolution based on this new knowledge. It's not, as many may have understood (and perhaps still do), two parallel processes, carried out by different people and feeding into each other in a discontinuous, sequential fashion (the discovery work of the last 2 weeks, feeding into the delivery of the following 2 weeks), with no ongoing consideration of the learning achieved through each "prism". With this newly acquired knowledge, Paul proposed an experiment to the team to visualize this discovery work at workflow level. " In agile product management, it's crucial to know as quickly as possible if you're wrong, so it was beyond me to bring in the idea of having discovery items circulating alongside delivery items that needed to be done before we could progress on delivery. Most of the time, this work had to be linked to the same element of value, so that it was seen as one unit of value, where the whole team remained responsible for flowing the element as quickly as possible towards the end of our workflow.  But on the other hand, sometimes it was necessary to carry out more in-depth and longer studies to ensure that the value hypothesis was viable. So I brought the following experiment to try:  The creation of a new type of value item that would circulate in our workflow, which I called "Study (discovery)" and which would correspond to this longer discovery work. For the rest, I suggested to the team that they consider the contribution of UX practices in the various stages of our workflow: Refining, for example by quickly interviewing a few users, or quickly prototyping something on paper and testing it with a few users. This enabled us to start the IT development with a few improvements or adjustments to the solution we had in mind. During development, and when it made sense (especially when questions about usability emerged), we would continue to explore whether the solution was appropriate, for example on the basis of a higher-fidelity prototype. When we got to the acceptance stage, we would approach end-users to have them handle the new functionality, and in particular check points where we had doubts about usability." These proposals were deemed interesting, and the team embarked on the experiment. For the new "Study Discovery" element type, the team challenged themselves with an associated Service Level Expectation (SLE). They didn't want to bring back the bad experience they'd had with the external UX consultancy themselves, and decided that this should be carried out the majority of the time (80%) within a timeframe of no more than 15 days. The workflow* could be represented as follows:  Figure 12: Workflow definition after the fifth evolution * For the sake of readability, not all the elements of a workflow definition for a professional Kanban strategy are shown here (refer to the Kanban guide to understand what's missing). The experience was highly conclusive, and further strengthened the team's links and pluridisciplinarity. The expertise wasn't at the same level, but this meant that UX work that didn't require a great deal of expertise (collecting impressions and feedback on mock-ups and prototypes, for example) could be carried out by virtually anyone in the team. All these developments brought the team closer to the end-users, management's confidence in the team was excellent, its efficiency had increased drastically and so had its predictability. The Product Owner (and a good part of the team) had been trained to use their (factual) throughput data to make probabilistic predictions via Monte Carlo simulation, which gave much more accurate and relevant results. Confidence between marketing and sales was also greatly improved, and any tensions that may have existed in the past had completely disappeared.  The Product Owner was also increasingly integrated into the team, and on the strength of this experience and the results obtained, he was offered a very interesting opportunity in another company, which he seized.  Management knew they could count on Paul to step in and offer him this opportunity, which he was quick to accept. At that time, the organization could be described as follows:  Figure 13: Mapping org topologies after the fifth evolution Paul, supported by the rest of the team, has been working ever since to resolve a difficulty that is still largely hampering the team's ability to deliver value: the existence of this production and technical infrastructure management unit. Indeed, the Scrum team is always dependent on this unit to be able to see completed developments available in production, which means they lose a few days before the new features are available and they can learn from them. Once they have the power, the permissions and authorizations to deliver their products themselves, they will truly have become an autonomous Scrum team, able to deliver a continuous and rapid flow of new valuable elements. Hopefully, they will succeed, and when they do, the organization in this business unit can be mapped as follows:  Figure 14: Mapping org topologies after the sixth, possibly upcoming, evolution THE END... or not, depending on how you readers react ;-) A big thank you to Alexey Krivitsky and Roland Flemm for creating Org Topologies™ and their incredible OTP class that I was lucky enough to follow on Paris in March 2024, as well as to their various feedbacks, clarifications and clarifications to bring to this story before I publish it.  Elevating Katas (addition of December 2024 by Alexey Krivitsky): This article by José provides great examples of what we now call Elevating Katas . Elevating Katas are introduced as repeatable, structured patterns or routines introduced into an organization’s ways of working that help teams and leaders build new capabilities, improve system-level performance, and “elevate” their overall approach to value delivery. Elevating Katas Identified in this Experience Report on Business Agility with Org Topologies and Kanban: Forming Cross-Functional, Customer-Oriented Teams Transitioning from separate specialist units (BAs, QA, Dev) to more integrated teams capable of handling end-to-end work. Repeatedly merging previously siloed roles encourages shared understanding, reduces handoffs, and aligns everyone around a common goal—improving flow and predictability. Unified and Evolving Workflows (Kanban Strategy) Introducing a visual workflow and continuously refining it with techniques like WIP limits, tracking work item age, and establishing Service Level Expectations (SLEs). Each iterative adjustment of the Kanban system and the workflow—removing “pending” columns, merging steps, and controlling WIP—forms a kata of ongoing operational improvement. Integrating Discovery and Delivery Practices Moving from upstream “big batch” UX/design activities and long, disconnected cycles to a “dual-track” model. By repeatedly incorporating small-scale discovery tasks directly into the same workflow as delivery, the team runs continuous experiments. Over time, this kata improves their ability to learn quickly from real usage and adapt solutions faster, reducing waste and cycle times. Data-Driven Continuous Improvement Routinely measuring cycle time, variability, and throughput to guide improvements. Using product analytics, user feedback, and metrics-based decision-making becomes a kata—repeated cycles of gathering data, reflecting, and refining the approach. This ensures that changes aren’t based on guesswork but on evidence and measurable outcomes. Gradual Removal of Dependencies and External Silos Systematically integrating external providers (e.g., external development service centers, UX consultancies) into the core team or phasing them out. Repeated attempts to reduce external dependencies—such as enabling the team to deploy directly to production—constitute a kata that steadily elevates the organization toward greater autonomy, responsiveness, and continuous delivery capability. More on Elevating Katas here .

Management Summary  Leaders set business objectives and define strategies to achieve them, yet often lack the tools to sustainably drive organizational performance. The good news is that this can be learned and thoughtfully applied today at organizations. Org Topologies (OT) will help you get the desired change going. How do you define and successfully lead the change that’s right for your organization? Here’s a key point: Different goals—rapid delivery, global adaptability, resource optimization, or amplified innovation—require different and tailored org designs. As a leader, you can define that goal and use the approach offered here to evolve your organization in the chosen direction.  Why does change fail so often? First, existing solutions may seem suitable when analyzed superficially, but, in fact, don’t fit your unique context. Second—an underappreciated factor behind failed change—people, when not owning the change ideas, won’t fully accept them and won’t go the extra mile to make them work. As a result, the promised benefits of change often remain unfulfilled despite all the wasted resources and opportunities. This case study explains how applying Org Topologies ensured that a company was implementing a correct organization design and how OT helped to introduce the change in the product development group. Strategic Org Design What is Org Topologies? Org Topologies (OT), being a strategic org design system, helps you align all the moving pieces so that your (1) business strategy, (2) organizational capabilities, and (3) change process work together cohesively to drive the desired organizational performance. Why Use Org Topologies? When organizations undergo transformations, choosing a framework like SAFe, Spotify, or LeSS alone may not be sufficient. OT helps identify if your new organizational design will genuinely solve the underlying issues or if it will fall short due to overlooked systemic challenges. OT helps companies align their internal structures with business goals, resulting in a performance boost, measurable by faster innovation and efficient delivery of customer value. Customer Case: Elevating XG Customer profile: XG (anonymised for confidentiality purposes), is a scale-up in the EV market. They provide an EV information platform and empower the most ambitious players to meet EV power demands. The challenge at XG  The business was growing fast, but the R&D department could not keep up with the growing demand for features. Although XG was the number one innovator in their market, they noticed that they were losing their pole position. Competitors were catching up in releasing new customer delighters. Growing the number of R&D employees did not solve the problem. The time to market for customer requests increased from weeks to multiple months.  XG management studied the possible causes for the declining delivery speed. Their R&D department consisted of 7 teams, each team responsible for one component of the complete XG solution. Their org design had grown organically over time, with its main driver being clearly defined component ownership by deep specialists. While growing from 8 to 50 people, the R&D group had turned into a collection of isolated silos.  The managing directors agreed on the need to improve the organizational performance. They would need to restructure the processes of the teams at R&D. Middle management (Head of Engineering and Head of Product) was tasked to implement a change to solve the problems.  The solution designed by XG To solve the performance problem, middle management informed themselves on existing frameworks. Before any external consultant was approached, they crafted a custom future org design for the R&D department by themselves. They anticipated implementing key characteristics of the LeSS Framework: removing Product Managers at the team level in favor of three product areas, with each one having a single Product Owner and multiple teams. They designed the product areas by customer type. Each area should work as a team of cross-functional teams. They had designed a new Target Operating Model and were looking for external consultants to implement the TOM and support them in improving their scaled Scrum processes.  Org Topologies It seems XG had found/created a solution that needed no further discussion. However, a closer look at the TOM revealed that implementing it would not result in a sustainable change.  Three observations led to this conclusion:  The anticipated TOM did not completely resolve the root causes of the long time to market. The change was not systemic, meaning it focused only on restructuring R&D and did not yet consider other elements of the organizational design that influence organizational performance. Top management was very supportive, but not involved.  To address these challenges, we used the Org Topologies MADE method (Map Assess, Design, and Elevate) as a guide in our consulting and coaching activities. Map   We used Org Topologies to map the existing design and assess the future TOM. OT Mapping entails determining the prevalent archetype of each org design unit (teams, managers, etc) involved in the value creation chain and plotting them on the OT map. Below is a mapping of the existing org design. Org Topologies mapping at XG, existing design The design shows a Head of Product (H) working at the whole business level. He works with eight Product Managers (items with a P on the map) who work at the capabilities level , each responsible for one team (items with a T on the map, one color representing one capability).  Each team is locked to one component (capability) of the whole solution. And each team depended on (most of) the other teams to deliver customer value (depicted by the lines connecting the teams). Assess Assessing with the OT MADE Method consists of verifying if a design is fit for purpose. In this case, we asked ourselves if the new TOM XG was fit for purpose. Was the new org design the correct solution to achieve the business goals in their market? How well was the design understood, and how well did (upper) management know the change implications? Each org design provides certain organizational capabilities. Org Topologies proposes three recognizable topologies: The Resource Topology, the Delivery Topology, and the Adaptive Topology. The business ambitions and market conditions determine which organizational capabilities most likely support achieving our goals. In the XG case, the market was uncharted, finding new innovative solutions to win customers and being fast in delivering known solutions were required. The Adaptive topology can provide this.  Mapping the existing org design confirmed the root cause for slow value delivery: the dependencies between the teams caused hand-offs and coordination work.  We mapped the TOM proposed by XG. In the proposed design, the Head of Product works with three Product Owners, each for a specific customer type. Each PO has a group of teams working at the feature capabilities level.  Note that the colors of the teams inside each bubble in the new design are similar, since their only level of specialization is the focus on their business area.  Reducing the number of product managers and elevating them to manage three partial solution areas was a great idea. However, having three product areas would not completely solve the inter-team dependency problem since product backlog items might span multiple areas. Also, the head of product would still have to deal with trade-offs of insufficient capacity for important initiatives, and local optimizations inside each area were most likely to occur. For example, features would be built for a specific customer domain, although they are not the most important priority at the XG company level. Management acknowledged this problem, but this suboptimal design was deemed to be a great improvement considering the component landscape they were coming from. Creating a single Backlog for the whole company was too big of a stretch for upper management at that moment in time. Design The Design phase explores options to consider for the best fit for purpose. In this phase we explored the structure of the adaptive topology and concluded the time was not right for implementing it. Understanding how the proposed TOM would or would not improve the performance before the change is implemented is a great win. Discussions showed there was insufficient understanding at XG of how the adaptive org design would work in practice and that it was unclear what was needed to elevate the existing org design to the new TOM.  Elevate   The fourth step in the MADE method is Elvate. The Elevating Katas answer the question “But how are we going to do it?” It is a rich set of practices that bring the ongoing transformation effort into business as usual.  The Org Topologies mappings of the existing and proposed designs were extremely helpful in the sessions where we communicated the change with the development group. Team members had heard about the change initiative but did not have a concrete idea of what the change would be like. To create the new areas, the existing component teams were disbanded and new end-to-end teams needed to be created. Especially the formation of new cross-functional teams was unknown to them. And yet, this was the most impactful change that would hit the teams. The mappings transparently explained that the existing component team ownership would be broken and replaced by end-to-end capable teams. Explaining the existing component team dynamics with the map, visualizing the inter-team dependencies, was a feast of recognition for the development group. Talking about expanding the mandate on skills and scope of work created the understanding of how to move forward to end their dependency hell. Explaining the current and future situation using the map has become an ongoing activity. Learning simply takes time and repetition. We prepared the existing teams to be ready to work in the new business areas in a "team of teams setup". We flipped the organization in two days. Meaning: abandoning the old structure and starting to work in the new setup took two days. We ensured that everyone had time to work on the change preparations while business continued as usual in the months leading up to the flip. Time and effort were spent learning and preparing at the cost of a productivity loss. This is a necessary investment: slow down now to accelerate later.  We applied the following Elevating Katas to enable the flip to the new design:  Merging Product Backlogs Forming a Team-of-Teams Sharing Ownership Across Teams (rotating duty team allocation) Enabling Team Self-Design Sharing the Same Cadence Across Teams Designing Tailwind Career Paths (everybody is a Product developer) Expanding and Sharing the Definition of Done Across Teams Holding Multi-Team Product Backlog Refinement Using Synchronous Team Work to Expand Capability and Ownership After the flip, the change work needed to continue using the Elevating Katas to execute smaller experiments to further improve the development system: Pair programming Mob programming Opening all repositories Install communities of practice Code mentorship Integration test automation Architecture and knowledge sessions The results When the teams started working in the new setup, the performance increased dramatically.  Happiness has gone up for almost all employees. However, some devs have difficulty accepting shared code ownership and broadening the mandate on the business domain. Some single-skill specialists struggled to find their new purpose outside of their comfort zone. Initially, upper management was thinking lightly of the impact of the anticipated (process) changes in R&D. During the change process, they started seeing the impact of the transformation and the need for employee buy-in to embark on a never-ending journey of continuous improvement.  They enjoyed the energy of the people crafting their journey within the boundaries set by management. The support department was onboarded and included in the change, not only to manage their expectations but also to involve them during refinements and Sprint Reviews. After eight months of working in the new setup, the pain of local optimization per area was making its point. Delivery on the roadmap was not advancing. Tech debt was deprioritized for local area feature work. People were pulled across areas to share their expertise, leaving crippled teams behind. Product owners disagreed and spent time bickering over who picks up which item as most items appeared to span multiple areas. The organization had to experience the downsides of their self-created design to be ready for the next move: implementing Adaptive topology! Conclusion The Map, Assess, Design, and Elevate steps brought the client from supporting the change initiative by funding it and to being involved by understanding the change. The MADE method revealed omissions in the target design and demonstrated the complexity of the change.  Org Topologies supported the organization in their journey to improve the org design until it was fit for purpose (for now). We used the OT mapping in various workshops to explain to the employees the current design and the new org design. The visualizations are a powerful means of communication to bring understanding of the why and what of the change. We emphasized that elevating a development group impacts how the company sells its product, hires new people, provides support, and manages its human capital. Org Topologies elevated managers and employees to become systems thinkers. Watch the videos on this transformation: Lecture while the change was in progress: https://www.orgtopologies.com/post/doing-a-less-flip-in-two-months-with-org-topologies   Lecture at the LeSS conference in 2025: https://less.works/videos/doing-a-less-flip-in-two-months

Poster POS Inc. (or Poster) is a cloud-based SaaS automation for small-to-midsize businesses in the hospitality industry, also known as HoReCa (Hotels-Restaurant-Catering). The business was founded in Ukraine around 2013 and has shown a very high level of resilience since then. The HoReCa industry has been severely affected by Covid-19 and by the Russian war on Ukraine in 2022. Still, the company restored its profitability and even grew its B2B clientele in Ukraine during the wartimes. In 2021, the company has undergone serious reorganization, striving to increase its adaptability. Poster was inspired by the ideas from Large-Scale Scrum (LeSS) , such as global optimization with a whole-product focus and delivery of high-value work with customer-facing feature teams. This case study analyzes that transformation journey using Org Topology Scans (org scans). It covers three distinguishable organizational designs: Org scan of the status quo in Poster before the LeSS adoption, "Team-level Scrum" Org scan of the envisioned initial LeSS-Inspired blueprint (which drawbacks we timely rethought and eliminated) Org scan of the improved LeSS-Like org design implemented in 2021 as the scope of this LeSS adoption. The following chapters describe these three OT™ scans in detail. Heads-up! Video is Available There is also a talk by Alexey Krivitsky from the LeSS Conference 2023 featuring some of the ideas from this article: 1. Org Scan of the Pre-LeSS Structure "Team-Level Scrum" Before the LeSS Adoption started in the summer of 2021, Poster had around 50 engineers in the R&D department that were structured as: a dozen of development teams varying from 2 to 6 people; teams were built around a specific technology, a component, or a feature set; one separate infrastructure/operations team of several people; one small designer group , whose members mainly worked on individual task lists to support the development teams with visuals and UI sketches. According to the Archetypes of Org Topologies ™ , the development teams in this setup can be seen as a mix of task-focused, component-oriented teams (TASKS-2)  and capabilities-focused teams working on a narrow capabilities set (CAPS-2) . What is typical for these designs is that every team had an individual team-level backlog (task/capabilities list) that was managed by a team-level "PO". Most of the teams, especially the bigger ones, also had a team lead - an interface person for the team and the ultimate solution-oriented decision-maker. The designer group can be seen as individual task-focused work (TASKS-1) . Two more departments, tightly coupled with the R&D were the "client onboarding" (3 people) and "1st & 2nd-line support" (25 people). This case study doesn't go into the details of those departments, keeping a focus on R&D and its radical transformation. The illustration below shows an org scan of Poster product department as of the summer of 2021 with TASKS-2 and CAPS-2 archetypes. Analyzing the "Team-Level Scrum" Org Design According to the Org Topologies™ mapping, all the archetypes of Team-Level Scrum provide close to no organizational adaptability, as they are narrowly specialized in tasks and individual features. That was why Poster wanted to improve its org design and planned the restructuring. The "Team-Level Scrum" org design is typical for many product development organizations of any size. It grows naturally as a company hires more people and forms new teams. It is also known as the "copy-paste Scrum adoption" antipattern, where Scrum is implemented as a cookie-cutter for each newly formed team. Scrum in such an organization is seen as a team-level way of working, where each team gets its own backlog and a backlog owner and starts working with iterations that are typically non-synchronized among the teams. Such an approach allows the teams to run a Scrum-like process individually. And from the team perspective, this is an efficient way of working, as it allows teams to keep focus and ownership on given product components or some narrow feature sets. This org design is also relatively easy to implement, which is why it is so widely adopted in the industry. But as the number of teams grows, additional complexity caused by inter-team dependencies increasingly slows everyone down. Hiring professional managers and applying project management tricks just make things worse. These practices add communication layers with hand-offs, bureaucracy, and processes to an already poorly designed engine. In such a model, even though each team has a sharp focus and might even have an illusion of progress by ticking off items from its individual backlog, the performance at the organizational level tells a whole different story. At the level of the R&D department (not just individual teams) in such organizations, we see slow delivery and low adaptability. This is a systemic view: paying attention to the interaction between the parts is as important as studying the parts. The lack of maneuverability (teams cannot easily switch to working on new things, as they don't have the necessary knowledge and skills), causes this type of organization to hire more specialists to perform specific tasks. This makes the system even more complex and degrades over time. Our experience is that at the size of around 50 engineers, these challenges start to emerge and become painful enough to make managers want to act on them. By the spring of 2021, the leadership team at Poster had recognized these drawbacks and was actively searching for an improved org design that would eliminate the aforementioned problems. 2. Org Topologies™ Scan of Initial LeSS-Inspired Org Blueprint LeSS promotes org design based around long-lived, cross-component, cross-functional, customer-facing feature teams . Such teams deliver and learn much better than narrowly specialized ones. By learning to work on things that they previously didn't know, feature teams continuously improve their adaptability. Therefore, the whole large-scale product development system based on feature teams could potentially, over time, get better at delivery and better at learning. These qualities enable faster value delivery and higher organizational adaptability: Faster value delivery comes from having teams that are learning to build products end-to-end. Higher organizational adaptability comes from teams that are learning to work on the whole product. If the company's optimizing goal is faster value delivery and higher organizational adaptability, the LeSS-inspired org design is the most consistent with those goals. In such an organization, the product owner will only have to reorder the product backlog items to change the course of development for all the teams. No reorganization is required to realign the product development organization to adopt a changed product strategy. The product development organization is agile and can adapt to changing requirements just in time. Already during the next refinement session (in LeSS terms, "multi-team product backlog refinement" or PBR ) the teams will start learning that new high-value work. At Poster, the leadership team plus all the developers and business stakeholders were trained in LeSS and its ideas before adopting this org design. It took around two months to arrive at informed consent on which org design to use. During that time, several org design blueprints were created, compared, and contrasted. The following illustration depicts a scan of the anticipated org design blueprint (later it was discarded due to the reasons listed below). This org design consists of three "value areas": B2B (the core product). B2C (the new, innovative product development). Growth (product tuning to increase customer activation and retention). The B2B area was the largest and was planned to have the biggest investment. Four feature teams were planned to share a single product backlog. Very much a LeSS-like structure. This design can be classified as B3. The other two areas had fewer investments and were to have a single team each. They are capabilities-focused, as each team would have an individual feature-centric product backlog, i.e., having a relatively narrow product focus. No changes for the infra/ops team and the designer group were planned. Analyzing the Initial LeSS-Inspired Org Design As it can be clearly seen from the org scan above, several single-team value areas were envisioned (B2C and Growth), even though the leadership team at Poster had already embraced the idea of LeSS and broader product definition . What was driving the management to choose a sub-optimal org design? And what were the shortcomings of such an org design? Why not allow all the teams to work together on the entire product as LeSS proposes? From our experience as org consultants, the most voiced arguments for creating narrow-focused single-team value areas are: Investments & Innovation : "As we have never been able to work on X and Y, let's create an X-team and a Y-team". Experts & Ownership : "There is an expert in Z, let's make her a product owner and give her a Z-team". Focus & Accountability : "Teams need to have a clear focus and accountability for each component; otherwise the code becomes a mess". Learning & Specialization : "Knowing everything is impossible, we value and need the specialists". We often hear these kinds of objections when a LeSS-like org design is proposed. At Poster, it was a mix of the first two arguments that produced the initial blueprint. Such arguments are hard to counter, as they stem from deep beliefs in the convictions of the leaders. They have not yet seen a different setup than their own, and all their experiences and career successes confirm that what they already know is working. This confirmation bias automatically disproves all new ideas. An organizational design is the sum of the mental models (beliefs and value systems) of the people who created it. But all mental models are personal. If we want the managers to own (create and support) a new improved org design, there is not much choice but to work with them to help them see new options, help them challenge, and eventually have them adapt their mental models. The breakthrough of discarding this model and going with a simpler org design (LeSS for all the feature teams) came from a realization that B2C and Growth can still be worked on, if needed, even with all teams sharing the same product backlog simply by setting the order of the items. Also, the people from the teams voiced a strong argument supporting wider collaboration of the teams: "Let's learn to work all together as one; isn't that why we want to go with LeSS in the first place?" To make such powerful conversations possible, during the preparation/learning phase, all the team members and the management representatives were regularly gathered for open-space-like events. That shared context helped them to uncover and collaboratively agree on many open questions. Eventually, building informed consent to start with a simpler holistic org design, is described below. The real goal of the design activity is to create the simplest org design possible that would still work. More processes and roles can be added later when needed. But starting with a simpler org design empowers the people to own it and improve it. 3. Org Scan of LeSS-like Org Design at Poster It took us several months to arrive at a simpler org design with no single-team areas. An org design that everyone was happy to start with. An org design that would barely work, but was understood by everyone to own it from day one. The improved org design would have all the feature teams sharing work and working across the product. That would classify them as WHOLE-4 teams. Analyzing Org Design: "LeSS for the Whole Product with All Teams" This simpler org design covers many raised concerns above: Investments & Innovation: In this org design, when there is a need to work on Y or Z, these items simply get prioritized and put higher on the common product backlog. And then the teams (one, several, or all) will start working on them. There is no need to create specialized teams. If, for instance, the B2C or Growth topics become the most important, nothing stops the Product Owner (PO) from putting those items on the common Product Backlog and letting the teams start to refine and deliver them. This way, in every Sprint, the PO can decide with the teams how many teams should be working on these topics. This creates a fluid org structure where pairing between teams and topics happens just in time. In contrast to statically defined separate org units (value areas) per topic. This way, an organization stays highly adaptive, as it can decide to jump on any opportunity without any reorganization efforts. Experts & Ownership: Shared work on the common product backlog by all the teams leaves a lot of room for collaboration with experts. But this collaboration happens only on high-value work (just-in-time). Such a modus operandi eliminates the creation of proxy or clerk-type product owners. And welcomes the teams to work with many different experts and keep learning from them. Focus & Accountability: Good focus and a strong feeling of ownership in teams are still possible, even if they work broadly on the whole product together. This can be achieved by applying practices of Continuous Integration , Mob Programming , multi-team work sessions, and other means of inter-team decentralized coordination . Learning & Specialization: Specialization is great. And learning to work broadly on a product by delivering customer value is great, too! These goals are not mutually exclusive. There is no false dichotomy, as we need them both. The LeSS-inspired org design allows the teams to pull items that they are capable of doing (utilizing their existing skills) as well as working with other teams on new things (acquiring new skills). As is seen in the next illustration of a flow scan of Poster after the change, tight multi-function collaboration and the presence of feature teams contributed positively to shortening lead times for features. A big change for the developers was expanding the Definition of Done to include non-development activities like customer onboarding. Now, a feature is seen as done only after the first customer(s) use it. That created a powerful feedback loop for the teams and affected the way they design, work on, and deploy the features. Weekly collaborative requirement refinement sessions became a collaboration opportunity for all the stakeholders and the experts: customers, product managers, designers, representatives of the support department, client onboarding, and engineering managers gathered with the feature teams. That accelerated the processes of forming requirements. And importantly, it has ensured a much better shared understanding of what is expected to be done. This process contributed to minimizing lead times for features not only by reducing waiting for specifications but also due to minimized rework because of improved alignment. Note how the collaboration style of many groups has switched to facilitating, supporting the work of the heart of the new org design -- the feature teams. Conclusions The LeSS adoption at Poster and its detailed org scans can be illustrated as an org topologies mapping provided below. The initial mix of task-focused woek (TASKS-2) , and capabilities-focused teams (CAPS-2)  was mainly converted to an organization practicing holistic product development, with teams operating at whole solution focus (WHOLE-4)  and optimizing for adaptivity in learning and delivery. Observed Adaptability and Resilience Since the end of summer 2021, Poster and its feature teams have been operating in this new mode. They went through and recovered from the Covid-19 lockdowns. Now, as of writing this case study in winter 2023, they have spent almost 300 days serving their impressive B2B customer base during the wartime in Ukraine. They even managed to grow their clientele, a real sign of high resilience! Business resilience comes from high organizational adaptability. And high adaptability comes from an org design that enables and nurtures it. Therefore, org design is an essential skill to be mastered by management. © Written by Alexey Krivitsky and published with permission from Poster POS Inc. This experience report presents a personal view on the change story by the credited writer. Should you have alternative views or additional details about this particular company's change story, please do not hesitate to contact Org Topologies and submit your version for publishing.

Craig crafted a powerful algorithm that helps address such conflicts in optimizing goals and teaming up with people like Bob. Everyone who had a chance learning from Craig in his classes on system thinking in org design—Certified LeSS Practitioner—knows this well. Let’s assume the organization’s primary goal has been set: to become more customer-centric. There is Bob. He supports customer centricity in theory . When the change starts to touch his  team, though, he pushes back. “If we let developers talk to customers,” Bob might say, “That wouldn’t be efficient . If we let developers spend time with customers, they’ll lose precious development time.” Our first instinct is to fight and prove we are right and he is wrong. But that will only turn up emotions and, in the worst case, turn Bob from a vocal proponent to a silent saboteur. That would undermine the whole change process. We need to act with compassion and wisdom.

For decades, we have rewarded deep specialization . A radiologist reads scans. A frontend developer writes UI code. A paralegal prepares contracts. These roles were seen as focused, professional, and trustworthy. We encouraged our kids to get an education that makes them experts—the go-to person for one well-defined kind of work. The times are changing. In the environments shaped by rapid change and growing uncertainty, success depends on more than executing well-learned domain and well-practiced tasks. Professionals are increasingly expected to learn as they go, apply knowledge in unfamiliar contexts, and respond when standard solutions no longer fit. This is new in practice for most of us, but the theoretical distinction is not. In the 1980s, cognitive researchers Giyoo Hatano and Kayoko Inagaki introduced a useful concept to describe this phenomenon: routine expertise  versus adaptive expertise . Routine  expertise is the ability to perform known tasks efficiently and accurately by applying established procedures. Routine experts excel in stable conditions. They produce reliable, high-quality outcomes—as long as the situation remains familiar. Adaptive  expertise goes further. Adaptive experts can extend, recombine, or reinvent their skills when conditions change. They handle novelty without freezing. They learn while acting. The COVID-19 pandemic made this distinction painfully visible. Health professions educators around the world were forced to abandon standard training models almost overnight. One post-pandemic study showed that adaptive expertise did not correlate with age or years of experience. Instead, it emerged as a distinct capability that had to be deliberately developed. Those scoring higher in adaptive expertise also performed better during periods of disruption, while seniority alone offered little protection from disruption. As it turns out, work experience does not automatically result in adaptive expertise. Adaptive expertise is a different kind of mastery—one built through continuous learning, exposure to variation, and the embrace of new challenges. In other words: purposefully and with broader mandates. After the pandemic, the professionals who had demonstrated their surprising adaptive expertise were able to return to business as usual. But are there domains where such behavior is not a crisis response, but the daily norm?

Most organizations respond to rising expectations by copying what worked elsewhere. That reflex is understandable, but it rarely creates an advantage. In an era of soaring expectations, “copying Spotify” won’t move the needle. Lasting advantage has always come from a different place: learning and experimenting as a strategic capability. And now, in these turbulent and promising times of accelerating AI progress, the organizations that institutionalize experimentation will win. Sustained performance results from systemic change. The 10X Org principles provide that system. They are not tactics or best practices to be cherry-picked, but a coherent design logic for organizations that can learn, adapt, and perform at 10X scale. Each principle builds on the previous ones—moving from ownership and intent, through structural choices and learning loops, toward sustained human and organizational capability in the age of AI. Principle 1: Own, Not Rent, is the backbone .  Sustainable organizational improvement does not survive as a borrowed idea. It endures only when the organization truly owns the change. Ownership means that someone is accountable for understanding what is happening, choosing a direction, and continuously energizing others to co-own and improve the system.

While developing the Org Topologies change method and writing the  #10XORG book , we have come up with the concept of Elevating Katas . The term kata comes from martial arts, where it describes a practiced sequence used to build skill and judgment through repetition. In Org Topologies, Elevating Katas serve the same purpose: they provide a practical way to evolve an organization deliberately, without relying on one-off transformations or wholesale reorganizations. The 10X Org principles set direction. They clarify what matters and what trade-offs are being made. The Katas make that direction actionable. Rather than prescribing best practices, Katas create safe, repeatable ways to reshape structure, mandates, roles, processes, and incentives—while learning from real work. This catalog of katas is now tightly integrated with the upcoming book chapters. Learn more about Elevating Katas, see the full and growing catalog, and see them being applied in case studies.

I recently co-authored a case study about our journey at Strobbo over the past few years: ‘Strobbo Adopts Professional Scrum to Accelerate Go-to-Market’ . Alongside my colleague Bert Neels , our agile coach Steven Deneir , and the fantastic team at Scrum.org , we delve into the challenges we faced and how we overcame them over 12 to 18 months. And believe me, it wasn’t always smooth sailing! Even after contributing to the document and recording a podcast about it, I still feel like there is more to share about our story. In this document, I aim to explore our journey through the lens of organizational design using Org Topologies. This approach provides a structured map to navigating the complexities of teamwork and organizational structure. How did we reconfigure our team  dynamics? What organizational structures helped us thrive? It’s like assembling a detailed jigsaw puzzle where every piece is crucial.  Background on Strobbo Strobbo is an HR platform that automates the administration of flexible workers. It offers an all-in-one solution for managing availability, staff scheduling, time tracking, Dimonas (social security declarations in Belgium), contracts, and monthly payments across various sectors, including hospitality, retail, and the funeral industry. Strobbo integrates with existing tools like cash register systems, enabling quick analysis of turnover and staff costs through its reporting module. The platform also connects with reservation systems and weather forecasts to optimize staff scheduling and links with payroll systems for seamless payroll processing. Founded as "Onlinewerkrooster" in 2016 in Lommel, Belgium, by Nick and Bert, who identified a need for flexible staff scheduling in the hospitality sector, Strobbo addressed issues related to the white cash register system aimed at preventing tax evasion. By 2018, it had a team of 9, serving 500 businesses, and was acquired by Protime, a European workforce management specialist, to accelerate international growth. Rebranded as Strobbo in 2020, the company expanded internationally, supported by a growing team. Today, over 2,000 businesses in Belgium and beyond rely on Strobbo for automating personnel administration. Introduction to Org Topologies Since we will be using Org Topologies to analyze our organizational design, I will first introduce some of the basics. What follows below is just the bare minimum to understand the rest of this chapter. For a more detailed introduction, I can recommend reading the Org Topologies Primer . The Org Topologies map contains a set of recognizable archetypes, each with their own characteristics. In earlier versions these were labeled with letters and numbers; in the current version, the emphasis is on understanding mandates  and the kind of organizational intelligence  the design enables. The Horizontal Axis The horizontal axis of the Org Topologies map represents the Scope of Skills Mandate  of a unit in your organization. The more an organizational unit moves to the right, the broader the range of skills it is mandated to apply, and the faster it can deliver value with less dependency on asynchronous hand-offs. We distinguish 5 different types of org units:  Functional units contain people with similar skills who typically perform the same function. This is often not yet a team as everyone is working on their own tasks. Multi-skill unit(s) or cross-functional team(s) that can tackle more complex work. There are still dependencies on other organizational units to complete their work. End-to-end unit(s) that can deliver end-to-end value without being held back by asynchronous dependencies. Expanding units can continue to learn to remain end-to-end capable over time when new technology emerges. Unbouned contains org units that are free to learn without limitation. The Vertical Axis The vertical axis indicates the Scope of Work Mandate  in which the organizational units collaborate and share work. The higher you move up the axis, the closer the unit is to the customer and the more it will be able to deliver customer solutions: Task focus : the unit receives tasks to work on. Capabilities focus : the unit receives work as capabilities that need to be built. Partial solution focus : units focus on a partial solution area and might work for goals within that partial solution scope (for example a sub-product, a business area, or a bounded segment of the customer domain). Whole solution focus : units can work on customer and business problems throughout the entire customer domain and are not tied to any partial solution or sub-product. Unbounded : units operate beyond fixed solution boundaries, dynamically shaping work based on learning and strategic needs. Below you find the full 4x4 map used in detailed org design work. It would take me too far to go into detail of each archetype now, but I will explain those in context of the teams later. However, it is worth mentioning here the position on the map where units are both complete in skills mandate and broad in work mandate (whole solution focus, and in some cases even unbounded). As an example, the authors of Org Topologies refer to startups being in that space, as in this case, the founders are typically very close to the customer and either have the necessary skills or are forced to learn them (mostly because there is no money to hire someone to do the job). As a business grows, you will get lower archetypes, and it requires more and more effort to get back to that state (if it is even possible). Scaling Issues and Mechanical Scrum Our story starts somewhere roughly two years ago. As Strobbo's team had expanded over time we had already restructured into multiple smaller teams to maintain agility and efficiency. This restructuring involved creating three development teams with a multi-skill mandate  and a capabilities-focused work mandate , and a second-line support team with a task-focused work mandate . The second-line support team would handle more complex support issues and maintenance for our older technology stack, thus allowing the new development teams to concentrate on the newer technology stack and developing new features. Despite these efforts, we faced significant challenges, including frequent bugs, performance issues, and a lack of maturity within the team. We brought in external experts operating with a very narrow, TASKS-1 mandate  to help improve code structure, implement solutions for better quality and performance, and provide training for the existing teams. However, several key issues persisted: Mechanical Scrum : Teams were going through the motions without fully understanding Scrum principles. Overplanning and Lack of Autonomy : Heavy reliance on the Product Owner led to disengagement. Lack of Trust and Fear of Speaking Up : Trust issues and fear of speaking up resulted in low motivation and commitment. Poor Communication : Meetings were passive and disengaged, leading to individualistic work. Tactical vs. Goal-Oriented : High pressure from management and pessimism undermined efforts. Lack of Transparency : Poor transparency and communication led to a lack of shared understanding. The issues faced by Strobbo indicated that while the teams were designed to operate as cross-functional teams, they were still struggling to embody the characteristics of effective teams with those mandates. Lacking a visual depiction of Org Topologies, we missed the crucial insight that Strobbo's teams were in a transitional stage—aiming to operate as cross-functional teams—but facing significant hurdles that kept them closer to task-focused and functionally siloed behavior. Some specific examples of behaviors inside the teams that kept us back were: A large focus on ‘resource’ efficiency , with team members being very focused on keeping busy individually.  Breaking down work to fit the skills of one team member , resulting in frequent hand-offs between single-skilled individuals. Inside the teams people were falling back to task-focused behavior and were not working as a team but also overly focused on tasks. Some team members compensated by keeping the overall picture and breaking down the work. Mapping of the dynamics inside the team. On the other hand there were also still several dependencies between the teams and the product owner and the teams and the external experts that were holding them back: Relying on testing and acceptance by the Product Owner , which caused frequent delays. Contract thinking at task level when feedback was given. e.g. there were frequent discussions about something being in the acceptance criteria (or not) and no focus on the overall goal. Teams did not trust their own skills to make architectural changes and relied heavily on external experts to do the work, causing more hand-offs and delays. Dependency on the second-line support team to release features dependent on our legacy software. While some of these dependencies were to be expected (e.g., dependencies on the legacy software) for the foreseeable future, reliance on both the Product Owner and the external experts was something we actually wanted to avoid. The teams were, however, lacking in certain skills to be able to avoid this. These challenges, combined with legacy issues in both the old and new tech stacks, further complicated their transition to stronger cross-functional and more independent behavior. A visual Org Topologies map would have highlighted these discrepancies, allowing us to address them more effectively and guide the teams toward the desired position on the map. Implementing Lean Improvement Kata Recognizing these challenges, we initiated a coaching track with Steven Deneir , utilizing a Lean Improvement Kata  on a weekly basis to enhance our work processes. This approach aimed to systematically address our issues and guide us towards more effective team dynamics. We set forth these goals for ourselves: Make the team independent - stop them from looking to Bert (co-owner of the company) and Michael (Product Owner) for the smallest decisions, clarifications, etc. Make sure the team understands that everything can be discussed and changed. Make sure the team is proud of their work and boost morale. Make Strobbo a showcase within our parent company Protime as a good example of what it means to be a team and what they delivered. Prepare the team for further growth (uplift the technical skill level). No longer practice Scrum mechanically and half-heartedly. Looking at these goals through the lens of Org Topologies, we aimed to enhance the team's technical skills, moving their position to the right on the map. Simultaneously, making the teams less dependent on the product owner required them to move up on the map. Speaking in terms of mandates, we knew that we wanted to expand beyond a capability focus toward a partial solution focus  with our teams, and focus on achieving business agility. Achieving full adoption of the CAPS-2 Archetype But as we saw in the previous section our teams were still struggling to fully adopt the intended position on the map. Our Lean Improvement Kata resulted in a bunch of positive improvements, which really helped elevate the teams to more stable cross-functional, capability-focused behavior and further. With the coaching we received, step by step we were able to make progress. Many of these are also proposed as Elevating Katas™  within Org Topologies. Sprint Goals and Transparency : Sprint Goals : Introduced clear Sprint Goals to guide the team's efforts, ensuring alignment and focus on delivering value. Stakeholder Involvement : Invited stakeholders to Sprint Reviews, transforming them into collaborative sessions that provided valuable feedback and boosted team morale. On-Site Reviews : Moved from online to on-site Sprint Reviews, which significantly improved interactions and engagement with stakeholders, including senior management. Product Backlog Refinement : Involved team members in refinement sessions using Impact Mapping, Event Storming, and User Story Mapping. Team Cross-Functionality, Self-Management, and Definition of Done (DoD) : Encouraged collaboration between front-end and back-end developers. Implemented Mob development and pair programming for knowledge sharing and tackling complex issues. Focused on End-to-End Testing, balancing technical and functional responsibilities. Ran a defect matrix workshop to aid in self-management and decision-making. Conducted workshops to define and clarify the DoD . Made UnDone work transparent , creating a clear path to getting items into production. These structures and practices collectively enhanced team autonomy, transparency, and alignment, driving significant improvements in Strobbo’s agile adoption. Transitioning from Capabilities to Partial Solution Focus But as we said our vision was to enhance our team's capabilities and autonomy. Initially operating with a capabilities-focused work mandate, we sought to transition toward a partial solution-focused work mandate within the Org Topologies framework. Our vision went further than simply improving processes; it entailed a fundamental shift towards greater business agility and independence. After fully realizing the CAPS-level position, the teams were working effectively, but there was still a significant amount of coordination required from the Product Owner. Additionally, we wanted to close the gap with the customer to ensure better alignment and responsiveness to their needs. This is also the point that we learned about Org Topologies and understood that we needed to spend more time with the team to help them better understand the direction that Bert and I were moving the teams toward. In a team exercise, we started with showing the video  ‘How Misconceptions About the Product Owner Role Harm Your Organization and What To Do About It’  to not only better explain the role of the product owner but also to make the point that they can take ownership themselves. We then let the team put themselves on the map , and had a group discussion about what we are currently lacking. To further elevate the teams at this point, we invested heavily in the following Elevating Katas, building on our previous efforts: Product Roadmap and Ownership : Goal-Oriented Backlog : Transitioned from a feature backlog to a goal-oriented backlog, focusing on metrics such as the number of pilot customers live, feature usage, or deals sold. The emphasis shifted from merely completing features to ensuring their adoption and impact on the company. Roadmap Workshops : Organized workshops with internal stakeholders and developers to align on the product vision and co-create the roadmap. Enhanced Collaboration : Fostered collaboration to reduce reliance on the Product Owner for day-to-day operations. Product Backlog Refinement : User Story Mapping : Utilized techniques like User Story Mapping to create valuable increments towards achieving goals, ensuring value delivery each sprint. Flexible Scope : Instead of detailed estimates, we set goals and placed bets on achieving them within a certain number of sprints. This approach acknowledges uncertainty and allows flexibility in adjusting the scope based on the situation, focusing on the impact rather than features. Sprint Planning : Limited WIP : Leveraged our goal-oriented backlog by limiting work in progress (WIP) and, in some cases, having teams focus on a single goal at a time. Sprint Goals : Centered sprint goals around the next best step for the current goals. A significant consequence of these changes was the evolution of the Product Owner role to be more outward-facing, focusing on stakeholder and customer engagement. This shift also created greater transparency on the roadmap and backlog for both development and business. At this point on the map you can also notice a big difference in the interaction between the teams. Task-focused and capabilities-focused units require external coordination at the team level. With a partial solution-focused work mandate we see the dynamics change to a ‘Team of Teams’ where teams will organize themselves. Instead of coordinating at the team level you now coordinate the ‘Team of Teams’. This also changes a lot of the dynamics regarding ownership as capabilities-focused teams will be more likely to focus hard on their own parts and use it as ‘cover’, whereas a partial solution-focused ‘Team of teams’ will start self-organizing based on the work they receive. There can still be ownership, but it is no longer a problem of the external managers to figure this out for the teams. Part of expanding toward partial solution focus involved less reliance on external expertise, which is why the ‘external experts’ are gone from the map. Collaborating with Protime Strobbo (formerly Onlinewerkrooster) was acquired by Protime in 2018. The timeline discussed previously occurs after this acquisition. While Strobbo remains a distinct brand and product within Protime, alongside their other workforce management solutions, we operate mostly autonomously as a product group. This autonomy allows us to make decisions regarding our product and technology independently. However, we don't operate in isolation. Over time, we've made significant progress in integrating the Protime and Strobbo product groups, fostering closer collaboration. This integration highlights the importance of addressing how we fit within the larger company and how it influences our position on the organizational map. Portfolio management Until now, I have limited the scope to our product development part of Protime. However, the recent creation of a Portfolio Manager role has shifted the position of the Product Owner. From this larger perspective, it becomes clear that the product owner now lacks a ‘whole solution focus’ and is concentrating only on a specific part. This change adds an extra layer of coordination and alignment that was previously not there. The impact on the teams is limited, but as the Product Owner might not have the whole picture anymore (depending on how transparent the Portfolio Manager is), we risk them making wrong decisions or losing time on additional alignment. We should realize that when work moves from portfolio to product and then to development, it is not a sequential flow. As we learn more, work might move back from development to portfolio. If this requires a lot of coordination, it can slow us down in terms of delivery and innovation. Planning Domain Following the acquisition, the Strobbo team gradually became responsible for the entire planning domain within Protime. Strobbo continues to exist as a standalone product, but two additional teams have been added to integrate Strobbo and another recent acquisition ( Sheepblue ) into myProtime, Protime's main product. This integration effort aims to streamline functionalities and enhance the overall user experience within the Protime ecosystem.  This integration necessitates adapting our organizational map to fit the larger context. In Protime, the Product Owner (PO) role is different, responsible for assisting multiple teams with feature development but not acting as a true Product Owner. Instead, product ownership is handled by the Product Manager. This shift demonstrates the clear benefit of using an Org Topologies map over a framework-based organizational design. Even though the titles change, the position on the map remains consistent. The newly added teams comprise developers from both the Strobbo and Protime development teams. The Planning domain fully encompasses Strobbo as a product, with all its features, and includes Planning as a feature of myProtime. For the teams working on myProtime planning, the scope of work is therefore narrower than for those working on Strobbo. This narrower scope limits the ability of the myProtime planning teams to cross the chasm as the Strobbo teams did. Work beyond their scope must be picked up by other teams, requiring coordination at the 'product' level between the PART-level archetypes. Conclusion Reflecting on Strobbo's journey, it is evident that our path to agile excellence was marked by both significant challenges and transformative successes. Initially, moving from a single-team scrum setup to multiple, more specialized teams did not immediately resolve our deep-seated issues related to agility, autonomy, and cross-functionality. However, over time, through persistent effort and continuous improvement, we were able to achieve these outcomes. Key to this transformation was the introduction of clear Sprint Goals, stakeholder involvement, and regular on-site reviews, all of which enhanced transparency and team morale. Although we did not initially use Org Topologies, in hindsight, it would have provided a critical framework for understanding and addressing the complexities of our organizational structure. This approach could have highlighted the foundational issues sooner, guiding us more effectively through our transitions. Our integration into Protime further underscored the importance of aligning our product and technology strategies with broader organizational goals. By adopting a goal-oriented backlog, fostering collaboration, and maintaining a flexible scope, we ensured that our teams remained focused on delivering impactful solutions. As we continue to evolve, the lessons learned from our agile practices will guide us toward sustained growth and innovation within the larger Protime ecosystem. This experience report presents a personal view on the change story by the credited writer. Should you have alternative views or additional details about this particular company's change story, please do not hesitate to contact Org Topologies and submit your version for publishing. Elevating Katas (addition of December 2024 by Alexey Krivitsky): This article by Michael provides great examples of what we now call Elevating Katas . Elevating Katas are introduced as repeatable, structured patterns or routines introduced into an organization’s ways of working that help teams and leaders build new capabilities, improve system-level performance, and “elevate” their overall approach to value delivery. Elevating Katas Identified in the Strobbo's Case Study: Unifying Product Ownership Moving from individual team-based product owners to a more unified product ownership structure. This elevates product strategy and ensures that the product vision is collectively understood, prioritized, and managed. Instead of each team interpreting the product direction in isolation, a unified product ownership model helps maintain strategic coherence and alignment across the entire product landscape. Merging Product Backlogs Instead of multiple, disconnected backlogs, the organization merges them into a single, shared backlog. This structure forces transparency, reduces competing priorities, and keeps all teams focused on the same highest-value opportunities. Similar to the “Merge Product Backlogs” kata, this elevates the entire organization’s workflow by ensuring that work items are consistently prioritized at a product (rather than team) level. Holding Multi-Team Product Backlog Refinement Establishing regular, multi-team product backlog refinement events. During these sessions, all involved teams align their understanding of upcoming work, dependencies, and priorities. This structure ensures that each increment of work is clearly understood and synchronized, preventing silos and misalignments before development starts. Using Obeya for Org Topology Evolution While not explicitly called “Obeya,” the case study implies the use of dedicated forums or physical/virtual spaces where stakeholders (including product owners, coaches, and team representatives) gather to review strategic metrics, progress indicators, and customer feedback. This structure leads to better-informed decisions and quicker action. Over time, these regular strategic gatherings elevate governance and leadership practices. Designing Tailwind Career Paths Encouraging roles to evolve beyond traditional job titles or hierarchical tracks into more fluid, capability-driven pathways. Instead of fixed roles defined by narrow functions, individuals grow in breadth and depth of skill areas aligned with organizational goals. This provides a structure that consistently nudges people towards multi-skilled growth and adaptability. More on Elevating Katas here .

An Org Topologies™ MADE Report 1. Introduction & Engagement Context This paper applies the Org Topologies™ MADE method to analyze and elevate the organizational design of a past engagement in which I served as Scrum Master. The organization, anonymized for confidentiality, is a prominent entity within the automotive sector that created a decentralized data marketplace enabling secure data exchange and data monetization across ecosystem partners. The organization consisted of approximately 20 people, a size well suited for focused, systemic assessment and for exploring alternative org design options without the complexity of large-scale systems. One of the reasons I selected this case is that the organization operated with a high degree of autonomy: leadership empowered the team to propose and experiment with organizational changes. This makes it an excellent context to reflect on org design through the lens of Org Topologies™, even though the engagement occurred before I learned the method. Org Topologies™ is applied retroactively in this paper to map the current (past) ecosystem. assess the structural challenges, design a fit-for-purpose target state, and propose Elevating Katas™ that would guide the organization toward higher adaptability and improved value flow. 2. Business Landscape The organization operates in the automotive sector but is positioned within an emerging digital ecosystem centered around data exchange. Its core business model is built on providing a decentralized data marketplace that enables security, privacy-preserving, and compliant data transactions. Leveraging blockchain technology, the platform ensures transparency, traceability, and trust among participating organizations. 2.1 Strategic Objectives • Establish itself as a premier platform for secure and compliant data exchange. • Drive innovation by enabling access to diverse, high-value datasets. • Scale through a SaaS model to increase adoption and reach. • Support businesses in effectively monetizing their data assets. 2.2 Maturity Stage At the time of the engagement, the platform was in a growth stage, expanding capabilities, user base, and technological robustness. 3. Current Ecosystem (MAP) initial state This section describes the ecosystem during the engagement, following Org Topologies™ mapping practices. 3.1 Existing Organizational Design Functional groups included: General Manager, Marketing, Business Development, Customer Success, Product Management, Engineering Team, Infrastructure Team and Design Team. 3.2 Value Flow (Concept to Cash) Work flowed sequentially across units: Customer Success + Business + Product → Design → Engineering → Infra → Release → Customer Success. 3.3 Lists, Backlogs, and Queues • Product Backlog (including Bugs and Spike) • Sprint Backlog • Design Kanban • Infra Kanban • Release Notes • Marketing Requests 3.4 Org Topologies™ Mapping The mapping showed heavy clustering in CAPS-1 and CAPS-2 archetypes, with PART- 1/PART-2 for leadership and Product. No TASKS-3/TASKS-4 or WHOLE-level archetypes existed. 3.5 Key Observations • High dependency network. • Fragmented Work Mandate. • Centralized decisions around Product. • No end-to-end ownership. 4. Assessment (ASSESS) 4.1 Market for data sharing conditions The market for data sharing and data marketplaces is experiencing significant growth and is shaped by several critical factors: •  Escalating Privacy and Compliance Concerns : Legitimate and widespread privacy concerns, coupled with constantly evolving regulatory requirements (e.g., GDPR, CCPA), make secure and compliant data sharing a complex endeavor. •  Growth of Data Marketplace Platforms : The global data marketplace platform market is projected to grow significantly, from an estimated USD 1.49 billion in 2024 to USD 5.73 billion by 2030, with a CAGR of 25.2%. 4.2 Business Strategy •  Promoting Secure and Compliant Data Sharing : To overcome common data challenges like privacy and security by offering a Web3-powered solution with cutting-edge data security and privacy features. •  Simplifying Enterprise Collaboration : To streamline organization-wide data transactions and foster collaboration across diverse industries and ecosystems. •  Enabling Data Monetization : To facilitate the buying, selling, and monetization of data over the blockchain in a transparent and secure manner, creating new revenue streams for data providers. •  Ensuring Data Sovereignty and Governance : To decentralize data transactions, implement robust role-based governance, and enhance overall data efficiency while ensuring data owners retain control. 4.3 Compared to general competitors •  Traditional Centralized Data Marketplaces (e.g., Snowflake, AWS Data Exchange, Oracle Marketplace): These platforms typically operate with a centralized model, often requiring data to be moved to a single location, which can present privacy and control challenges. This decentralized data marketplace solution's decentralized nature and privacy-preserving computations offer a distinct alternative. •  Other Decentralized Data Marketplaces/Protocols : While this solution is built on existing open source protocol, it stands out as an enterprise-specific, white-label solution with significant corporate backing, differentiating it from more general- purpose decentralized data protocols or smaller projects in the space. 4.5 Summary of Structural Constraints Overall, the ecosystem expressed a classic Resource Topology , this topology does not fit the organization goal because: • The organization operates in a growth-stage digital platform context that requires fast learning cycles and rapid adaptation, while a Resource Topology optimizes for resource efficiency rather than learning and flow. • Narrow Skills Mandate and Work Mandate prevent teams from delivering outcomes end-to-end, increasing dependency chains and slowing value delivery. • Strong functional silos introduce excessive handoffs, coordination overhead, and information loss. • Central coordination around a single Product Owner creates a systemic bottleneck, limiting scalability and decision speed. • Fragmented queues and multiple backlogs delay customer feedback from reaching delivery teams, reducing responsiveness. • Slow Onboarding of New Customers, Fragmented ownership increased onboarding delays, especially if customers need a customize features. 5. Organizational Goal & Fit-for-Purpose Logic (BUSINESS OBJECTIVES) he organization aimed to: - Shorten customer onboarding time, Shorten time-to-market and Reduce the Product Owner bottleneck. The organization selected a fit-for-purpose goal of enabling at least one PART-3 value- stream team to own customer onboarding end-to-end within the next 3–6 months. The other two of the prioritize goals are: • Shorten time-to-market. • Reduce the Product Owner bottleneck. 5.1 Fit-for-Purpose Logic Achieving these goals requires: • End-to-end ownership. • Fewer handoffs. • Broader Skills and Work Mandates. • Distributed refinement. • Cross-functional collaboration. Target ecosystem moves toward PART-2 / PART-3 archetypes with value-stream ownership, representing a shift from a Resource Topology toward an Adaptive Topology . The MAP revealed a narrow Scope of Skills Mandate and Scope of Work Mandate, which kept the organization in CAPS behavior, making the move toward PART-3 essential. 6. Target Org (DESIGN) The following section describes a retrospective target design. It explains how the MADE method and Org Topologies™ could have been applied during the engagement to design a more fit-for-purpose organization. The design represents a plausible outcome of applying MADE, not a historical implementation. 6.1 Target Design Summary Based on the outcomes of the workshop, the organization agreed to reorganize around feature-based team-of-teams , structured by customer value rather than functional specialization. The primary feature streams identified were: • Onboarding Experience • Buying Experience • Selling Experience Each team-of-teams includes: • 1 Product Manager • 1 Product Owner • 1 Designer These teams are supported by shared roles: • Scrum Master • Solution Architect • Business • Customer Success • Infrastructure This target design represents a deliberate movement away from CAPS-1 / CAPS-2 functional clusters toward PART-3 behavior, forming the foundation of an Adaptive Topology by expanding both Scope of Skills Mandate and Scope of Work Mandate. anticipated future state The design intentionally organizes around features and customer journeys rather than functions. The assessment revealed that functional silos, central coordination, and fragmented queues were the primary causes of slow delivery, product bottlenecks, and delayed customer feedback. Key design rationales include: •  Value is delivered through features, not functions . Structuring teams around onboarding, buying, and selling aligns organizational structure with how customers experience value. •  Reduction of Product Owner bottlenecks by embedding Product, Design, and delivery capabilities within each feature team-of-teams. •  Absorbing growth-stage complexity locally , allowing teams to respond to increasing demand, regulatory input, and customer diversity without escalating coordination overhead. •  Scalable design through replication , enabling growth by adding new feature teams rather than increasing central coordination. 6.2 Why This Design Is More Adaptive This target design enables adaptive behavior by changing how decisions are made, how learning occurs, and how work flows through the organization: •  Shorter feedback loops by reducing handoffs between discovery, delivery, and customer interaction. •  Broader local decision-making through PART-3 Work Mandate, allowing teams to prioritize and adapt without centralized approval. •  Lower coordination cost , as most alignment happens within the team-of-teams instead of across functional units. •  Increased learning capacity through direct customer interaction by engineers and designers. •  Fit-for-uncertainty , allowing teams to evolve solutions incrementally in response to market and customer change. In Org Topologies™ terms, the organization shifts optimization from resource utilization to flow, learning, and outcomes, which defines an Adaptive Topology. 6.3 What Is Required to Move Toward End-to-End (Partial) Ownership The target state deliberately aims for end-to-end partial ownership (PART-3) rather than immediate WHOLE ownership. This represents a realistic and sustainable evolution path. Product Manager / Product Owner • Shift from centralized control to shared ownership • Focus on outcome framing and strategic alignment • Enable collaborative prioritization and refinement Engineering • Expand Skills Mandate to include customer understanding • Participate in discovery and refinement Design • Move from a service role to an embedded team member • Collaborate continuously with Product and Engineering • Own user experience outcomes end-to-end Customer Success • Transition from reactive support to proactive co-ownership of customer journeys • Work directly with feature teams to close feedback loops Business • Provide strategic input rather than detailed prescriptions Infrastructure • Serve feature teams rather than operating as a downstream queue • Enable autonomy through platform and tooling Scrum Master / Solution Architect • Focus on flow, alignment, and systemic impediments • Facilitate collaboration across team-of-teams with customer • Support learning 7. Elevation Path (ELEVATE) A set of Elevating Katas™ to move toward the target ecosystem. 7.1 Create Feature-Based Team-of-Teams Establish PART-3 behavior with end-to-end ownership. 7.2 Simplify Lists & Flow Transparency A common shared backlog could be introduced across each feature-based team-of- team. Instead of separate backlogs for Product, Design, Engineering, and Infrastructure, each value stream will work from one unified backlog that contains discovery work, design work, refinement work, delivery work, and release-related tasks. This shared backlog becomes the single source of truth for: •  Prioritization , guided by customer outcomes, onboarding friction, and feature impact. All units could jointly assess value and urgency, which will help to reduce Product Owner bottleneck. Decisions can be made more efficiently, resulting in improved alignment. •  Refinement , Instead of being solely the Product Owner’s responsibility, this could become a cross-functional activity. Teams would build a shared understanding, beyond just creating documentation in JIRA, which leads to better-quality backlog items and a more seamless delivery process. •  Dependencies , It is recommended to make dependencies explicit and visible within the shared backlog, rather than keeping them hidden across functional queues. For example, teams should consider implementing buying-related features before developing sales-related functionalities like a sales dashboard, since the dashboard’s completion relies on the availability of corresponding sales data. •  Customer feedback could be treated as first-hand backlog, not as input filtered through multiple layers. •  Customer Onboarding improvements , It is recommended that onboarding work be elevated from a side initiative to a central component of feature delivery. By prioritizing aspects such as self-deployment, organization setup, and configuration alongside new features, teams could begin to view onboarding as an integral part of their end-to-end responsibilities. This shift would help ensure smoother onboarding experiences and reinforce holistic ownership of the product lifecycle. By consolidating work into one backlog per team-of-team, the organization reduces fragmentation, removes queue-based delays, and strengthens PART-3 end-to-end ownership. Consolidate into single backlog per value stream. 7.3 Expand Work Mandate to End-to-End Move teams from CAPS toward PART-level outcomes. 7.4 Customer-Facing Discovery for Engineers & Designers Faster feedback loops, reduced PO bottleneck. 7.5 Shared Refinement & Distributed Product Thinking Cross-functional refinement increases alignment and quality. 7.6 Empower Teams to Deliver Self-Onboarding Feature A strategic, end-to-end initiative as the first major ownership slice. 7.7 Enable Scalable Growth Scale by role replication within value streams, not functional silos. 8. Conclusion & Practitioner Reflection Applying Org Topologies™ revealed structural issues invisible through Scrum alone. 8.1 Key Learnings • The MAP exposed dependencies, especially the Product Owner bottleneck that Scrum ceremonies do not reveal. • The MAP highlighted slow time-to-market caused by multi-step feedback loops. • It created shared awareness of bottlenecks and aligned teams on next goals. • It revealed that most units were not delivering end-to-end, prompting new conversations on autonomy and empowerment. 8.2 Final Reflection The MADE approach shifted the organization’s perspective from local optimizations to system-level understanding. It demonstrated how structural constraints, not individual performance, were limiting flow, adaptability, and customer outcomes. Org Topologies™ provided the language, visuals, and pathways needed to evolve the organization toward a more scalable, collaborative, and outcome-driven ecosystem.

A story of how a Ukrainian PropTech company redesigned its structure, embraced LeSS principles and built adaptability and resilience amid the challenges of full-scale war. About the Company DIM.RIA is one of the leading Ukrainian PropTech platforms and part of the RIA.com Group, one of the country’s largest digital ecosystems. The product is a real estate marketplace that connects buyers, sellers and agents across both residential and commercial segments. The company’s core value is trust through verified information – its mission is to provide users with only verified, reliable listings, ensuring transparency and confidence in every transaction. Beyond listings, DIM.RIA offers verified property data, valuation tools and digital services that help users make informed decisions. Over the years, it has become one of the most trusted and widely used sources for property search and transactions in Ukraine. At the beginning of 2022, when Russia launched a full-scale invasion of Ukraine, the real estate market faced turbulence. Demand and construction volumes dropped sharply, with many projects suspended or lost due to hostilities. Companies in the sector had to adapt quickly, rethink their business models and stabilize operations amid constant uncertainty and shifting market dynamics. Our organizational transformation took place entirely remotely – online. Because of safety concerns, blackouts and the realities of war, our people were spread across Ukraine and even beyond its borders. Yet, despite the distance and challenges, the teams managed to stay connected, collaborate effectively and drive deep structural change together. This transformation became a living example of how people can unite and overcome extraordinary challenges, even when dispersed across different parts of the world and successfully carry out something as complex as an organizational transformation. Acknowledgements I want to express my deep gratitude to the entire team for believing in this change. You are amazing! Special thanks to Roman Marchenko (Chief Product Officer, Board Member) and Oleksandr Lishchynskyy (Chief Technical Officer, Board Member) for the trust and engagement.   Introduction In the summer of 2024, I joined the team DIM.RIA. At the time, the company employed over 100 people, with approximately 50 working within the product organization. The product team was actively searching for organizational solutions. The main question was: How should we organize our work to achieve better results? The organizational structure had been adjusted multiple times, often in response to shifting definitions of the product. In earlier periods, management had attempted to implement selected elements of the Scrum framework, hoping this would improve team efficiency. As I later heard from team members, they had experienced so many transformations that they joked they could survive one more. But I felt the teams’ fatigue after these words. Because these changes lacked clear direction, addressed only short-term problems and focused on local optimization. Studying the Organization I began exploring the organization by asking management a simple but fundamental question:   “Why does your structure look like this?” The team was divided into three main areas: Sellers, Buyers and Core functionality. ●      The Buyers stream focused on users and product features aimed at people searching for real estate. ●      The Sellers stream, in turn, worked on tools and features for those listing properties. ●      The Core team developed functionality for internal users, such as moderators and internal departments, and was responsible for building shared services, databases and other foundational components. Within each stream, there were managers responsible for specific parts of the product. As a result, each manager had their own list of tasks, prioritized independently. In addition to Product Managers, there were also Project Managers who coordinated team events such as sprint planning, daily scrum and retrospectives. They were responsible for writing task descriptions, documenting requirements and tracking the status of work within each sprint. Each stream also included roles such as a Data Analyst, Designer and Team Lead. Development Teams As for the development teams, they were divided according to clear specializations. Full-stack developers worked on both backend logic and the frontend logic of the web application. Mobile app developers focused exclusively on the mobile application and were not involved in backend development. QA specialists formed a separate team and were primarily responsible for manual testing of anything assigned to them. There was also a dedicated frontend markup specialist who handled web layout tasks. In this setup, specialists were focused strictly on their specific areas of work. However, they often lacked broader context about what was happening in their part of the business. Within each stream, individual specialists worked only on the specific functionality assigned to them. That made it easier to control changes in their part of the product, but limited visibility. Only the Team Leads of each stream had a wider understanding of the overall picture. Design and analytics competencies existed within two of the streams. However, they operated separately from the development teams. Instead of working as part of cross-functional squads, designers and analysts received tasks directly from product managers.   Sprint flow The teams did not have clear sprint goals. Their main focus was simply completing their individual lists of tasks. Before sprint planning, some tasks might have been discussed between individual specialists and a product manager to clarify certain implementation details. But in practice, it was the product/project manager who wrote the requirements and assigned tasks to different specialists for execution. On planning day, each product manager would gather tasks from their own backlog that they wanted to include in the sprint. The stream team would then come together and each manager would take turns assigning work to the developers they were in regular contact with. At the end of the sprint, a presentation was held where managers shared what they had planned for the current and previous sprints, what had been released to users and what was still in progress. Developers did not participate in these presentations at all. This is an example below of how a large feature, intended for all platforms, could end up being developed over multiple sprints due to functional separation and a long chain of handoffs. Not every feature took as long as five sprints to complete, but the same working pattern remained. For instance, the mobile app team couldn’t start their part until the backend work was finished – which often meant waiting until the next sprint to even begin. And in reality, these handoffs rarely went smoothly. Mobile developers would go to the Team Lead or product manager and say that the backend was delivering incorrect data. The managers would then step in to resolve the issues. The organizational design through the Org Topologies These observations gave me a clear understanding of the organization’s setup. Viewed through the Org Topologies the organization clearly matched the Resource Topology archetype. The development teams were positioned at levels TASKS-1 and TASKS-2. So the delivery was fragmented and coordination-heavy because of a lot of hand-offs. At the same time, Product Managers and Team Leads operated at levels PART-1 and PART-2, reflecting their partial ownership of business areas and decision-making responsibilities. A big part of their job was coordination across multiple teams. Teams were not empowered to deliver independently across the full value stream. They were workloaded due to their individual capacity. That’s why the whole delivery flow was based on handoffs. Managers or Team Leads obtained the role of coordinators in this process. This organizational design shows that the structure was built around utilization, driven by a resource-management approach and the splitting of product areas and codebases across different teams or specialists. In practice, the organization was optimized for utilization and coordination, rather than for flexibility and flow. Assessing the organization With this understanding I finally got an answer to my question: “Why does your structure look like this?” and here’s what I concluded: ●      It was a linear decision made as the team started to grow. ●      The structure made it easier to manage developer workloads and assignments. ●      When each developer works only on what they already know, they naturally maintain control over changes in the codebase, and it’s always clear who to talk to if something breaks. This belief reflects a mental model of local ownership and specialization – one that shaped the structure of teams, roles and workflows across the product organization. And it shows how an initial need and a mental model can lead to growing organizational complexity. In our case, streams meant new product functionality. So when the team realized they needed to build something new (for example, a new search or filtering capability), it was treated as a new project. And the belief was that each project needed its own manager to lead it. As a result, adding new streams naturally increased the number of managers and developers, which led to overall team growth. R1: Growth Trap Loop As the team grows, communication becomes more complex, leading to coordination problems and inefficiencies. These problems create pressure on Product Owner, who respond by hiring additional managers to improve control and oversight. But this only increases the size and complexity of the system – feeding back into more communication overhead and more problems. This loop is self-reinforcing and hard to break from within. It feels like you're solving problems by hiring additional managers, but in reality, you're fueling them. R2: Backlog Multiplication Loop As the team scales, more managers are added. Each manager tends to manage their own backlog (due to the mental model of individual responsibility), increasing the number of disconnected lists of work. This increases cognitive load, misalignment and pressure on Product Owners who must now coordinate across more fragmented areas. In response, the organization again hires more managers and the loop continues. Together, these two reinforcing loops created a self-sustaining trap. The more the organization scaled, the more structural and coordination complexity it introduced. Attempts to regain control, by adding more managers and splitting ownership, only deepened the system's inefficiencies. Over time, this created organizational fatigue, misaligned delivery and mounting internal friction, despite the good intentions behind every decision.   Diagnosis Summary The current structure is characterized by handoffs, fragmented ownership and manager-driven coordination. It is optimized for resource allocation and control, rather than for efficiency and value delivery. This design emerged not as a deliberate target, but as a result of well-intentioned decisions aligned with a mental model of individual specialization and responsibility. This structure became self-reinforcing: developers executed assigned tasks, while problem-solving and coordination were handled through managers. The organization, while growing, unintentionally optimized for control – not adaptability or learning. Designing the future organization I presented my observations and conclusions to top management. While the overall reaction was positive, some points were difficult to accept. The biggest insight came when I explained that the goal of the current structure wasn’t efficiency,  it was utilization and resource management. This highlighted that utilization and resource management should not be the primary goal of an organization. Because it didn’t bring benefits anymore. The management realized that simply adding more people wouldn’t lead to greater efficiency or better performance. In fact, it could make things worse. After all those conversations and reflections we back to the familiar question which I mentioned at the beginning: “How should we organize our work to achieve better results?” This is the key question that determines the state of the future organizational design. From the earlier findings and research, I began forming certain hypotheses about the future organizational design. But the answer wasn’t straightforward. So, I wanted to validate my vision. I decided to clarify the organization’s needs. Because understanding those needs shapes how the organization must operate in order to achieve its product goals. My next step was to review the Product Strategy, Product goals and initiate a round of additional conversations with management to clarify the organization’s real needs. As the result of this research, the main organization’s needs were: Focus on what matters most and prioritize according to the overall strategy. Make product decisions based on data and real user needs. Ensure consistent functionality for all users across all platforms. And it was aligned with the LeSS principles: ●      Whole product focus ●      Customer centric ●      Empirical Process Control Comparing the current state and the organization’s needs, the conclusion was obvious: the existing organizational design couldn’t meet those needs. As I mentioned in the first part of this case, the structure was effectively optimized for utilization and control of work and not for adaptability, learning or delivering product value. It was close to my previous hypotheses. But to be honest, I still didn't believe in the idea of LeSS Transformation. Because it looked like  a difficult and complex journey – elevating an organization from component teams to end-to-end feature teams. I wasn’t sure the organization was ready to take on such a huge challenge. As I mentioned earlier, the organization had already gone through many different phases of change and transformation. Because of that, the motivation to make the new round of changes, even if it is more structured, was very low. "Once again, we’ll start changing something, but in the end, it won’t affect anything, and we’ll just go back to how it was," – one of the Team Leads told me. Such a fundamental change should always be about organizational structure. Especially, when the organization's needs are intertwined with LeSS principles. LeSS adoption always required structure changes.   Three Adoption Principles LeSS defines three adoption principles that describe the necessary conditions for organizational change. The first principle "Deep and Narrow over broad and shallow" suggests starting change within clear product boundaries rather than attempting to transform everything at once for reducing risks. The second principle, “Top-down and bottom-up,” states that transformation cannot be driven from only one direction. Leadership must actively support the change and explain its business intent, while teams need to be involved and understand the purpose behind it. This alignment between management intent and team-level ownership requires shifts across the entire operational layer, including how the organization thinks about product development. The last principle, “Use Volunteering,” emphasizes that transformation depends on people who are willing to step forward as change drivers, leading by example and encouraging others to engage. Applying the Three Adoption Principles to our context, the first principle was straightforward. As part of the organizational changes, we needed to focus on a specific area of product development involving about 50 people. According to the second principle, my intention was to work across all levels of the organization, not to create yet another local optimization at the team level. However, the third principle raised some questions. I had strong support from the C-level executives – they were active and deeply engaged in the process. But the teams were still uncertain. They didn’t fully understand what was going to happen or, if changes did occur, where those changes would actually lead. Absorbing all these thoughts, I shared with the management that we should begin with a LeSS Organizational Design training. This training had several goals: Involve people in understanding the current problems we were facing; Educate everyone because it is an important part to help everyone understand why behind the needed change; Check the mood of the team and how LeSS concept would met; Identify volunteers who were motivated to support and lead the change   LeSS Organizational Design training Educating everyone is a difficult challenge especially when we're talking about 50 people. So the decision was to start with the first training group which included: C-level representatives, Head of Product, all Product Managers, Project Managers and Team Leads from development, analytics and design. This group included the key authority figures within the product development organization – those whose understanding and support would be critical for any future change. I started preparing for the training. And then I created a chat in a common workspace to announce this event for this group with all details and agenda. The LeSS training programme: Day 1: Complex domain, Scrum basic, System Thinking, Optimizing Goal, One Product Backlog. Day 2: Scaling, LeSS principles, Team design and capabilities in LeSS setup, Cross-Team Refinement, LeSS Adoption steps. After the full two-day training, we achieved great results. Aligned with the training’s goals, we were able to highlight current organizational problems and explain the dynamics behind the existing structure. Participants gained a deep dive into system modeling, which helped them better understand the underlying patterns and causes within the system. The key insights that were: ●      The existing organizational design optimized for utilization and control of work. ●      We need to define a clear optimization goal. ●      We should move toward a single Product Backlog. ●      We must align around one shared Definition of Done (DoD). ●      We need to rethink team structures and roles. ●      And we must place greater focus on user needs. I was surprised by the level of engagement. People were energized by being involved in discussing challenges across the organization. And they were part of the organizational designing and decision making process. For the first time, they didn’t feel like they were simply receiving instructions from above, they felt like they were co-creating the future of the organization, not just following top-down directives. Almost all 20 persons became drivers of future changes in the company.   And based on training’s insights we created a Transformational Backlog together as a team. The Items in Our Transformational Backlog: ●      Create the Optimization Goal ●      Create a single Product Backlog for the Whole Product ●      Accept the decision about the team structure changes ●      Conduct LeSS training for the engineers ●      Team Design Workshop ●      Accept the DoD for Whole Product ●      Preparing tools for the teams’ online work ●      Conduct Initial PBR (new format) But there were still open questions about Product Backlog, Teams’ Flow. While the training topics were clear and well-received, fully accepting them required a significant mindset shift. It’s important to highlight that this training was not just about introducing the LeSS framework. Honestly, we didn’t focus on terms like “LeSS” or “LeSS Transformation.” Instead, we approached it as a process of organizational design, using systems thinking and LeSS principles to shape the possible future state. But the training wasn’t the end of that process. Over the following 4 months, we prepared for the flip toward a more adaptive organizational structure. During this time, we did a lot of work: discussing, debating and aligning around key topics like the Product Backlog and Team Flow. We were able to carry out comprehensive work on identifying the organization’s needs and conduct high-quality training. This training helped the team gain knowledge in system modeling, new approaches to product development and product management, as well as a deeper understanding of LeSS principles and practices.   Creating the Optimizational Goal This was a particularly difficult step. We were misaligned in our visions and priorities. Despite the training and shared insights, the old mindset was still holding us back from moving forward. I pushed for a focus on adaptability, because it was clearly rooted in our previously defined organizational needs. However, part of the transformation team remained focused on financial goals above all else. In the first iterations, the proposed optimization goal sounded like: "Maximizing company profit through the execution of the product strategy." – with a small note underneath: "One Product Backlog, Cross-Functional Teams." . And nothing about organizational structure. I didn’t like it at all. Over the next few sessions, we focused on creating the Optimization Goal. We returned to the organization’s core needs as the primary source of our direction. I reminded the team of the key insights from the training and the LeSS principles – all of which pointed toward adaptability as our central challenge and aspiration. I reminded them that the current structure was not designed for adaptability. It was built for control, coordination and utilization. That’s why the Optimization Goal had to reflect the real purpose behind the change, not just surface-level improvements. We needed a goal that would unify the organization and guide future design decisions. It defines what the entire system is intended to achieve. Without it the common understanding of changes could be lost. And looking ahead, I can say that the Optimization Goal truly helped us make the right decisions about the future organizational structure. After several sessions of discussing and repeating all that we learned from the training we reached a shared agreement on our Optimization Goal and we all agreed that this is a vision that will help us to elevate our adaptability: To build an organizational structure that enables self-managing development teams to focus on delivering the most valuable functionality for users.   Q&A sessions At this stage, only the volunteer group knew about the upcoming organizational design change. Even after we had completed the training, created the transformation backlog and defined the optimization goal, people still had doubts about the future design. And I understood them, when you start to realize that you’ll have to break a familiar way of working, along with all your established processes and connections, it’s natural to want to take a step back. Although the training helped them see the situation from a different perspective and even inspired them, there was still fear and a feeling that everything might break and get worse. So before moving forward and announcing the change to the entire team, we needed to align among ourselves to present one clear, unified message. The main doubts were about: the Product Backlog, the role of Product Managers, E2E feature teams, Definition of Done and sprint dynamics in the new setup. So we ran a few Q&A sessions discussing these topics. We started with Product Backlog. All work items were stored in Jira, but spread across different projects. Each team: iOS, Android, Web and QA, had its own Jira space with different workflows, statuses and definitions of done. In addition, every manager created their own items in separate projects, maintaining personal lists of work. I reminded them that the Product Backlog should be: ●      A single source of work for all teams ●      Ordered to maximize progress toward the Product Goal. ●      Prioritized by the Product Owner I explained to them what a Product Backlog Item (PBI) is and introduced the concept of vertical slicing. That’s when they realized we would need to create the Product Backlog from scratch. This was disappointing for them, as they already had a large number of requirements in Jira. Now, all of that would have to be merged into a single list and, even more challenging, the specialized tasks could no longer exist. At this point, I felt some resistance which was natural. I refocused them on the Organizational Needs we had discovered together. These needs aligned with Whole Product Focus, Customer, High Value Items Delivery, Customer Feedback. This alignment helped us make the final decision to create a single Product Backlog. Regarding the role of Product Managers, I explained that they were not going anywhere – instead, they would become more involved with the Product Owner’s team. The only condition was that they would no longer have their own separate backlogs to manage. Instead, they would contribute to the single Product Backlog and the overall product work, without being tied to specific teams. The possible New Organizational Design The most interesting discussion was about teams’ flow and teams’ design. They began to challenge the idea of feature teams. Everyone understood the need for change and the reasons behind it, but the transformation team started asking questions and reflecting on possible designs. It was difficult for them to imagine a format where they were no longer tied to specific product areas. Their proposal reflected this concern: keep the separation between Buyers and Sellers, but remove the Core team and distribute its competencies across the two streams. From their perspective, this made sense for two reasons. First, such a design was more familiar to them – they could keep their existing competencies and since the product had both Buyers and Sellers on the platform, developing in these two directions seemed logical. Second, it required less effort, meaning the change could happen faster while globally keeping the structure they were used to. But this was a very fragile moment. I remembered the phrase: “When the structure changes, the behavior changes as well.”  In their proposal, the structure essentially remained the same setup, just with slightly reconfigured teams. I asked them directly: “Why do we need to keep these two directions at all?” For them, the answer was simply that it was familiar. What they couldn’t yet see was how to combine both directions into one Product Backlog and ensure meaningful collaboration between the Product Managers and the teams. I started filtering their vision through the lens of the organization’s needs and pointed out where their proposal didn’t match. Second, I reminded them of what we had agreed during the training: that our product is not about separate streams. By removing those streams, we could increase our adaptability, not by creating work for specific directions, but by exploring user and product problems and solving them with a faster response than we have today. The proposed design still reflected old thinking – distributing work by competencies. This would have required creating new teams whenever new skills or product directions emerged, adding unnecessary complexity to the system. When speed of change was raised as an argument, I challenged it by asking how previous “quick” transformations had truly improved the system. Through these questions, I helped the group shift their perspective from local optimization and short-term fixes toward systemic needs and whole-system functioning. Finally, we agreed that the quick and simpler solution did not meet our needs or align with our optimization goal. Keeping the two product streams would only preserve the system’s existing problems. We chose to make a complete structural shift creating an adaptive and value-driven organization. Involving volunteers, especially team leaders, made it possible to address much of the initial resistance and doubt right from the start. It also allowed us to finalize, together, the shared vision of the future organizational design.   Communication to the whole team After we reached a shared understanding with the volunteer team, we began preparing for a meeting with the entire team to involve them in the current challenges and explain the need for changes. We prepared a presentation in which we talked about: ●      the functions and goals of the current way of working ●      the organization’s needs ●      the main insights from the training ●      the optimization goal ●      our next steps Since the key leaders were already engaged, answering questions and facilitating discussion became much easier. The explanations were coming from people who had been working alongside the team for years and not only from me. The team especially liked the plan. We explained that the preparation phase would last several months and wouldn’t start the day after the meeting. As part of this preparation, we would go through training together and address questions as they arose. This approach gave them the opportunity to feel involved in the process.   Learning Organizational Designing and LeSS Framework with rest of team I remember that a few times the management suggested that maybe we shouldn’t conduct training for the team and instead speed up the implementation of changes. But this is a principle that cannot be violated and it was my main condition – to train everyone. So, I reviewed the structure of the previous training and made some adjustments, adding more emphasis on the principles of working with a single backlog, feature teams and the main events in LeSS. During the training the most discussed topic was E2E team design. It took time to explain to them why the organization needed such kinds of teams. I prepared the frame with types of team design: narrow focused specialists (BE, FE, etc.), multi-functional teams responsible for some functionality, cross-component and cross-functional teams. And asked them to generate pros and cons for every type. We discussed and then I asked, what type is aligned with organizational needs and our CLD. Only a few people said that third type. We stepped back to the Single Product backlog and asked them to explain how the 1st or 2nd type could match. Gradually, they began to see that only the third type could truly support adaptability and whole-product focus. It wasn’t easy for them to shift their thinking, but eventually they agreed. We finished the training with a batch of insights. The team realized their accountability and influence on the product was much greater than they had assumed. They gained an overview of LeSS and system modeling. I especially remember one developer saying afterwards: “Nothing like this has ever happened before, that we are involved in shaping the changes, that our opinions are asked and that problems are discussed so deeply.”   Before team design workshop The LeSS guide recommends running a Team Self-Design Workshop. After our training, we met with the Team Leads to discuss the next steps. When I presented the workshop agenda, they were not comfortable with the idea of letting people select their own teams. Their main argument was that before working with me, they had already gone through several reorganizations that year. By this time, they were only just beginning to settle, build trust and establish working relationships. The idea of reshuffling everyone again felt too disruptive and they were not ready for it. They were ready to agree with some changes to balance all teams with all necessary competencies. I decided to make a compromise and step away from the LeSS recommendation. Looking back, I wouldn’t call it a critical mistake, but it did slow down the pace of knowledge sharing and reduced the initial willingness of teams to take on unfamiliar PBIs. The lesson I learned here: trust the system, not the fear. Because the fear blocks any useful changes. However, it only slowed us down and it didn’t stop us. With every Sprint, teams became increasingly confident in picking up new items outside their comfort zones. The fear of mistakes gradually disappeared, as the new structure encouraged exploration and learning.   Team design workshop We held this workshop online. Ideally, such a session works best when everyone can gather in the same physical space, but due to the war and blackouts in Ukraine, we didn’t have that opportunity. The plan on the workshop were: -       Introducing the team design and setup -       Building the competencies map -       Creating perfection vision -       Define DoD Introducing the team design and setup The team listened to the arguments about the teams’ setup decision. They agreed with the purpose of feature teams and the proposed team composition. Still, there was some nervousness, as it was a completely new experience for them – working together in one team with web, iOS, Android and QA specialists. The next was creating the competencies map. All new teams went to the virtual rooms to discuss their experience, knowledge and skills. When they came back, they were more energized and motivated. This part turned out to be very valuable, they learned a lot about each other and even more importantly, they saw what their teammates wanted to improve and agreed to support each other through knowledge sharing.   Perfection vision On that positive wave we went forward and worked on Perfection Vision. I asked them to imagine the ideal state of engineering practices, product, organization. They wrote down many different ideas of what they wanted to see in their product. These included improving stability, boosting business metrics, increasing technical expertise, enhancing teamwork and much more. I remember them saying that they had never discussed these things together before. Now, they could see just how many great ideas emerged from such a conversation. They also noted how engaged everyone was and how interesting it was to listen to each other. It brought them closer together as a team. Definition of Done At this stage, we spent time discussing the current Definition of Done (DoD). We quickly noticed differences – each team had its own conditions for what counted as completed functionality. We gathered these together and created a shared baseline list called “DoD NOW,” which became our starting point. Then, I asked the teams to think about what they wanted their DoD to look like in the future. I reminded them of the perfection vision and gave them time to work in groups. Afterwards, we shared the results and voted on which items were both realistic and important. This became our improvement list “DoD 2.0” and we agreed it would be our collective focus for next improvement.     The end of the workshop We did a great job that day. The teams left with a stronger sense of ownership and mutual trust. For many it was the first time they had open discussion about vision, product, their impact and how they could support each other across roles and platforms. This created energy, motivation and a shared belief that change was not only possible, but also within their influence. We closed the session with clarity that we would build a structure capable of delivering end-to-end product value. But I made a huge mistake that affected us later. At the time, I didn’t realize how critical it would be. I overlooked key competencies such as design and analytics, which should have been embedded within the teams. I will describe this in more detail later.   Product Backlog Creation After the Q&A sessions about the Product Backlog I mentioned earlier, the PO and Product Managers organized themselves into a working group. Their main task was to create a transparent list of high-value items that weren’t sliced into narrow technical tasks. From there, we began prioritizing the Product Backlog in alignment with the Product Goals. By the end, we could finally see what really mattered most and this clarity allowed us to identify the highest-value PBIs to bring into the Initial PBR.   Initial PBR The LeSS guide recommends that the Initial PBR last for two full days. In our case, we spent three days refining PBIs. We worked through a large scope, refining everything in the backlog several sprints ahead. Looking back, I can say this wasn’t necessary. Refining just two sprints ahead would have been enough. At the time, we did it because we had the false feeling that it would make things easier, and because we didn’t yet understand our delivery rhythm and actual capabilities. We started with the product strategy and the main product goals. The PO emphasized what was most important for the product, how the product needed to evolve, what steps we had to take and which metrics we would focus on. This stage helped broaden the teams’ understanding of expectations and impact. Previously, teams, and even individuals, were used to working only within their own parts of the product. Now it became clear that the boundaries were wider. Teams began asking questions about the product and its goals. This was something completely new compared to what I had seen during planning meetings in the old structure. Then we moved on to presenting the PBIs, where the PO together with the PMs briefly explained the context of each item. The teams paid close attention, asking the PMs clarifying questions such as which platforms a particular feature should be implemented on. It was fascinating to watch, because in the past teams would receive tasks already split by platform. Now the teams themselves were seeking clarification. After walking through the backlog, I asked the teams to split into small groups to refine backlog items. We ran several rounds of multi-team PBR. After each round, I suggested giving short feedback. After the first round, it was clear that people were not yet generating solutions as much as they were learning with the parts of the product functionality. For many, this was entirely new knowledge. Within the groups, more experienced specialists in specific areas explained to others how the systems worked. Round by round, we kept moving forward, building up more and more shared knowledge. I remembered the doubts teams had voiced during the LeSS training, when they questioned the point of feature teams: “How will I work with the backend and discuss tasks if I don’t know the backend?” And then I watched them in practice – a backend developer sitting with iOS and Android developers, figuring out the API logic together. In another group, developers explained to a PM how the current search logic on the website worked and suggested possible implementation options. Other group members were present, listening, asking questions and learning new functionality themselves. The next day we continued our work. Together, we defined the greatest value we needed to deliver in the upcoming Sprint and identified the most high-priority PBIs. Then I asked the teams to meet separately, review those PBIs and decide which work they could take on. After that, we ran team-level PBRs so they could prepare more deeply for the Sprint. At the end of the day, we gathered again to summarize the results of our work over the past days. The teams felt a strong sense of responsibility and didn’t want to make mistakes. They were eager to understand the PBIs thoroughly, so they asked to dedicate one more day to learning and refining them. From my experience, I knew they would not be able to break everything down to the smallest details or prepare perfectly for the Sprint, but I decided to support their initiative. For me, it was a positive signal that they were engaged and making decisions within the process. Sprint Planning After all 3 days of Initial PBR we gathered on the Sprint Planning. As the teams had already chosen their PBIs, we started with Sprint Goals. The PO stated the main focus and then we reviewed the PBIs once more to ensure they aligned with the goal. Next we clarified dependencies among the PBIs and lack of knowledge among the teams. And there teams agreed about coordination and consulting each other during the sprint. And then we took time that teams go and planned their work, define their sprint goals and observe their scopes of sprint to finalize all. After that, we all gathered to finalize the Sprint goals and the work for the Sprint.   Sprint Goal This was our first experience in defining a Sprint Goal. Even with all the available recommendations, it doesn’t mean you can immediately do it well. But it is important to start, and to improve gradually. To define a Sprint Goal, you need to answer the question: What exactly do we want to invest this sprint in? Or What specifically should change in our product after this Sprint and why? These questions point the way toward creating the right kind of goal. Around them, the team can start practicing setting goals, even if at first they are not very clear or perfect. It is a practice that helps build product thinking within the team. However, it is important to avoid goals that are too abstract or technical, such as: “complete all tasks”  or “deliver tasks to testing.”   Closing Sprint Planning When we finished planning, the teams still felt nervous. For them, this was a completely new way of working. They didn’t yet know their real capabilities, how the new setup would function, what problems might arise or how to solve them along the way. So I reminded them that for some time we would simply be adapting and experimenting with this new format. I emphasized the importance of sharing feedback, because that would help us move through this phase faster. Despite their concerns, they wanted to try. Compared to all the previous transformations they had experienced, this time felt different.   We did it online The main challenge in our journey was that we were doing all of this during the full-scale war in Ukraine. We had no possibility to gather together physically, as the team was spread across Ukraine and around the world. So everything had to be done remotely, using online tools. Despite all recommendations to work on such changes in one physical space, for us it simply wasn’t possible. Even under these conditions, we managed to carry out comprehensive preparation work entirely online, following LeSS guides and principles, and it worked. We: ●      educated everyone ●      involved the volunteers ●      created a single Product Backlog ●      created 3 feature teams capable of taking on any PBI from the Product Backlog ●      did the initial pbr ●      planned the sprint Through this experience, I can say that the real strength lies in the team. When people truly care about their product, are willing to make it better, act as ambassadors of change and open to experimentation, then even being far apart, in the difficult conditions of today, teams are capable of making big transformations. From an organizational dynamics perspective, the challenge was even greater: questioning an entire way of working that had been built over years, and then shifting to a completely new structure within just 4 months. It was, in fact, a stress test for the entire organization. And I am deeply proud of the people I worked with to make this possible. I believe I was fortunate to have this team. LeSS Organizational design Making the flip is a major event for any organization. It represents the moment when it dares to challenge its familiar way of working and rethink itself. However, at this stage, it is very difficult to evaluate whether these changes will actually lead to the expected results. The teams move forward mostly on belief and adrenaline, as the familiar structure they were used to no longer exists. I can say that when an organization makes the flip, that’s when everything actually begins. The entire preparation process took us about four months. However, I believe that if an organizational change has the highest priority and strong management involvement, this preparation phase can be completed in a shorter time. Still, speed should not be the key criterion in a transformation process. It’s better to invest more time in preparation, discussions and involving people, so that the organization truly understands the necessity and embraces the idea of change. That’s why it’s important not to rush – just to be faster. Here is how the new structure looked compared to the previous one. It clearly illustrates the reduction of complexity and the descaling effect that emerged after the transformation. Multiple fragmented backlogs and component-based teams were replaced by a single Product Backlog and three cross-functional feature teams capable of working across the whole product. Teams dynamic at the beginning The first two Sprints were not very representative in terms of evaluating the results of the new way of working. During that time, there were several staffing changes unrelated to the transformation itself and it also coincided with the vacation period. Therefore, we can say that the beginning of 2025 became the point when we could truly start assessing the impact of the changes. However, even in the first Sprints, the teams began to notice significant changes in their work dynamics. The full responsibility for managing and organizing their work had now shifted to them. The teams started independently organizing their Daily Scrums, resolving development issues and coordinating their work. Managers, who previously facilitated meetings or made technical decisions instead of engineers, were no longer involved in these processes. This happened due to several factors: ●      Team design.  Each team consisted of 8-9 engineers, which significantly simplified communication and interaction – both during team meetings and in day-to-day work. ●      Sprint Goals.  The teams now set their own Sprint Goals and were fully responsible for achieving them. Consequently, they also took ownership of resolving all questions and challenges related to reaching those goals. This simplified interaction and helped the teams become more autonomous and they liked it much more than in the previous structure. Now, within their own teams, they discussed progress directly, shared information openly and highlighted where support was needed. The teams also started communicating directly with other teams whenever necessary, which significantly accelerated problem-solving. They no longer had to wait for a manager to find time to gather everyone and lead the discussion. It was a small, but meaningful victory that built confidence and trust that the changes were truly making things better.   Product Backlog A single Product Backlog for the entire product was something completely new for the organization. It started to create a shared understanding of what was truly important for the product. In practice, it became the single source of work for all teams – the place that answered the question: “Where is the product heading?”.  Over time, this shared understanding continued to improve. We created an end-to-end backlog that included PBIs from various product initiatives. The Product Managers, acting as subject matter experts (SMEs), met regularly with the PO to keep it up to date and to define priorities together. Structurally, it looked like this: But there were several problems. The first issue we began to notice was decomposition or rather, the lack of it. In the first Sprints, neither the managers nor the teams had yet developed an understanding of iterative development. As a result, the PBIs brought to PBR sessions were mostly clarified and discussed from an implementation point of view, but not broken down further. The teams then took several of these large PBIs into the Sprint and were unable to turn them into a ready Increment by the end of it. The teams were finishing their work on these items by the end of the Sprint, usually at the testing stage, at best. For several consecutive Sprints, the situation didn’t improve. Working through this together with the teams, we identified that this was a clear violation of our Definition of Done. If we look at this moment in terms of metrics, the Sprint Task Completion Rate was around 45–55%, while the Sprint Goal Completion Rate was about 40%. To address the issue, we agreed on the following steps: ●      During PBR, teams should decompose any PBI that is too large to complete within one Sprint. ●      Reduce the number of PBIs brought for discussion during PBR.Gradually decrease the number of PBIs planned per team for each Sprint. ●      Ensure that everyone understands and adheres to the DoD so that each Increment meets it fully. At the next PBR, I began by explaining what decomposition and iterative development mean. I suggested we try decomposing a PBI using a real example, so everyone could understand both the process and the expected outcome. This small workshop helped everyone understand how decomposition really works. It also helped us manage expectations within Sprints more effectively. Managers and teams began to see the concept of “customer value” differently. They realized that value can be increased iteratively step by step by gathering feedback from users along the way. This was very different from the way they used to work before.   Product Backlog Refinement PBR has become an integral part of the teams’ work and learning. It is thanks to multi-team PBR that we maintain knowledge sharing across teams, which greatly improves understanding of both the product development context and the engineering context. This is especially important considering that, in the past, developers worked only on separate parts of the product. In my opinion, this is one of the most essential elements for increasing adaptability, as the teams are no longer limited by knowledge of a single functional area – instead, they explore PBIs together and develop higher-quality solutions. Multi-team PBR also helped us anticipate potential blockers and dependencies before the work even started. This made it possible to plan actions that would help resolve these issues ahead of time or manage them more effectively during development. In practice, it improved overall team coordination.   Multi-team PBR facilitation Under the conditions of the full-scale war in Ukraine, all teams work primarily online. Tools such as Miro, Mural and Confluence whiteboards help us create a shared virtual workspace for team collaboration. A day before each PBR, we meet with the PO and PMs to review and update the backlog, and we prepare the virtual board for the upcoming session. We start each PBR with the PO presenting the upcoming priorities,  explaining why they are important and which of them are most likely to enter the next Sprint. We briefly go through the PBIs to provide the teams with context. After that, the teams organize themselves into mixed groups and move to virtual breakout rooms to discuss the proposed PBIs. Usually, we divide into three groups. During the session, each group completes three rounds, rotating between rooms so that everyone has a chance to work with all PBIs. At the end of the session, we finalize the results of the PBR and determine which PBIs are ready for planning and which still require additional work. For those not yet ready, the teams agree to refine them individually, either because they are interested in taking them into the next Sprint or because they want to explore them further and later share their findings with everyone. The teams quickly began to see the value of PBR. At first, this format seemed complex to them, but now they want to understand as much of the broader product context as possible. It’s also important to note that PBR has shifted the focus from simply analyzing tasks assigned by managers to enabling teams to propose their own solutions to product problems. It is expanding organizational agility and domain knowledge among engineers. Sprint Planning We start with a short alignment session where the Product Owner, together with Product Managers, reviews the Product Backlog one more time to finalize expectations for the upcoming Sprint. At the same time, teams meet in their virtual rooms to synchronize and update their context. They review their boards, check if there’s any remaining work from the previous Sprint that could influence the next one and briefly revisit outcomes from the last retrospective to incorporate improvements into the new Sprint. Next, we all come together for a joint session. Each team gives a short update on whether they still have unfinished work or if there’s anything that needs to be added to the planning scope. Then, the PO shares overall expectations for the Sprint and walks everyone through the backlog. After that, teams split again to analyze the expectations and backlog items and to decide which work they want to take on. They mark potential items directly in the backlog. Once all teams have done this, we review the selections together to identify overlaps, for example, when two teams have marked the same item and agree on ownership. Each team then holds its own Sprint Planning session, where they define their Sprint Goal, create a plan and identify dependencies and interactions with other teams. At the end, we come together again for a short Sprint summary, where we align on Sprint Goals, team scopes, open questions and then officially start the Sprint.   Story Points experiment Over time, we decided to run an experiment with estimation. Previously, teams estimated work in hours. This approach caused a lot of frustration and it didn’t provide any real guarantee that tasks would be completed on time and it was almost impossible to predict how many productive hours each engineer would actually have during the Sprint. Most importantly, it reinforced an old pattern of individual estimation and task assignment, where work was distributed per person rather than owned by the team. Following old patterns also affected Sprint results. In the first few Sprints, teams still had unfinished work and often failed to achieve the Sprint Goal. I believed this was happening because the teams were not yet acting as a single unit and each person still held their own context and estimates around tasks and maintained an individual focus rather than a shared one. I suggested trying Story Points instead. I know there’s a lot of criticism around this approach, but in our case, the reasoning was very specific. The goal wasn’t to measure velocity – it was to break the pattern of individual focus and to encourage shared team understanding of the work. The hypothesis was simple: if teams start estimating together, they will communicate more, share knowledge and better understand how to achieve the Sprint Goal collectively. And that’s exactly what happened. Through Planning Poker, teams began to discuss implementation details, ask clarifying questions and uncover hidden assumptions. I believe this is the true purpose of Story Points is not to measure precision, but to help teams talk, think and plan together to find the best possible solution. If you face a similar situation or believe this approach could be useful in your context, be ready to sell the experiment to the team. My proposal was not just about changing the estimation technique, it was about solving a specific problem. I started by clearly explaining the goal of the experiment, the problem we wanted to address and my proposed decision – to try Story Points. Then I described what Story Points actually are, how they work and how we would implement them together. This framing was important. When teams understand why a change is happening and what problem it solves, they are much more likely to engage, experiment and make the approach their own. As a result, this experiment became one of the elements that helped us improve delivery stability. It wasn’t the Story Points themselves that made the difference, but the shared understanding, communication and team alignment they encouraged. At the same time, I wouldn’t recommend using Story Points just because “Agile teams are supposed to estimate this way”. They are not a universal solution – their value depends on why and how you use them. In our case, Story Points worked because they solved a specific problem and helped the teams grow together, not because they were part of some agile rulebook.   Sprint Review A major change for the organization was the introduction of the Sprint Review. Before the structural transformation, there was already something similar, it was called a Sprint Results Demonstration. The mechanics were quite simple: managers prepared slides showing what they had planned for their teams, what had been released during the Sprint (which could include functionality started in earlier Sprints), and then, during the meeting, they presented this information slide by slide. When I asked the questions, “Why aren’t the teams doing this?” and “What is the value of this meeting?” I received the following answers: ●      “Should the teams really be doing this? It’s the managers who manage the tasks.” ●      “To share progress on these tasks.” There were no conclusions, feedback or discussions during this meeting. In fact, the manager simply reported on “their” tasks. When it came time to prepare for the Sprint Review, the teams began asking why they needed to do it themselves. The main concerns among the teams were about preparation and presentation. It was clear that they were reluctant to invest their time and effort into it. They perceived it as additional work, something they hadn’t been responsible for before. For them, it felt like extra effort and new responsibility, because in their minds, this had always been the managerʼs job. So, I decided to remind them once again of the purpose of the Sprint Review and to explain what the teams’ responsibility truly means. The purpose of the Sprint Review is to inspect the Sprint results and gather feedback on the created Increment in order to define further changes to the product. This event creates a shared context among all interested roles. The teams are the owners of the Increment because they are the ones who built it during the Sprint. Therefore, they should be the ones explaining and demonstrating it. Preparing for the Review also builds a sense of responsibility and self-organization – helping teams realize that they are not just executors but the true owners of the result. According to this, the teams agreed with this experiment and took the responsibility for preparing the increment. We also agreed that the teams would prepare for it by themselves, deciding how they wanted to present and inspect the developed Increment and would be active participants in the discussions. Also, we aligned on the structure for the Sprint Review: ●      The Sprint Review begins with the PO giving an opening message, highlighting the main focus areas. ●      Next, the PO briefly reviews the key product metrics and provides short comments on their dynamics. ●      After that, the teams take the stage one by one. Each team talks about its Sprint goal and demonstrates how the new Increment works. At the end of each demonstration, the team leaves time for questions, feedback and discussion. It might seem like nothing particularly significant had happened — the teams simply started taking an active part in the Sprint Review. But here are a few of my observations on how this change actually influenced the teams. This change had a strong impact on setting clearer expectations. Now it was not the manager showing some results, it was the team that created the Increment within the Sprint and was responsible for it. This, in turn, influenced how teams began to perceive and relate to the Sprint outcome. There was now a clear Sprint Goal and clear expectations. This significantly increased the level of ownership and accountability. As a result, the teams started approaching PBR, Sprint Planning and the upcoming Increment much more consciously. PO team dynamic As I mentioned at previous parts, the system before changes had been built around the idea that Product Managers divided the product into separate areas and directions. Each PM was responsible for their own part and was expected to deliver results and report on progress. Consequently, they had their own individual goals that they wanted to achieve. In practice, this prevented the product from evolving in a unified direction, as each PM was focused on pushing forward their own initiatives. Each manager was mainly interested in ensuring that their tasks were taken into development. As a result, planning meetings brought together component teams and managers. Each manager would present their tasks and, together with the Team Lead, decide which developer would take on which task and how many. In the end, every developer had a list of tasks for the next two weeks, and the manager coordinated their execution. From the very beginning, during our training on organizational modeling, we explored the roles of the PO and PM, and how collaboration between the PO, PMs and Teams should work. The key idea that managers needed to accept was that they no longer had to push their own tasks into development or compete for resources. Their role remained important – they continued to support the PO in developing the product, but they were no longer responsible for coordinating teams or managing events. Most importantly, all future work now flowed through a single Product Backlog. This created some difficulties at the beginning. Each manager still remained an expert in their specific part of the product and continued working within that area, preparing corresponding PBIs. Naturally, each of them wanted their items to be taken into development –  otherwise, they felt they were losing their sense of importance and contribution. The PO was the one who made the final decision on where to invest the next Sprint’s effort. Not everyone liked this change, but we followed the principle of “job safety over role safety.” It was also important for them to understand that situations where a manager explored a direction and their findings were not immediately taken into discussion or included in the next Sprint were completely normal. We focused on what was important for the product, not on how many tasks a manager could prepare or plan for the team. However, not all managers fully accepted this new reality and over time, some decided to leave the company. For those who stayed, there was a period when they felt somewhat disconnected from the teams. They were no longer facilitating team meetings, solving development issues, or coordinating daily work. However, this was the right direction for them – it allowed them to focus more on product research and development. The teams themselves began to approach the managers whenever they needed support or expertise.   Expanding engineering competencies One of the most rewarding observations was how deeply engineers embraced the idea of sharing product knowledge and developing new competencies. A great example of this was the initiative to spread app testing expertise across teams. Due to several staffing changes, the number of dedicated testers was significantly reduced, which made this skill set critical. Our Engineering Manager, together with internal experts from the teams, designed a practical training course on testing. They developed a learning plan and, over several Sprints, conducted sessions to teach and mentor developers and other testers on the testing practices used within the company. This initiative greatly helped to spread testing knowledge, reduce bottlenecks and strengthen the teams’ autonomy. And helped to support the quality of the product on the level. Now there is no fear or resistance to testing work – it’s no longer seen as “someone else’s responsibility”. Teams understand that quality is a shared responsibility and that mindset has become part of our culture. This was a beautiful example of mature self-organization showing how a culture of shared responsibility and learning can spread organically across teams, without being enforced from outside. Definition of Done When it comes to the Definition of Done (DoD), we initially gave it little attention. We defined a basic version at the start, but over time teams began to follow it only partially. Such an attitude can easily lead to a gradual decline in quality, especially as the organization scales. A Sprint Increment must always meet the Definition of Done. If the DoD is unclear, incomplete, or inconsistently applied, it creates invisible debt: unfinished work, untested code and technical uncertainty that accumulates over time. Without a shared and enforced DoD, the meaning of “Done” becomes subjective and predictability and quality quickly erode. Over time, we returned to review our DoD again. The engineers agreed that we needed to adhere to it consistently and improve it together. This led to new, clearer items that became mandatory for all teams. We are now working to ensure that every team has the capability to meet these standards so that each Sprint delivers a true, high-quality Increment. As a result of this reflection, we created a plan that includes developing new skills within the teams. This clearly demonstrates how the Definition of Done directly drives development of engineers capabilities and continuous improvement. I highly recommend establishing a clear Definition of Done. Define what activities it includes, how DoD can be measured and how the organization will support it Sprint by Sprint.   Results and Organizational Impact In conclusion, I’d like to share some concrete results. Many people in the industry often ask – why are such organizational changes even necessary and what do they actually bring to the business? There’s a fair amount of skepticism in the market about these kinds of transformations. And I didn’t want to answer with something abstract like: “It’s a complex systemic process with many influencing factors, but overall it’s a better way of working because it aligns the organization around a single source of work and puts the customer at the center.”Those words are true, but they still don’t answer the real question: did it actually make a difference? I chose a few tools to evaluate the success of the changes: key metrics and the Org Topologies mapping. The main metrics I tracked were Cycle Time, Throughput and Sprint Goal Completion Rate. These are simple indicators that help observe how the system is changing. ●      Cycle Time showed how quickly we could turn started work into usable outcomes. ●      Throughput helped us see the stability and predictability of delivery. ●      Sprint Goal Completion Rate reflected how well the teams understood priorities, planned their work and delivered on what they committed to. These metrics were easy for everyone to understand and discuss, which made them a great entry point for learning and reflection. They also served as signals of whether our changes were really improving the system or just shifting the symptoms. After seven months of operating in the new LeSS structure, the impact on key flow metrics was striking. Cycle Time across all three teams decreased by around 80%, meaning Sprint Backlog items were completed roughly five times faster than before. This reflected the removal of systemic delays and smoother collaboration across the teams. Throughput remained stable, even though Work in Progress was reduced by approximately 60%. Previously, teams tended to start more work than they could complete, which led to interruptions, dependencies and items getting stuck in progress. With the new structure, teams focused sharply on their Sprint Goals and committed only to the amount of work they could realistically complete to achieve those goals. This resulted in a much more stable and predictable flow of work. As a result, Sprint Goal achievement rose from around 40% to over 90%, demonstrating stronger alignment between planning, execution, and outcomes – a clear indicator of improved system coherence and team maturity. These outcomes were not merely the result of improved metrics. By simplifying the structure, reducing handovers and fostering true cross-team collaboration, the organization created conditions for faster learning and more consistent delivery of value. This systemic improvement also translated into financial impact. In this case the organizational changes did not have a negative impact on financial performance, as is often feared.   Observing New Org Design The second important insight emerged when I looked at the new structure through the lens of Org Topologies. As described earlier in the Designing the Future Organization section, the LeSS structure was meant to help the organization become more adaptive. From an Org Topologies perspective, such a structure ideally sits in the top-right quadrant. That was our target state. So what did we actually achieve? We ended up with three cross-functional, cross-component feature teams capable of taking any item from the Product Backlog and delivering it to “Done.” In principle, this meant that each team could work across the whole product. Product Managers acted as subject-matter experts, supporting the Product Owner in shaping the product strategy and aligning the backlog with business goals. Structurally, this seemed like a good step toward adaptiveness. However, I made a significant mistake during the team design phase. While focusing on building end-to-end feature teams, I concentrated mostly on engineering capabilities: backend, frontend, mobile, QA, and didn’t fully consider non-engineering but critical competencies, such as design and analytics. Design and analytics were essential to our product development process, yet they remained outside the teams – organized as separate functional departments, each with their own leads and allocation model. These departments provided their services to teams but were not part of them. At first, this seemed acceptable: teams could pick any backlog item and deliver it end-to-end as long as the design and analytics work had already been done. But this dependency became more visible over time. From the Org Topologies perspective, this revealed a clear misalignment between intent and reality. The teams had indeed moved up the vertical axis – their scope of work expanded to cover the whole product. But horizontally, their scope of skills was still incomplete. They were multi-skilled, but not truly end-to-end. Missing design and analytics capabilities meant that teams couldn’t independently close the full loop of problem discovery, solution definition and delivery. As a result, the organization unintentionally remained in a Resource Topology. Despite having feature teams, the flow of value was still dependent on centralized design and analytics functions. The teams’ behavior reflected this dependency: instead of continuously discovering and solving product problems, they focused on delivering the highest-priority items that already had design and analytical input. When that input wasn’t ready, teams couldn’t start the work – which in turn affected flow and planning. The Org Topologies assessment made this visible. It showed that even with substantial effort and structural redesign, we had reached only partial adaptiveness. This realization was eye-opening and valuable. It showed that organizational adaptiveness is not achieved merely by forming cross-functional engineer competencies. It requires integrating all critical skills into the system of value delivery. Engineering alone cannot ensure adaptiveness if discovery, design and analytics remain external. Org Topologies helped visualize this gap and turn it into a clear direction for the next evolution step: expanding team capabilities to cover the full product cycle, from insight to impact. Reflection In this part, I share some reflections and key lessons from this transformation experience. Engagement of top management shapes how the entire system perceives change. Executives must be present, participate in discussions, attend training sessions and clearly explain, from a business perspective, why the transformation matters and which problems it aims to solve. Their active involvement sends a strong signal across the organization: this is not another local optimization, but a strategic shift in how the company operates and creates value. Leadership participation builds trust, aligns intent with action, and helps the organization see the change as meaningful and long-term. So, top management has to be in the center of these changes. You must have a mandate for change Any transformation requires a clear and legitimate mandate for change. Without it, even well-intentioned efforts quickly meet resistance, as existing structures and incentives naturally protect the status quo. A strong mandate creates the necessary space for experimentation, enables decision-making without constant escalation and provides the psychological safety for people to challenge established ways of working.   Organizational Design Is More Than Delivery According to the Galbraith Star Model, organizational design is built around the alignment of five elements: strategy, structure, processes, people and rewards. Strategy is a core input for shaping the organization. Reflecting on this experience, I realized that structure and processes cannot evolve in isolation. Even with adaptive teams, stable delivery and growing revenue, success is not guaranteed if the product strategy and decision-making practices remain weak. It is important to keep it consistent. Product strategy and feedback loop are the most important parts of product development. It’s crucial to avoid a situation where any initiative can slip into the backlog simply because someone wants it. There has to be a clear filter that evaluates how each initiative aligns with the strategy and contributes to the product goals. That’s why the product dimension of the organization must evolve as well, including how we define and work with product strategy, make data-driven decisions, validate hypotheses and strengthen the overall product mindset. The focus should be on the whole system, not only on the delivery part. Before starting organizational design changes, it’s worth running several sessions to align on the product strategy, analyze how decisions are made and how hypotheses are validated. Such discussions can expand awareness, improve preparation for the “flip” and help identify missing capabilities in product research and validation practices. This reflection led me to an important realization: preparing for transformation means not only getting engineers and teams ready, but also developing the product side of the organization, helping product managers and leaders learn how to explore, test and make product decisions in new ways, and enabling engineering teams to contribute to this process as equal partners.   Track Product Metrics Organizational design should ultimately help the company achieve its product goals, not only improve internal efficiency. That’s why it’s important to track how structural and process changes affect the key product indicators. Connecting organizational changes to product metrics helps ensure that transformation delivers not just better delivery, but real business impact.   Be Confident One of the most important lessons I learned is to stay confident. When facilitating a transformation of this scale, the whole system will often push back, especially at the beginning. Not everyone shares the same understanding of why change is needed; some people will resist it and a few may even try to actively sabotage it. If you start doubting yourself, compromising on principles or skipping essential parts of the LeSS preparation process, it’s unlikely you’ll be able to bring real value to the organization. Such compromises often lead to mistakes that will have to be fixed later. If you keep old roles, processes or structures “just for now,” be sure that you’re also scaling old problems into the new organization. Confidence in principles and clarity of intent are what allow the transformation to stay meaningful and effective.   Design the System, Then Follow It Follow the conditions of the system you create. When transitioning to LeSS or any other adaptive model, elements of the old structure will remain. These remnants of the previous system can silently undermine new principles if allowed to dictate the rules. It is therefore crucial to continuously identify and eliminate contradictions, aligning the organization with the principles of the new design. LeSS is not just Scrum at scale; it is an organizational transformation that demands systems thinking and ongoing adaptation. Only when all elements – strategy, structure, people, processes and culture operate in harmony with the new model does the system truly come to life and begin delivering real value.