ORG TOPOLOGIES 

This is a digest from the ideas explored in 10X ORG by Alexey Krivitsky, Roland Flemm, and Craig Larman — a book about what happens when AI meets organizational structure, and why the structure usually wins. Listen as a podcast: You could fake agile... Many did. You could rename your project managers to Scrum Masters, your status meetings to standups, your milestones to sprints. You could buy SAFe licenses, certify 200 people, hang a Kanban board in the hallway, and call the whole thing a transformation. And it worked — in the sense that nobody called you out. The board saw the slide deck, the consultants got paid, the teams did their retros. Everyone played along. Change theater, done well, can run for a decade. Your Scrum Master would have told you that's fine. "Agile is an adjective," they'd say. "What matters is that we're more agile this year than last year." And that sounded reasonable, because slow change was tolerable. The market moved at a pace where incremental improvement felt like enough, and nobody was keeping a public scoreboard of how fast your competitors shipped. But here's the thing about slow change: in most organizations, it was cover for no change at all. The language got better. The ceremonies got smoother. The underlying structure — who decides what, who learns what, who is allowed to work on what — stayed exactly where it was. That was survivable. Until now. You Are Now Being Compared to 100X AI-native startups are building full products with one CEO and five Mac Minis. They don't need your org chart, your review cycles, your handoff protocols. They started clean, with no legacy structure and no historical management system weighing them down. From now on, your organization will be benchmarked against what they can do. Not by you — by your board, your investors, your competitors, your customers who notice that someone else ships in days what you deliver in quarters. One hundred times faster, and not as a metaphor. As a measurable gap. So your leadership will ask — if they haven't already — why can't we move like that? And why do we see only costs increasing with no visible gains? The answer is uncomfortable. Your organization didn't start from scratch when AI arrived. It was already on a path — a management system, team structures, habits built up over years. AI found all of that in place, and it is very likely your org is on the same trajectory as before, now with AI spread like fairy dust. Increasing costs, not necessarily gains. With agile, you could hide in the theater. Fake a transformation, skip the hard parts, and nobody benchmarked you against a fundamentally different kind of organization. With AI, the 100X baseline is public. The gap is visible, and faking it gets expensive fast. The Part That's Already Happening Here's what makes this different from every previous technology wave: your developers already know. They go home in the evening, open Claude or Codex, and build something in a few hours that would have taken their team two sprints. They pair with an AI agent and ship a working prototype before midnight. Then they come to the office at nine in the morning and sit down in the same org structure, the same approval chains, the same narrowly defined role boundaries that were designed for a world where building software was slow. They feel the gap every single day. And the ones who are good — the ones you most want to keep — are already thinking about where they could work without that friction. You're not just competing with other employers anymore. You're competing with the experience your own people have at home, where they already operate at ten times the speed your organization allows. This isn't a theoretical risk. It's a retention clock that's already ticking. The Uncomfortable Part AI doesn't just speed things up. It pushes people away from single-skilling and toward orchestration and outcomes. Take a database designer — there's an entire section in 10X ORG called "Nobody Needs 1,000X More Databases" that unpacks this example. If AI allows other people to handle much of that work, and allows the designer to do their traditional load in a few days instead of a month, then the question becomes obvious: what will the organization do with this person? Producing more of the same thing is not the answer. There is no customer demand for a thousand times more databases. There won't be enough demand for what they do. The same goes for UI specialists, business analysts, frontend developers, and a growing list of roles defined by a single skill performed within a fixed boundary. AI doesn't fire anyone. It just makes certain roles easy to not refill. The people with the narrowest mandates and the least leverage to negotiate are the ones who leave first, and they don't get replaced. This is the displacement pattern — not by job title, but by mandate. In 10X ORG (Chapter 3: Org Topologies), we call this the Scope of Skills Mandate: how many skills an organizational unit possesses and is authorized to apply. When that scope is narrow, the unit depends on handoffs, coordination, and other people's calendars. AI makes narrow units faster at what they do — but it doesn't give them anything else to do. And here's where diminishing returns hit. If that database designer is kept pinned to the same work — structurally mandated to keep designing databases because "that's what database designers do" — then the acceleration has nowhere to go. The designer finishes in three days what used to take a month, and then sits in a system that has no mechanism for deploying their freed-up capacity elsewhere. The local gain doesn't compound. It dissipates. That's 1X dynamics: faster parts, same system, no global improvement. The same pattern applies at the team level. Consider a Search team or a Payments Integration team — what 10X ORG describes as Delivery Topology (Chapter 3): units that "ship rapid improvements within a bounded area but are neither expected nor designed to contribute to other, perhaps higher-value work beyond it." If AI makes them ten or a hundred times faster at their bounded work, will there be enough valuable search or payments work to fill their capacity? Almost certainly not. But if they're structurally mandated to keep working on that thing — because "it's faster if a search team works on search" — there won't be any system-level gain. The team is optimizing locally while the organization stays flat. This is the Ferrari Effect (10X ORG, Chapter 2): adding faster engines to a jammed highway doesn't fix congestion. As Principle 3 of the book puts it, "mandates determine the maximum complexity the organization can handle. If mandates are narrow, the organization can only solve narrow problems, and anything broader turns into dependencies, coordination meetings, and delayed decisions." Multi-learning — people and teams expanding beyond their primary craft, building capabilities across domains — is no longer a nice principle to put on a slide. It's what Principle 8 of 10X ORG calls "Embed Multi-Learning": a structural requirement, not a training initiative. Without it, AI augmentation gives you a local efficiency gain, not a compound, org-wide one. You get 1X, not 10X. The Part Nobody Tells You Here's the twist: multi-learning is not new. In 1986, Takeuchi and Nonaka published "The New New Product Development Game" in Harvard Business Review — the paper that later inspired Scrum. They studied Honda, NEC, Canon, and others. The teams that produced breakthrough products weren't narrow specialists. They were multi-learning teams, people with depth who also developed capabilities across domains. They followed value and they learned while delivering. That was forty years ago. Most organizations ignored it, or paid lip service. They took the Scrum part — the ceremonies, the roles, the cadence — and left the multi-learning part on the table. Too hard, too expensive, too disruptive to career ladders and HR policies that reward growth within a single funnel. As 10X ORG puts it: "learning has traditionally been treated as a cost to minimize, not a capability to grow." The agile homework was never about standups and sprints. It was about building organizations where people can learn, follow value, and contribute beyond their job description. The companies that did this homework — that embedded multi-learning as a structural principle, not a training initiative — those companies know how to handle AI. They already have the muscle: broader mandates, cross-boundary work, people who are allowed and expected to grow beyond their current role. They don't need to panic. They need to accelerate. Must-Shaping M-shaped people. Not T-shaped — that was the polite version. Multiple strokes of depth, connected by the ability to learn across boundaries and contribute wherever the value sits. This is not optional anymore. This is must-shaping. AI democratizes knowledge and skills, making it easier for people to go beyond their primary craft. As Aiden — the AI character in 10X ORG — explains: "tutors, copilots, and research agents make multi-learning practical in weeks and days, not years. We are entering the new era of flattened learning curves." But the organization has to allow it. Traditional HR policies and career paths still reward growth within a single clearly defined funnel, and that system is becoming outdated fast. The technology is ready. The structural permission is not. So leaders need a sense of direction, and the direction is clear: broaden the definition of expertise. Allow people to learn, follow value, and use AI in ways that are still emerging. Not replacing people with AI — amplifying human intelligence with AI. 10X ORG calls this the move toward Adaptive Topology: "a network of interdependent units where adaptation doesn't require a reorganization — it is built into how these units work." The organizations that did the agile homework know this direction. They've been walking it, slowly, for years. AI doesn't change the direction. It removes the excuses for not moving faster. And the ones that faked it? They're about to discover that the AI assignment doesn't grade on a curve. The ideas in this digest come from 10X ORG — available now. If this resonated, the book goes deeper: nice principles, real case studies, and a diagnostic map to see where your organization actually sits.

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.