ORG TOPOLOGIES 

Introduction In 2022, Andrew Sales (Chief Methodologist and SAFe Fellow at Scaled Agile, Inc.) spoke at Tecnifor SAFe Day about “accelerating the flow of customer value.” You can watch his talk here . In this post, I will reflect on his ideas and share additional approaches to improving the flow of customer value systemically  within SAFe. While Andrew highlights key areas that can dramatically improve SAFe’s delivery capacity, I invite you to think beyond the immediate solutions and consider how organizational design principles—such as those found in Org Topologies™—can address the broader, root-level constraints that often limit our ability to achieve true business agility. Andrew begins by posing a critical question: “The question arises: if the (SAFe) framework has flow built-in and the teams and the ARTs are cross-functional, why do we sometimes struggle so much to deliver value seamlessly to our customers?” He then proposes eight “flow fundamentals” that will, in his view, significantly change how SAFe is practiced. Let’s examine each one, discussing potential remedies, deeper considerations, and how they align with Org Topologies thinking. 1. Visualize and Limit WIP Andrew’s Summary The value-delivery capability of a team drops as Work in Progress increases. Proposed Actions:  Make WIP visible and set strict WIP limits. Expanded Reflection and Analysis Visualizing WIP is a valuable first step that raises awareness. It helps teams see how many tasks they are juggling and appreciate the inefficiencies in context-switching. Strict WIP limits often lead to immediate improvements in the team’s throughput. Short-Term Relief : Limiting WIP on a single team can increase its output and reduce stress. Potential Pitfalls : If only one team or a handful of teams impose strict WIP limits, work might accumulate upstream or downstream, creating bottlenecks elsewhere. This local optimization can inadvertently slow down overall flow across the ART, Solution, or Portfolio. Systemic Perspective : ART-Level WIP : Consider implementing WIP limits at the ART backlog level. This broader scope forces the entire release train to confront systemic constraints (e.g., insufficient capacity, unclear priorities) that only become visible when we stop overloading teams. Organizational Design : If teams cannot handle certain types of work, it may indicate a deeper capability gap rather than merely a “too much WIP” issue. Sometimes, “limiting WIP” becomes a temporary band-aid unless you also address cross-functional skills, system architecture, and organizational structures. By integrating an Org Topologies perspective, you can decide whether to move teams “up” (broaden their scope) or “right” (expand their capabilities), ensuring that WIP constraints are part of a larger design strategy rather than an isolated fix. 2. Address Bottlenecks Andrew’s Summary Bottlenecks commonly emerge from limited shared knowledge, poor collaboration, missing discipline, or external dependencies (including delayed customer feedback). Proposed Actions:  Increase capacity at the bottleneck or replan work. Expanded Reflection and Analysis Identifying and addressing bottlenecks is a continuous challenge: Increasing Capacity Quick Win : Add specialists to the team. Although it helps clear the immediate bottleneck, it may not be sufficient if the newly introduced skill remains concentrated in a single person. Long-Term Investment : Use pairing or mobbing to distribute specialized knowledge across multiple teams. This approach takes more time but creates a more resilient system in the long run. Replanning Work Risk : Simply rescheduling tasks defers the underlying bottleneck problem. For truly valuable features, you might still need that scarce skill tomorrow. Systemic Approach : If certain types of work always require a specialized skill, consider reorganizing to embed that capability in multiple teams or reduce the scope of specialized tasks so that it becomes more feasible for additional team members to learn and take on the remaining specialized work. Moving “Right” on the Org Topologies Map Increasing a team’s capabilities (e.g., adding new skill sets) can reduce bottlenecks. However, you must also consider the frequency  of using those skills. If the skill is needed often across multiple teams, a system-level reorganization might be more beneficial. 3. Minimize Handoffs and Dependencies Andrew’s Summary Handoffs and dependencies arise when one team (or individual) must wait for another’s output. Proposed Actions:  Visualize dependencies, reorganize around value, and redesign teams or systems to reduce overhead. Expanded Reflection and Analysis Dependencies are not inherently bad. Synchronous dependencies can spur beneficial collaboration; the real issues often arise with asynchronous  dependencies or deep, specialized silos: Reorganization Paths Left/Down Move (Team Topologies) : Create streamlined groups specialized in certain components, with clear communication pathways. This can control dependencies by isolating complex components to dedicated teams. Up/Right Move (Org Topologies) : Form “team-of-teams” constructs within an ART, focusing on broader chunks of customer value. Allow them to pull work directly from the ART backlog to reduce cross-team handoffs. Balancing Complexity System Architecture : Sometimes the product architecture is the root source of these dependencies. Without architectural improvements (like decoupling components), simply rearranging teams has limited impact. Collaboration Practices : Techniques such as mobbing across teams for shared tasks can reduce repeated handoffs, but they require a culture that encourages collaboration and shared ownership. By examining dependencies through an organizational design lens, you can systematically reconfigure teams or the entire ART to ensure that integration and delivery happen at the level where true customer value emerges. 4. Get Fast Feedback Andrew’s Summary Technical feedback (e.g., ensuring the product is built correctly) and customer feedback (e.g., ensuring we build the right  product) are both crucial. Broken feedback loops lead to rework, technical debt, and dissatisfaction. Proposed Actions:  Investigate which type of feedback is missing, shift left for technical feedback, and practice CI/CD. Expanded Reflection and Analysis Technical Feedback Emphasize code reviews, pairing, mobbing, and continuous integration to detect problems early. Adopt automation tools, including AI-assisted testing, to speed up cycles. Customer Feedback SAFe typically provides a big feedback window every Program Increment (PI) (often every 10-12 weeks). This might be insufficient for highly dynamic markets or fast-evolving products. Encourage more frequent integration and demonstration at the ART level or higher, rather than strictly by individual teams. Systemic Dimension If multiple teams are required to deliver a customer-facing increment, ensure they can frequently integrate their work. Shrinking feedback loops often requires changing organizational structures that slow decision-making or add bureaucratic gating steps. In Org Topologies terms, moving “up” can mean giving teams a broader scope so they can test and demo an entire feature or sub-product to the customer in real-time rather than waiting for a separate integration phase. 5. Work in Small Batches Andrew’s Summary Large batches create long feedback delays and increase the risk of rework and unpredictability. Proposed Actions:  Align story size to iteration, feature size to PI, and consider smaller release, integration, or customer batches. Prioritize enabler work to improve automation. Expanded Reflection and Analysis Most practitioners agree on the efficiency gains from smaller batches: Practical Constraints Some organizational policies or regulatory environments may enforce “big batch” releases, slowing feedback. Challenge these policies if possible or design intermediate validations to emulate smaller batch feedback. System Design Splitting work into tiny pieces is only helpful if teams can actually deliver those pieces end-to-end. If siloed functions (e.g., QA, security) come in late, you still end up with a large integration batch. Consider a vertical “up” move: enabling teams to own features at the business-problem level. They can slice user journeys or epics in small increments that are still meaningful  to the customer. When small batches become the norm, flow accelerates. But do not forget that it often requires not just rethinking iteration planning, but also evolving the architecture and team compositions so that integration is continuous and frictionless. 6. Manage Queue Lengths Andrew’s Summary Queues represent committed work. Long queues mean long wait times for customers and diminished agility. Proposed Actions:  Avoid overcommitting to future PIs, reduce informal (untracked) work, and focus on what’s promised. Expanded Reflection and Analysis SAFe Context Enterprises implementing SAFe often value predictability, which sometimes conflicts with the unpredictable nature of software development. Balancing “enough predictability” with the need for agility is a tricky but necessary conversation. Systemic Insight Managing queues effectively might mean reducing the number of backlogs altogether. Many organizations have separate product, team, and portfolio backlogs, each adding overhead and friction. If teams within an ART can collaborate on a single ART backlog, they can rapidly respond to emergent, high-value requests without the inertia of multiple queue handoffs. By removing or combining backlogs, you reduce the communication overhead. This is a significant organizational design shift that can pay dividends in responsiveness and alignment. 7. Optimize Time in the Zone Andrew’s Summary “Being in the zone” refers to focused, deep work essential for complex tasks. Excessive meetings, events, and context-switching undermine productivity. Proposed Actions:  Question the necessity of certain meetings, keep WIP low, and leverage pairing/mobbing to reduce handoffs. Expanded Reflection and Analysis Meeting Culture Identify which meetings are truly indispensable for alignment or decision-making and streamline or eliminate the rest. Consider a “meeting-free day” policy or carefully structured meeting blocks to give teams uninterrupted blocks of time. Beyond WIP Limits If a team’s backlog is a mix of unrelated tasks, limiting WIP will help to some extent. However, the deeper cure is to provide teams with a cohesive scope (e.g., a full feature or business capability). Pairing and Mobbing These can rapidly spread knowledge, reduce dependencies, and create shared ownership. They also cut down on the need for status meetings since the team is aligned in real time. Viewing these improvements through Org Topologies might lead to restructuring roles or merging backlogs so teams spend more time innovating and less time “managing the process.” 8. Remediate Legacy Policies and Practices Andrew’s Summary Old habits can sabotage a modern SAFe implementation by reintroducing silos or extra layers of bureaucracy. Proposed Actions:  Identify and address these obsolete patterns. Expanded Reflection and Analysis Identifying Legacy Issues Legacy often hides in approval chains, governance rules, and organizational hierarchies that are ill-suited to agile flow. Tools like value-stream mapping in combination with the Org Topologies map can reveal how outdated practices obstruct effective collaboration. Changing Mindsets This is often the hardest part. People who grew accustomed to certain processes or organizational structures may feel uneasy abandoning them. Emphasize system-level outcomes, focusing on how an outdated policy slows flow or increases waste. Educational and Cultural Shifts Offer training or workshops on systems thinking and Org Topologies so that teams, managers, and executives understand how local decisions affect overall flow. Encourage experimentation with new practices, such as cross-functional “team-of-teams” or short, frequent planning cycles, to replace rigid, outdated methods. Conclusion Andrew Sales’ eight flow fundamentals offer a solid starting point for enhancing SAFe’s effectiveness. However, improving flow at scale requires a holistic  approach that looks beyond the immediate fixes—like limiting WIP or planning around specific bottlenecks—to address deeper organizational structures and cultural norms. Systemic Thinking: Embrace Russell L. Ackoff’s insight: “the performance of a system depends not on how the parts perform taken separately, but on how they perform together as a whole.” Focus on end-to-end flow (ART, Solution, Portfolio) rather than on isolated improvements within individual teams. Organizational Design: Consider how you can “move” across and up the Org Topologies map to expand teams’ capabilities or give them more business scope. Aligning on a single backlog at the ART level, merging teams into a “team of teams,” or embedding specialized skills across multiple squads can all be powerful levers to achieve sustainable flow. This article is an invitation to re-examine how your organization delivers value and to unify teams around shared goals. By integrating Andrew Sales’ flow fundamentals with a systemic organizational design perspective, you can create lasting improvements in your SAFe implementation—without losing the framework’s structural benefits.

Eurecat – FPED background Eurecat is the Technology Centre of Catalonia in Spain, dedicated to research and development of technology for business and industry. Eurecat operates across various fields of research and innovation, including Big Data, robotics, biotechnology, advanced materials, and sustainability, with the goal of helping companies become more competitive through technology adoption. The FPED unit (Functionalization, Printing, and Embedded) focuses on researching and developing new manufacturing processes and techniques to enhance the functionality and properties of plastic and composite materials, optimizing their production and industrial applications. This includes innovations in more sustainable and recyclable materials or materials with added functionality in finished products. Our First Contact In our initial discussions, some FPED unit leaders expressed a need for change. They were looking for ways to adapt better to an ever-evolving environment and felt that Agile methodologies could help them navigate uncertainty. With our goals aligned, we decided to introduce Agile and Scrum concepts through a training session (a non-certified version of my Certified ScrumMaster training) for all unit members. The training was a success, with most participants leaving eager to implement the new ideas they had learned in their work. Not long afterward, I arrived at their Mataró offices to help them begin their transformation. What I found When starting an Agile transformation, I like to spend the first few days learning everything I can about the organization I’ll be working with, and this time was no exception. Through this discovery phase, I gained a clear understanding of the current organization of the unit. The head of the unit (a W1 “functional whole business focus” individual) was responsible for establishing the high-level roadmap in alignment with the unit’s strategic vision, managing the budget, and ensuring timely completion of all administrative procedures (including human resource management, bid submissions, and grant applications). The unit’s various research initiatives were divided across four work teams, known as R&D lines (PSA or Printed Sensors & Actuators, SME or SMart Engineering, PHO or Printed Photonics and IME or In Mold Electronics), each led by a Head of R&D line: The Head of R&D line acted as the team’s representative on the executive committee, which met periodically with the head of the unit to report on the progress of various initiatives and to plan future efforts (new initiatives, proposals, conferences, etc.). They were also responsible for preparing new proposals (sometimes with help from a researcher) and for managing stakeholders and their expectations, including holding progress meetings, sending updated documentation, or providing live demonstrations. For each of the R&D lines, they could be classified as P1 “functional partial business focus” individuals. Each R&D line’s researchers conducted R&D work for different initiatives. However, despite being part of a supposed "team," work on each initiative was largely individual, with each researcher in charge of a set number of R&D initiatives (performing all the planning and research/develop tasks needed for each initiative) and minimal collaboration between them except for a small number of their R&D initiatives. At best, we could be describing them as F1 “incomplete multi-skill feature focus” pool, with some characteristics of, or at some times performing as, a team. Additionally, a Transversal Team (T1 “functional task focus” pool) supported the four R&D lines by performing highly specialized technical tasks. However, the way this team managed requests often led to delays and bottlenecks, slowing down the R&D lines’ workflow. - Img 1: Initial state of Eurecat-FPED unit - (Note: version 092024 used for this Case Study) A summary of FPED’s journey Rather than detailing every aspect of the Agile Transformation at the Eurecat- FPED unit, I’ll focus on the main actions that helped the unit evolve: Agile and Scrum training: As a Certified Scrum Trainer, I provided an Agile and Scrum training for all the Eurecat-FPED staff, showing them how the Agile way of working and the Scrum framework could help them achieve their goals in a very challenging environment. Scrum Masters (SMs): As the Agile Coach leading this transformation initiative, I wanted them to have one Scrum Master for each R&D line, but a mix of reasons, including the budget for the transformation and the high number of ongoing R&D initiatives in each line, made this impossible. That’s why only two researchers were selected to become part-time SMs. Although this slowed the transformation compared to my initial plan, the changes were better received by the Eurecat-FPED members, as they had more time to learn and implement the new ideas. Agile Change Team (ACT): We created an ACT with a mix of roles from the Eurecat-FPED unit (the head of the unit, the two SMs as Agile experts, a pair of Head of R&D lines, and several team members). This team, using the WaGI Diagram ( http://thewagidiagram.com/ ) , developed a Transformation Backlog and began working with the R&D lines to adopt new management practices and to foster an Agile mindset and way of working. Head of R&D line Role Transition: Initially, Head of R&D lines managed every detail of the initiatives and the R&D lines, but they began transitioning into Product Owner-like roles. Given that each R&D line had more R&D initiatives ongoing than team members (often more than double), and it was impossible for them to manage such number of Product Backlogs, the Head of R&D lines started to delegate some of their responsibilities to the team. This way, the Head of R&D lines were able to focus on executive committee duties, proposal development, prioritization of the Product Backlogs and key stakeholder management. Real Teamwork Within the R&D lines : A major effort was made to introduce and adapt Scrum to their context, moving from a setup where each initiative was handled individually by a single researcher to one where the R&D line members, like a "swarm," collaborated on the ongoing initiatives from their R&D line. This shift improved quality and reduced risks associated with the previous model’s lack of redundancy (the "bus factor"). Sharing the knowledge of the Transversal Team: The Transversal Team began mentoring team members from the different R&D lines so that they would have the knowledge to perform their tasks. Due to the capacity of the machines involved in their work, to improve efficiency the Transversal Team members would be involved in the planning and performing of those tasks, pairing with R&D lines team members. Implementing Agile Ways of Working (WoW) in the Transversal Team: The Transversal Team began developing a Kanban-based approach to serve the R&D lines more effectively, reducing the interruptions that had previously caused delays. The present Thanks to the transformation within the Eurecat-FPED unit, the team’s natural adaptability to changes has increased. They are now better able to manage both internal changes (such as staff turnover and absences) and external challenges (like pandemics, new research fields, or new clients). While the unit’s configuration may look similar from the outside, the internal dynamics have shifted: while the head of the unit official responsibilities may appear unchanged, and we would still classify him as a W1 “functional whole business focus” individual, his leadership style has evolved significantly. He now grants more freedom and flexibility to the R&D lines, delegating decision-making authority to those closest to the work, resulting in a noticeable reduction in his stress. The reorganization of the R&D lines has created four distinct teams (PHES, for Printed Health and Environmental Sensors, SME for SMart Engineering, IME for In Mould Electronics and PED for Printed Energy Devices) in which members are now more engaged, effectively collaborating, sharing experiences, and taking on Product Owner responsibilities. Head of R&D lines now function as team members rather than their bosses, focusing mainly on stakeholder management and coordinating proposals for new initiatives within their R&D lines. This have led them to become, from a sum of a P1 “functional partial business focus” Heads of R&D line, and an F2 “incomplete multi-skill feature focus” researches teams, to a P3 “complete end-to-end partial business focus” teams. And even when the Transversal Team is still a T1 “functional task focus” pool, as they have shared their knowledge with the R&D lines and they are using an Agile Kanban approach, interactions are now smoother, reducing the disruptions that previously slowed down the R&D lines progress. - Img 2: Current state of Eurecat-FPED unit - (Note: version 092024 used for this Case Study) And the future? In the coming weeks, Eurecat-FPED’s SMs are planning an event for the entire unit—a retrospective-like event—to review their transformation journey and explore what the future may hold. While the future remains uncertain, one thing is clear to me: if the Eurecat- FPED teams continue performing, learning, evolving, and pushing their boundaries as they have done so far, they are headed toward a bright future filled with success. Conclusions An Agile Transformation, in theory, has the potential to elevate an organization toward the upper-right corner of the Org Topologies Map, where teams improve their capabilities and gain a more comprehensive view of the work, ultimately leading to better decision-making. In Eurecat-FPED’s journey, we’ve observed this progress. As the team matures in Agile mindset and practices, they are finding a new organizational design that enhance decision-making and reduce previous challenges and risks. Using the Org Topologies Map at this stage allows Eurecat-FPED to acknowledge their achievements and envision the future: Should the R&D lines continue evolving toward W4 (multi-learning with a whole-business focus)? What should they change to reach that point? We’ll see, and the Org Topologies framework will help us understand their progress along the way! 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 Raul 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 Eurecat-FPED Case Study: Agile and Scrum Training as a Foundation Introducing Agile and Scrum principles and continuously reinforcing them established a routine of ongoing learning. This laid the groundwork for more adaptive ways of working and set a pattern of iterative improvement across the entire unit. Agile Change Team (ACT) and Transformation Backlog Creating an Agile Change Team composed of diverse roles and utilizing a transformation backlog (informed by the WaGI Diagram) is a structured, repeatable process to prioritize and implement improvements. Over time, the ACT regularly revisits goals, updates the backlog, and encourages an iterative approach to organizational change. Head of R&D Lines Transitioning Toward Product Ownership Rather than top-down control, Heads of R&D lines repeatedly practiced delegating responsibilities and focusing on stakeholder management and strategic prioritization. This shift, repeated and refined over multiple cycles, helped the organization progressively align leadership roles with Agile principles, reinforcing a more responsive and value-oriented governance structure. Evolving from Individual Assignments to Collaborative “Swarming” Teams moved from isolated, researcher-specific initiatives toward collective responsibility and collaboration. By regularly practicing “swarming”—where team members co-own tasks—R&D lines elevated teamwork, increased knowledge sharing, and reduced risk. Repeatedly applying this approach reinforced a culture of continuous improvement and adaptability. Sharing Specialized Knowledge Across Teams The Transversal Team began mentoring and pairing with R&D team members, transferring knowledge and reducing bottlenecks. This routine of pairing and skill-sharing evolved over time, establishing a kata for capability-building and enabling more resilient, multi-skilled teams. Implementing Agile Ways of Working (WoW) in the Transversal Team (Kanban): Introducing a Kanban system and continuously refining it to better serve the R&D lines became a kata that improved flow, reduced interruptions, and ensured smoother cross-team interactions. Iterating on the Kanban approach reinforced an ongoing cycle of measuring workflow, identifying bottlenecks, and making incremental improvements. More on Elevating Katas here .

Introduction ‭ An organization with a physical product, including a lot of (embedded and connected)‬ software - internally developed and manufactured - desires to elevate their product‭ development towards a more end-to-end approach, moving away from technology-focused‬‭ teams towards teams of teams with an end-to-end focus. Their journey identifying the‬‭ optimization goal of more end-to-end focus with better options to change direction started‬‭ with systems thinking by‬‭ system modeling‬‭ their current‬‭ situation and identifying their‬‭ optimization goal. Additionally, the system modeling revealed the root causes limiting them‬‭ from reaching their true potential.‬ ‭One of the important aspects in their journey is to redesign teams, while having certain skills‬‭ in multiple teams to be able to develop and maintain shared technologies or components in multiple teams. Org Topologies was used to analyze (and reconsider) the elevation that was‬‭ already designed based on the systems thinking, and resulted in the discovery of which shared‬‭ skills and technologies should be included in multiple teams. This case study will focus on‬‭ the discovery of the shared skills and technologies, and not on the full MADE of the product‬‭ organization.‬ ‭ Context and Challenges‬ ‭The organization has a rich history of developing and manufacturing physical products, and has grown‬‭ over time by merging several organizations across countries. In the last decades the aspect‬‭ of software became bigger, and now the physical products not only contain software, they‬‭ are also connected and need to work in an ecosystem with user interfaces (such as an app).‬‭ Common challenges of larger organizations are present, like developing and maintaining‬‭ multiple products, consistency across different production sites and countries, as well as‬‭ keeping up with new developments in technology. Historically, the use of software in their‬‭ products grew and at some point was brought centrally, having to deal with balancing the‬‭ commercial needs as well as the ability to maintain and stay adaptive to change. The focus‬‭ of the case study is on the department that creates all software for the physical products as‬‭ well as part of the hardware related to the software (e.g. print cards). The department has a‬‭ common organizational design - the first topology - with teams focusing on part of the‬‭ technology (software and/or hardware), while the physical product contains these parts‬‭ working together. The main challenge is to be able to deliver in a decent time as well as to‬‭ be able to change the products to stay competitive.‬ ‭Map & Assess‬ ‭A simplified Map & Assess visualization (some teams are combined, some teams are left out‬ because they are less relevant for the core message of this case study) for context shows‬ ‭that there is quite a lot of alignment (in PART-1 & PART-2) needed before desired features or new product variants would move to mainly functional and multi-skill teams (in CAPS-1 &‬‭ CAPS-2), leaving these teams with a lot of dependencies and unclarities about actual‬ ‭higher-level priorities. The yellow PART-2 teams are business teams that capture the‬ ‭physical product and are the main stakeholders for the software of the physical product for‬ ‭the department. The map shows the following:‬ map and assess with Org Topologies This organizational design was optimized for local lead times, and a result of bringing‬ ‭technical skills that were more individually focused together in functional or sometimes‬‭ CAPS-2 and TASKS-2 multi-skilled teams. This led to improved knowledge sharing, reduced‬ ‭dependencies and reduced redundant components. This was a big improvement at the time,‬ ‭but when their environment got more complex (technology and dynamics of the market),‬ ‭more demands from customers & markets came forward, the limits of this organizational‬ ‭design became transparent. Some teams included more skills in their team design and could‬ ‭deliver some less complex features themselves, but most teams were attached to specific‬ ‭parts of the technology.‬ ‭Additionally, the vision & products of the department were not in sync with the markets and‬ how the rest of the organization is organized. The connections between the other‬‭departments, the inside department product managers, and the teams showed many‬ ‭dependencies and lack of end-to-end focus. This made it hard to align with the‬ ‭organization’s broader objectives. The teams have a ‘Product Owner’, who was mainly busy‬ ‭with aligning and making sure requirements were understood by the team.‬ ‭The connections of certain teams became very transparent with the Map & Assess exercise.‬ ‭With the already intended move - based on the root causes and optimization goal of the‬ ‭systems thinking - the learning was to have certain shared skills and technologies in multiple‬ ‭teams (or team of teams). The mapping shows very clearly teams 5 & 6 having to connect to‬ multiple other teams. Mapping the main connections for teams and the needs and‬ ‭dependencies for skills and technologies of other teams proved valuable for identifying the‬ ‭shared skills and technologies as input for the new design.‬ ‭ ‭ Within several of the teams there were skills that in the new situation will be used by multiple‬ ‭teams, though not as important as the skills and technology from these teams for the overall‬ ‭optimizing goal. Therefore, those details are left out of the visual representation.‬ ‭ Design‬ ‭The post-mortem Design showed an approach to optimize for end-to-end capability, moving‬ ‭away from technology-focused teams towards elevated teams of teams with an end-to-end‬ ‭focus (CAPS-3). Additionally, the prioritization and alignment will be optimized in 2 ways:‬ ‭simplifying the authority on priorities to 2 Product Owners (PART-2) and connecting the‬ ‭Product Owners both to the markets that are strategically identified to focus on, which is also‬ ‭where the rest of the organization is organized towards (PART-2 teams from other‬ ‭departments). The - simplified - desired organizational design is visually represented below.‬‭ design with Org Topologies Good to note that the elevated team of teams still has 1 or a few Product Owners additional‬ ‭to the Product Owner in the visual representation, which they call an ‘area’ Product Owner.‬ ‭The Product Owner of the map prioritizes on higher level, while the area Product Owners‬ ‭take the higher-level prioritization one step further towards the more detailed priority for an‬ area (usually 2 or 3 teams per area). There are much less Product Owners compared to the‬ ‭initial situation, and in many cases multiple teams per Product Owner representing an‬ ‭(close-to) end-to-end area of work. The team of teams are mapped as an end-to-end‬ ‭archetype, because the scope of skills mandate is within the market and area they are in.‬ ‭Over time, they want to move more to the expanding archetype, integrating technologies and‬ ‭moving to a real team of teams with fewer Product Owners, ideally 1 Product Owner per‬ ‭distinguished strategic market orientation. Simplifying authority on priority‬ ‭In the current situation, the decision-making and stakeholder involvement is not consistent‬ ‭with the strategic focus of 2 markets, and this leads to many dependencies and a lack of‬ ‭end-to-end focus. The inside-department Product Managers are still there (one of them will‬ ‭become one of the two visualized Product Owners), however the interaction and authority of‬ ‭their role changes. They will be focused on understanding the market and customers, but‬ ‭have no decision-making on priority. Second, the Product Owners have an (increased)‬ ‭end-to-end focus and are matching the market orientation and organizational design of the‬ ‭rest of the organization. Therefore, it will be easier for them to create a vision together and‬ ‭decide on priorities.‬ ‭ Team of teams with end-to-end focus ‬ ‭The new Design consists of two elevated teams of teams with an end-to-end on the‬ ‭strategically identified markets (CAPS-3). Both teams of teams should include all relevant‬ ‭skills and technologies needed for those markets, though some of these will stay in one of‬‭ the teams of teams initially (due to technological constraints or limited amount of knowledge‬ ‭available). Additionally, the platform teams are re-oriented to work closer together, though‬ ‭not changing structurally yet. The strategic direction there is to have a future-proof platform‬ that will help deal with many dependencies and long-term sustainability. This is a‬ ‭technological elevation to improve the product quality.‬ ‭It’s good to reflect whether the teams of teams have a capability scope of work mandate,‬ and not a partial business scope of work mandate. The teams of teams are both still‬ ‭attached to a certain capability, though more end-to-end. They are not expected to learn or‬ ‭grow broader towards a partial business, as the Product Owner and business stakeholders‬ are expected to provide this overview. This makes them still attached to a certain capability.‬ ‭The other reflection is whether teams are end-to-end or multi-skilled. It depends on the reality‬ ‭after moving in this direction. The purpose is end-to-end, but quite some elevations need‬ ‭to happen to ensure this will be a reality, like technical excellence and including end-to-end‬ ‭testing in the team of teams and more.‬ ‭ The teams of teams will have a broader scope of skills mandate, working from a single‬ ‭Product Backlog for the end-to-end capability. This incentivizes improving the end-to-end‬ ‭capability, to improve the feedback loops, end-to-end testing, support, collaboration on work‬ ‭, and more. One important part of this change is to have teams, stakeholders and other roles‬ ‭work together earlier in Product Backlog Refinement, enabling expertise knowledge in an‬ ‭earlier stage, shorter feedback loops and better whole capability understanding for the‬ ‭teams, which should lead to solving the customer problems better ultimately.‬ ‭ Shared skills & technologies‬ ‭In the new Design certain skills and technologies are in all teams of teams and in some‬ ‭cases in multiple teams all together. The visual representation shows the merge of the‬ ‭separate display software and connectivity teams into the teams of teams. Part of the‬ ‭technology related to connectivity moved to the platform team. Additionally, some smaller‬‭ shared components and technologies are the responsibility of both teams of teams, while‬ ‭re-using these shared parts for both markets. This leads to a broader focus of the teams,‬ ‭less dependencies and new incentives to optimize for the broader products or capabilities.‬ ‭ Elevation‬ ‭There are several elevating kata’s applied to move towards the desired Design, amongst‬ them:‬ the expansion of the product definition‬ merging Product Backlogs‬ shared Definition of Done‬ redesigning to broader scoped teams‬ bring teams close together to collaborate as a team of teams‬ ‬and more.‬ ‭ The focus on the shared skills & technologies identifies the need for the elevating kata of‬‭ shared ownership of components or technologies (and shared functionality from a business‬‭ perspective as well). Elevating towards this is hard in practice, since there are historical,‬‭ process, technological and mental constraints to be able to achieve this.‬ ‭To enable shared components or technologies, technical improvements need to be in place,‬‭ as well as organizing learning and collaboration. For the technical improvements, most‬‭ important is to assess the current situation and determine what is needed to be able to, e.g.‬‭, with an‬‭ improvement kata‬‭ to make small steps forward‬‭ to the end goal. Depending on the‬‭ current situation, improvements often include a shared version control system across‬‭ components, continuous integration behavior (and related branching strategy) and‬‭ preconditions to make that happen, quick feedback loops with automated tests and‬‭ improving the architecture or design of the product(s) to simplify for shared work. For‬‭ organizing learning and collaboration, a shared Product Backlog with a common way of‬‭ working across the teams is a starting point. On top of that, organizing knowledge across‬‭ teams in communities, encouraging teams to talk to each other when needed and help them‬‭ to identify when to work synchronously together are among the practices that can help‬‭ elevate to shared components and technologies. These improvements typically also lead to‬‭ other elevations, like shorter feedback loops to customers and understanding the whole‬‭ product.‬‭ ‭Conclusion‬ ‭This case study highlights the journey of a complex product organization shifting from‬ ‭technology-focused teams to elevated teams of teams with an end-to-end focus. A key‬ ‭insight was the identification of shared skills and technologies across multiple teams to‬ ‭reduce dependencies, improve adaptability, and enhance delivery speed.‬ ‭The Org Topologies Map & Assess exercise uncovered systemic bottlenecks, including‬ ‭fragmented ownership, misaligned priorities, and high amounts of dependencies. By‬ ‭elevating towards CAPS-3, the post-mortem org design confirms the desire for an‬‭ecosystem where teams of teams could own broader capabilities while ensuring critical‬‭ technical expertise was distributed effectively.‬ Identifying shared components and technologies through MADE provided clarity in designing‬ teams and defining elevation strategies. Several additional elevating kata’s are useful to help‬‭ to move towards this desired state. Elevating shared skills and technologies is not just a‬‭ structural shift—it is a systemic transformation that requires aligned priorities, technical‬‭ enablers, and cultural adaptation.‬

I hadn’t seen Stacy in twenty years. We were in the same math class back in high school — she was the only one who actually understood what the teacher meant when he said “assume a spherical cow.” Now she’s a product manager in a government organization, running a portfolio of public-facing digital services. We reconnected after bumping into each other at a conference, and that night over curry and a shared bottle of wine, I asked her about her job. I could see the worry in her eyes before she said a word. “I don’t think I can turn this ship around,” she finally admitted. She went on to tell me about her world. Stacy is the product manager in a government organization. She manages three product owners: Oscar, Pete, and Jane. Oscar and Pete each have one development team; Jane works with two. That’s four teams total. On paper, they’re agile. They do PI planning. They have backlogs. The Jira boards are colorful and full of tasks. But the performance of their application is abysmal. New features trickle out. Budgets are tightening. And the pressure is building. “I try to get them to work together,” she said. “But it’s not happening. Everyone’s focused on their own goals. Their own backlogs. If one team hits a blocker, the others just… watch.” I asked about the product owners. “They’re committed,” she said. “But maybe too much. Everyone is locked into the deadlines we set during PI planning. It’s like once they’re on the track, no one wants to switch lanes—even if the train in front of them is on fire.” And then she told me about Pete’s analyst — the one who just quit. The only person in Pete’s team who fully understood the most obscure modeling tool in their custom-built stack. “Replacing him will be a nightmare,” she said. “Budget-wise, I don’t even know if it’ll happen. And onboarding someone new to this spaghetti tech stack? Six months at best. Assuming we find someone.” It didn’t end there. Even when a team does manage to finish something, their work is passed down like a relay baton — first to the “release team,” then the “user acceptance team,” and finally to the “implementation team. By the time something hits production,” she said, “no one remembers why we built it in the first place.” I nodded and took a sip of my wine. “So what have you tried?” I asked. She smiled — but it wasn’t a happy smile. “I tried everything that seemed reasonable. We organized ‘office days’ to bring people together. Free lunch. An interesting speaker. Sometimes we’d wrap it up with drinks or a board game night. The turnout was okay. The vibe? Polite. But as soon as people opened their laptops, it was business as usual. Jira tickets. Sprint goals. Conversations in Slack with their own team and no one else.” She leaned back and looked at the ceiling for a second, then added, “We even tried an office day without the perks — no lunch, no speaker — just nudging them to ‘work together.’ But that flopped harder. Everyone just clustered around their own squad. We were in the same building, but not together.” “Did you try any facilitation?” I asked. “Yeah, once. We brought in someone to run a session asking, ‘What do we have in common?’ and ‘What could we get out of these office days if we used them well?’ The whiteboards filled up with ideas: shared purpose, learning from each other, fewer handovers… all the usual suspects. But the moment the facilitator left, everyone slid right back into their silos.” “Why do you think that is?” Stacy didn’t answer right away. Then she shrugged. “I think everyone’s just… doing what they’re set up to do. Their goals are team goals. Their deadlines are their own. If someone from another team struggles, it’s not that they don’t care — it’s just that helping them would mean falling behind on their own commitments.” She sighed again. “And don’t get me started on the sprint reviews. Each team is working on such a small slice of the product that stakeholders either don’t show up, or they sit there wondering what it all means. ‘We updated the schema for the scheduling component’—great. But if the release team, user acceptance team, and implementation team haven’t done their part yet, no one sees the change in production for another month. The reviews feel more like internal updates than real demos of value.” She paused and then went on, her voice tinged with frustration. “I also tried to emphasize to the teams how important it is that they keep delivering. I wanted them to understand that their velocity needed to be more transparent, so we could all see where we were. But that didn’t quite go as planned. Teams started enforcing stricter definitions of ‘ready.’ If something wasn’t fully fleshed out — a user story wasn’t completely clear, or the design wasn’t handed to them before they started — they’d just push it back. It’s like they were holding everything up until the very last detail was nailed down. We’re still not getting value delivered faster, because now, everyone’s focused on making sure everything is perfect before they start. It’s like they’re waiting for the green light that never comes.” She glanced around the restaurant, lowered her voice “And now there’s this new issue. The product needs 24/7 support — we’re talking public-facing, critical services. But none of the teams knows the whole system, either in terms of functionality or the tech stack. Their scopes are just too narrow. So when something goes wrong at 3 AM, it’s always a mad scramble to find someone who might be able to help. No one wants to be on call four nights a week, even if they’re paid for it — especially not when it’s for parts of the system they barely understand. Sharing the burden doesn’t work when no one has the full picture.” That’s when I pulled out my notebook. “Can I draw you something?” She raised an eyebrow. “You’re going to draw?” “Don’t worry, no cows this time,” I said, flipping open my notebook. I sketched a horizontal line. Then I drew four dots across the line and labeled them 1, 2, 3, 4 — like levels of maturity, but not in a judgmental way. More like, different modes of how organizations structure their teams in relation to their product. “This is from something called OrgTopologies,” I explained. “It’s a way to map how your teams are organized around the product they’re building in terms of how work flows, where ownership lives, and how knowledge is distributed.” Stacy leaned in. “Type 1,” I said, pointing to the left, “are organized around functions or specialties. Think: frontend, backend, testers, release team. Value flows through handovers. Type 2 are multis skilled but unable to deliver end to end.” She nodded. “That’s basically us. We have cross-functional delivery teams, but they still rely on the release team, user acceptance team, implementation team...” “Right. And your teams don’t feel connected to the outcome, because delivery is decoupled from value. Now”—I moved my finger across the line—“Type 3 and 4 is the other end. You’ve got teams that own entire slices of the product, end-to-end. From customer insight to running code in production. Minimal handovers. Direct feedback. Deep context.” “I want that,” she said immediately. Then caught herself. “Or… I think I do?” “You probably do,” I said. “But it’s not about jumping from 1 to 4 overnight. It’s about making your current setup explicit, and deciding where you want to go on purpose. The problem isn’t your people. It’s the design—technical and organizational—that makes the behavior you see the most reasonable thing they can do.” She sat back. Quiet for a moment. “I kept thinking we had a culture problem,” she said. I flipped to a fresh page. “Let’s try to place your teams,” I said. “Where would you say each team sits in terms of autonomy and value delivery? Think about how much of the value stream they own — from idea to working product in production.” She considered for a moment, then pointed to the first lane. “Oscar’s team… probably somewhere between 1 and 2. They build features, but everything goes through the release team afterward. And they rely on user acceptance before anything can move.” I placed a dot in the 1–2 range. “Pete’s team?” I asked. She frowned. “They were maybe a 2, but now that the analyst’s gone? More like a 0. They’ve lost a ton of domain knowledge. They’re hesitant to touch anything outside their narrow component.” We mapped out the rest. Jane’s teams were similar: technically cross-functional, but in practice, tightly scoped to specific subsystems with lots of downstream dependencies. When we were done, the picture was clear. All four teams clustered around the 1–2 zone — functionally capable, but structurally constrained. Handovers, limited product ownership, long feedback loops. “This,” I said, tapping the page, “isn’t dysfunction. It’s design. Your teams are doing exactly what their environment optimizes them to do.” “So how do I get to 3? Or 4?” she asked, already drawing arrows toward the right side of the diagram. “Not all at once,” I said. “But we can look for one thing. A crack in the wall.” I drew a circle around one of Jane’s teams. “Suppose we chose one team — maybe one of Jane’s — and redefined what ‘done’ means. Instead of stopping at ‘code complete,’ what if we gave them ownership through to production? Not in a big-bang, ‘you own everything now’ way, but just for one flow, one experiment. Could we remove the release team handover for that?” Stacy looked hesitant. “They’d need more support. More tooling. Maybe even a direct line to stakeholders.” “Exactly. But imagine the impact. Faster feedback. Direct learning. A different kind of sprint review — one where stakeholders actually see value released. One example of what good could look like.” She nodded slowly. “Okay. I can see that.” “And while we’re at it,” I added, “we can start building shared context across teams. Not with icebreakers or pizza, but by looking at how we have set them up.” I turned the napkin sideways and drew the same horizontal line — this time with an Y, A, B, C spectrum. “This axis,” I said, labeling it scope of mandate, “is about what the team is allowed to do. At the bottom, teams get handed tasks. Their job is to build features, close tickets, hit deadlines. They’re told what to do.” I paused, then drew a small dot in the lower-left quadrant. “Here’s a typical team in a government setup: lots of oversight, lots of process, not much room for initiative. Even if they spot a better way to solve the problem, they’re not really allowed to change direction.” She nodded slowly. “And up here,” I said, drawing toward the top, “you’ve got teams who are trusted to solve problems. They’re given an outcome to achieve — like reducing waiting time for citizens or improving accessibility — and they have the freedom to figure out how.” I boxed in a dot in the upper-right corner. “Moving to the right is about integrating all the skills you need to create fast feedback — owning more of the product end-to-end. But moving up is about shifting from finishing tasks to solving real problems. It’s not just about speed, it’s about outcomes.” Stacy stared at the napkin. “So you can have a fast team… that’s still working on the wrong thing,” she said. “Exactly,” I said. “You want teams that can move fast and know where they’re going — because they helped chart the course.” She leaned forward, scribbling notes on a napkin now. I smiled. The ship was starting to turn.  It didn’t happen overnight. But over the next few weeks, Stacy started making changes. Small ones, careful ones — nothing revolutionary. Just enough to test whether the walls could shift. Then, three months later, she called me. I could hear it in her voice before she said a word. “I don’t know if this is working,” she said. “I feel like I’m losing them.” She’d made progress — real progress. Releasing and user acceptance were no longer separate handovers. Those steps had been integrated into the teams, thanks to support from a forward-thinking release manager and some allies in testing. Implementation was still a separate function, but Stacy said that made sense for now: those folks worked directly with field offices, training staff and preparing internal communications before anything went live. Their involvement couldn’t just be absorbed overnight. “The problem,” she said, “is getting the teams to work together.” She explained that her product owners were starting to push back — saying the extra coordination was interfering with their goals, making it harder to hit deadlines. Worse, HR had come knocking. Apparently, some developers had filed complaints. One said she was forced to learn parts of the system they’d never worked on before, written in languages they’d never even heard of. Another said it wasn’t fair — that some of the code was owned by a different department, and they couldn’t even get access. “And then one person told HR they might quit,” she added. “He said if this hurts his chances of getting promoted to a senior dev role — which he thought was about becoming the expert in one thing — then he’s out.” I paused, letting that sink in. “You’re running into exactly what you should expect,” I said gently. “You made a structural change. That’s a great start. But the rest of the organization has to move too. HR needs to understand what it means to support T-shaped— skill growth. Promotions shouldn’t just reward depth in one area. They should reward versatility, learning, problem-solving in context. Otherwise, you’re sending mixed messages: we want collaboration, but we only promote specialization.” She sighed. “I thought structural change would be the hard part,” she said. “Turns out culture doesn’t just shift because you redraw the boxes.” “Right,” I said. “Because structure and culture feed each other. If teams still operate in isolation, culture will default to local optimization.” “Still,” she said, “I was hoping they’d at least start collaborating more. Even just a bit.” “Let me ask you something,” I said. “Do your product owners still maintain separate backlogs?” “Yes,” she said. “One per team. Why?” “And do you do any kind of multi-team refinement? Like a shared product backlog refinement session?” “No,” she said. “Each team handles their own.” She exhaled slowly. “This is bigger than I thought. I’ve got a long road ahead,” she said. “But I’m not giving up.” M — Mapping the Current Org Topology Stacy’s original organizational structure aligns closely with what OrgTopologies™ defines as the Resource Topology. Her scope included oversight of three product owners (Oscar, Pete, and Jane), each responsible for one or two specialized development team. The underlying management objective was high resource utilization, not fast flow or customer outcomes. This structure created predictable silos: no single team could deliver customer value independently, and all relied on upstream analysis and downstream integration. A – Assessing the Current Org Topology Stacy’s frustrations are not unusual — in fact, they’re a predictable outcome of the organization’s current Resource Topology. Teams are structured around skills and technical components rather than around whole product outcomes. As a result, work is treated like a relay race: designed by one group, built by another, validated by a third, and implemented by yet another. This leads to fragmentation and a lack of shared ownership. No one team holds the full context, so by the time a feature reaches production, even the original intent is often forgotten. Sprint reviews attract puzzled stakeholders — or none at all — because the work being demoed is too granular or disconnected from real user value. And despite the product being a critical, public-facing system requiring 24/7 support, no team truly understands or owns it end-to-end. This isn’t due to incompetence or lack of effort. It’s an organizational design issue. In a Resource Topology, individuals and teams are grouped by role or skillset (e.g., developers here, testers there), and work flows between them. It creates clear divisions of labor but obscures product ownership. What Stacy is yearning for — cross-functional collaboration, shared goals, teams that understand and support the whole system — is better supported by an Adaptive Topology. In an adaptive topology, team structures flex around the shape of the product itself, aligning closely to user-facing outcomes. Ownership is end-to-end. Teams are empowered to not just deliver features but to learn from production and adapt based on feedback. The problems Stacy sees aren’t surprising; they’re the logical result of an org optimized for efficiency in silos, not for adaptability or product ownership. D – Design the Future Org Topology In an ideal setup, Stacy’s organization would shift toward an adaptive topology, where cross-functional teams are aligned to whole product domains rather than narrow slices of functionality or technical components. Instead of handing off work from team to team — from development to release, to user acceptance, to implementation — each team would be capable of delivering, validating, and operating the product end-to-end. This shift would support Stacy’s desire for deeper collaboration, clearer product goals, and stronger feedback loops. Rather than three product owners managing competing backlogs in isolation, each focused on their own domain, the organization would move toward value-aligned teams working within shared product boundaries. Stakeholders would engage more meaningfully because they’d be invited into a narrative that connects to real user outcomes — not just technical updates. Importantly, each team would understand not only what they’re building but why, because they’d be part of continuous discovery and delivery cycles. Their work would be traceable to real user needs and system behavior in production. This also addresses Stacy’s concern about 24/7 support: in an adaptive topology, teams that build the product also operate and support it. That sense of end-to-end ownership leads to greater accountability, system knowledge, and resilience. By moving away from the resource-based relay race and toward long-lived, outcome-focused teams with shared context and product boundaries, Stacy’s organization would be positioned not just to deliver more effectively — but to learn, adapt, and truly serve its public mission. E – Elevate the Organization Stacy had already experimented with what Org Topologies refers to as Elevating Katas—deliberate steps to help teams shift from a resource topology toward a more adaptive, outcome-oriented structure. One of her first moves was to introduce shared code ownership and a shared Definition of Done across teams, particularly trying to integrate the release and user acceptance teams horizontally. The goal was to reduce handovers and improve flow, allowing multiple teams to contribute to the same product increment with a shared understanding of quality and readiness. However, she ran into resistance. If we think of Galbraith’s Star Model, it becomes clear that while she was attempting to shift the structure—by encouraging cross-team collaboration and shared responsibility—other parts of the organization remained misaligned. The processes still reinforced sequential, waterfall-style delivery with late-stage sign-offs. Rewards systems, especially in HR, favored specialization and siloed ownership: developers were promoted for deep expertise in a narrow stack, not for cross-functional teamwork or shared delivery. There was also resistance from some senior developers who rejected shared code ownership, arguing that “the code they found was very obscure,” and expressing concern over the lack of clear boundaries or accountability. The consultant introduces a set of next-step katas that help operationalize the adaptive topology Stacy is aiming for. These include starting a multi-team Product Backlog Refinement (PBR) session to align understanding across teams, merging product backlogs to reflect a shared mission rather than fragmented initiatives, thereby gradually building teams with true product responsibility. These katas are designed not just to tweak the structure, but to bring alignment across people, processes, and incentives—so that the organization can begin to behave like a cohesive product system, not just a collection of parts. Conclusion What you’ve just read isn’t just about fixing a few broken processes—it’s a deep dive into how an organization can evolve from struggling with silos and misalignment to something far more dynamic. Stacy’s journey showcases the power of Org Topologies and agile collaboration in breaking down walls and fostering true ownership. But this transformation is messy, filled with setbacks, and far from linear. What’s clear is that the surface-level changes aren’t enough; the real shift happens when the culture begins to change with the structure. The work doesn’t end here—it’s only just begun. The style of this article aims to mirror Stacy’s journey—a blend of insights, challenges, and real-world complexity, presented in a way that mirrors the messy reality of change. Through narrative, we’ve explored the importance of agile collaboration and Org Topologies, while also underscoring the human side of transformation. My hope is that this approach sparks something in you, the reader—not just as an observer of Stacy’s story, but as a potential change agent within your own organization. Because like Stacy, the work you do isn’t just about fixing the surface—it’s about creating lasting, meaningful transformation.

AI, of course, can be used to improve the performance of individual single-skilled specialists, and this is what we see as of 2025, but there is a large landscape. Let me share. AI-Supported Org Design ("AI OD" for short) will become a hugely impactful topic affecting all of us and all the organizations in which we work. AI OD is the strategic practice of applying AI (agents and other upcoming innovations) to continuously inform, accelerate, and personalize how an organization is structured, how it evolves, and how its people learn.   It’s not about replacing managers or employees (!) —it’s about empowering us to design adaptable, resilient orgs with fewer structural overhauls and more intelligence baked into the day-to-day. ☝️The core organizing principle: AI Makes Versatile Teams Viable. ☝️ The core operating principle: With Multi-Learning as the Engine. How do these principles differ from applying AI to get individual performance gains? Let me unpack this slightly. Organizing Principle: AI Makes Versatile Teams Viable See Alexey's talk on versatility as an engine for staying relevant in the age of AI: Operating Principle: With Multi-Learning as the Engine If we unpack this principle, then we can see that this is all about applying AI to support an organization's development direction and accelerate its evolution to gain high performance and other competitive advantages. That is a strategic AI application. Some guides and practices to focus on here: 👌   #1: Multi-Learning enables Adaptivity : Especially in Adaptive Topologies (see Org Topologies Primer for details), learning—not just delivery—is the primary currency. AI enables this by making the unknown known and the unlearnable learnable, with ease. Sample scenarios: A backend developer shadows a customer support session and begins contributing to onboarding scripts. A frontline support agent learns enough Python to automate common diagnostic steps, reducing ticket escalations and easing the load on developers. An end-to-end team includes privacy review and data protection steps in their regular sprint workflow—not because they were forced to, but because someone on the team got curious, shadowed legal, and brought that knowledge back in. A delivery manager starts using AI tools like Cursor or GitHub Copilot—not to replace anyone, but to better understand how her teams are using it, what it’s good at, and the current limits. 👌   #2: Matching of Work-to-Skill in Real-Time : Rather than static org charts or disruptive reshuffles, AI supports the continuous alignment of skills to work based on live data and evolving interests, and when multi-learning is too expensive, AIs will suggest micro-reteaming without major upheaval as a temporary, quick-fix solution. We distinguish three skill-to-work matching patterns : static matching : pre-analyze and pre-plan work dynamic reteaming : reallocate people when needed multi-learning : give people the mandate to learn When multi-learning is a part of work, managers do not need to waste time and energy preplanning or reteaming. People can follow the work and learn what is necessary to achieve the expected outcomes. 👌   #3: Learning Becomes the Flow : AI agents will suggest relevant prior work and recommend 5-minute learning prompts when patterns emerge. AI agent says to a team: “Team X solved this two sprints ago.” “Want to see how testing was solved in a similar sprint?” Strategic AI in Org Design AI-powered org design harnesses AI to make teams inherently versatile and learning deeply integrated—driving adaptable, resilient organizations without the need for constant structural upheaval. This requires practicing a new mindset of seeing AI not as a tool to output more, but a strategic lever that enables humans with easier multi-learning and higher outcomes.

An essential part of organizational design is aligning demand (work) with skills (resources) effectively. What does the Age of AI change? Let's study three patterns of skill-to-work matching first. STATIC MATCHING Static Matching is the most popular approach within IT and R&D organizations. It establishes a fixed, pre-planned mapping of usually single-skilled parties to roles through clear team boundaries and responsibilities. Here, organizations set up teams with specific, narrowly defined roles. This approach is prevalent in Resource Topologies, where predictability and deep specialization drive efficiency.  Static Matching reduces uncertainty and minimizes cognitive overload by ensuring every team member knows exactly what is expected. Static Matching tends to be inflexible. When market conditions or technology requirements change, these rigid structures can become bottlenecks, forcing the organization to suffer delays while teams struggle to adapt. DYNAMIC RETEAMING The common answer to these drawbacks? Dynamic Reteaming is a reactive strategy wherein teams are reorganized on an as‑needed basis to address emerging gaps or mismatches between work and skills.  When a gap is detected—such as a critical skill deficiency or a new technology challenge—leaders may temporarily reassign or shuffle team members to patch the problem. The benefits are clear -- a short‑term quick fix that enables the organization to meet immediate demands, potentially speeding up problem resolution. Dynamic reteaming comes at a significant cost. It disrupts team cohesion, creates knowledge discontinuity, and introduces coordination overhead. Are there more strategic? Yes, thanks for asking! MULTI-LEARNING Unlike Dynamic Reteaming, which can be seen as a quick fix, Multi-Learning (ML) is a continuous, cross-disciplinary learning culture where individuals and teams regularly expand their skills and knowledge across functional boundaries. In this paradigm, teams are encouraged to go beyond narrow roles—integrating tasks like client onboarding, support, and cross‑departmental collaboration into their core responsibilities. This may involve stretching the team’s Definition of Done to incorporate outcomes that previously lay outside their remit. Advantages? ML fosters true adaptability. By building broader skill sets, teams become more resilient and capable of addressing unforeseen challenges without the need for constant reconfiguration. Limitations? Also known as ML requires a significant investment in training, cultural change, and often a rethinking of performance metrics. Without sufficient support, the burden of multi‑learning can lead to overload. AGE OF AI But in the Age of AI, these limitations are quickly softening as AI can be used as a teacher, mentor, and advisor. A multi-learning, versatile team can open a code repository they have never yet worked in and ask their AI coding assistance to describe the architecture, explain conventions, run tests, generate missing ones, and then eventually, bit by bit, build new functionality.

Any management approach that doesn’t include AI as a central part of the future workforce is of the past. We are rapidly entering a world of AI agents and humanoid robots playing a role at work and home.  Org Topologies Primer 2025 A key insight when designing with OT: Specialization and expertise are vanishing as limited resources, due to intelligence as a service . That makes it much  easier to elevate an organization! So when you are deciding on new teams requiring new expert knowledge, shed the old assumptions, “We don’t have enough experts, therefore…”. Spin up another 10,000 agents.  Evolving rightward on the horizontal axis to broader skills mandate will become ever easier due to AI. And likewise upward on the vertical axis to a broader work mandate. So, top-right Driving  archetypes will become more feasible. Obviously, “adopt AI everywhere you can” will be the general guidance, but given the limited resources of money, time, and attention, in strategic org design with OT we recommend that you ask and answer these questions: 1. What parts of the organization are the focus of development with OT?  Focus your AI investment in the area you are elevating, where competitive advantage may come from early adoption of new technology. 2. What archetypes are part of your target, and what are the major bottlenecks or constraints limiting their rapid adoption?  Find the early points where AI can make an outsized impact. 3. Do the AIs need monitoring by humans?   That implies new responsibilities and processes in your organization. We predict that monitoring  will become an important responsibility for human workers. Strategic AI Adoption: Example For example, a pet-supply company creates e-commerce software in a Resource topology. It’s a mature, uncomplicated market. Competition has delivered a better website and app that customers love. Leadership has decided on a business objective of retaining customers, with an org goal of fast flow to parity, by targeting a Delivery topology with CAPS-3 teams. Now let's evaluate this set-up with the three questions: Q> What parts of the company are the focus of org development? The Product Management and R&D departments, so focus on AI investment there.  Q> What archetypes are part of the target? What’s a dominant constraint from one to the other? The R&D department has mostly TASKS-1 individuals, and the target is CAPS-3 teams. On investigation, it’s a lack of front-end design and coding skilled people. Focus time, money, and management attention on AIs, especially on that big bottleneck, over a generic “adopt AI.” Q> Do the AIs need monitoring by humans? Yes, because people have decided on AI agents that autonomously design and code front ends, independently creating and iterating on variations that they deploy and measure. The small number of existing front-end designers and developers joining the new CAPS-3 teams will be trained in agent monitoring and take on that responsibility. Strategic AI Adoption in Archetype Groups As a part of the Org Topologies Primer 2025 — a table of how AI adoption can be strategized in each of the four archetype groups: More on AI Implications on Org Design

This article starts by laying down the key principles of EBM applied within an OT-inspired org change. It starts by providing a crisp description of both methods and then dives into describing how they are seen working together to reinforce a systemic org change with a strong focus on measuring value. Org Topologies recognizes Measure and Improve Value with EBM (for Enhanced Performance and Agility) as one of the Elevating Katas - a set of principles, methods, and guides for moving an org design closer to the upper right on the Org Topologies map. If you know both methods, jump to the later section where the methods are being compared, contrasted, and integrated. For a complete guide on Evidence-Based Management , refer to the Scrum.org EBM page . In this article, we claim the following to be true: OT provides the actionable changes and EBM provides the measure of success, enabling a scientific approach to organizational evolution. EBM identifies the symptoms, OT treats the root cause , and EBM then measures the treatment’s effectiveness . EBM measures act as a compass ensuring Org Topologies changes truly lead to agility . Org Topologies: Principles and Methodology Org Topologies (OT)  is a framework for strategic organizational design and change. It is described as the first “human-centric plus AI-friendly”  approach to organizational change. This means it emphasizes the human side of change (people need to own  their change and find it engaging) while anticipating the integration of AI into the workforce​. Key principles and components of Org Topologies include: Psychology of Change:  OT recognizes that lasting change occurs when people across the organization participate and take ownership, rather than having changes imposed top-down​. It provides a visual and collaborative mapping  process so everyone can “visualize, discuss, understand, and shape the change”  together​. This shared understanding creates a common language for organization design and engages everyone in the transformation. Fit-for-Purpose Design:  Org Topologies aligns organizational structure with the organization’s strategic goals or “North Star.” Different business goals (e.g. rapid delivery, adaptability, resource efficiency, innovation) require different tailored org designs ​. OT helps leaders define the right target design to achieve their specific objectives and keep the organization “fit for purpose”  as those objectives evolve. It works at any scale – entire enterprise or subdivisions – to ensure structure, strategy, and change process are all aligned​. Organization Mapping and Archetypes:  A core methodology in OT is mapping the current organization into archetypes  on a two-dimensional grid. The two axes represent fundamental dimensions of org design, such as the growing scope of skills mandate  (depth of cross-functional skills) and scope of work mandate  (breadth of product/customer scope)​. OT defines a set of common patterns (archetypes) for how teams or units are structured and operate. In the latest version, there are 16 archetypes organized into four groups and positioned along the two axes. This Org Topologies Map  is a visual tool to assess where the organization is today and identify mismatches between the current design and the capabilities needed to meet business objective. Topologies and Organizational Patterns:  The archetypes are further grouped into three broad topologies  – often described as Resource , Delivery , and Adaptive  topologies​. Each topology represents a distinctive way the organization coordinates work: Resource Topology  (traditional model): characterized by specialized, siloed teams managed via centralized coordination (emphasis on resource utilization). Directing  units (like PMOs or managers) decide work, and Doing  units execute, often leading to hand-offs and dependencies (not directly cited, but implied by context). This can maximize local efficiency but often sacrifices adaptability and speed. Delivery Topology:  focuses on the fast flow of outputs by using cross-functional teams and removing inter-team dependencies. Teams are structured as “complete” delivery units (often called feature teams or “feature factory”  style) that can produce a steady stream of features with short lead times. However, work definition (the “what to build” ) is usually still driven by separate planning or analysis roles (discovery is handled apart from the delivery teams). This topology excels when the main challenge is predictable, rapid delivery  of known features rather than exploring unknown market needs. Adaptive Topology:  aims for maximum adaptiveness and innovation . It merges directing, doing, and delivering into one  unified unit. In this model, teams (or “team-of-teams”  networks) are empowered to both discover and deliver value continuously, often working with a broad product scope and high synchrony across the organization. Humans, AI agents, and even robots collaborate in these “Driving”  units to solve complex problems, learn, and adapt on the fly. The Adaptive topology’s goal is to enable quick, cheap responses to change and to “discover and deliver higher-impact customer outcomes” , supporting long-term business resilience. This design is fit for organizations where growth, learning, and customer-centric innovation are paramount. Intended Application of OT Org Topologies is intended for any industry or domain seeking to improve organizational agility and performance – from software product companies to farms or construction firms. It is especially useful in agile and digital transformations, where existing structures hinder fast delivery, adaptability, or innovation. By using OT, leaders gain a “critical managerial tool” to drive performance via org design. For example, OT can be overlaid with frameworks like SAFe, LeSS, or even non-tech models like Haier’s Rendanheyi to map and enhance an Agile Release Train or a networked organization. Overall, Org Topologies helps organizations “align all the moving pieces” – structure, strategy, and change efforts – to achieve strategic goals in a sustainable way​ Evidence-Based Management (EBM): Principles and Methodology Evidence-Based Management (EBM)  is a framework developed by Ken Schwaber and Scrum.org to help organizations continuously improve by making decisions based on evidence and measurable outcomes. EBM is built on three core pillars: clearly defined  Goals , targeted  Measures , and the discipline of  Empiricism .  These pillars work together—our goals set the strategic direction, the measures (including KVAs) provide evidence, and empiricism drives continuous learning and adaptation. The method provides a disciplined, empirical approach for management and teams to achieve strategic goals in the face of uncertainty. Key principles and components of EBM include: Empiricism and Experimentation:  EBM advocates that organizations tackle complex, uncertain challenges through intentional experimentation and frequent feedback . Rather than making big up-front plans, teams and leaders set incremental goals , run experiments, and use data to decide the next steps. In practice, this means forming a hypothesis about how an improvement or change might move the organization closer to its goals, implementing that change on a small scale, and measuring the results against expected outcomes. Based on the evidence gathered, the organization adapts its tactics or even revises its goals. This iterative loop mirrors Scrum’s empiricism at a management level, ensuring that decisions are grounded in real-world data  rather than assumptions. Value-Focused Goals:  In EBM, all efforts are oriented toward improving outcomes  (value delivered), not just outputs. Organizations are encouraged to express their aspirations at multiple levels – a Vision (the ultimate change they seek to make in the world), a Mission (why they are uniquely positioned to achieve that vision), and concrete Goals that lead toward fulfilling them. However, EBM notes that many organizations struggle to create effective goals that drive real progress toward their mission and vision. EBM addresses this by helping organizations set Strategic Goals  (long-term objectives connected to mission), break them into nearer-term Intermediate Goals , and then into very short-term Immediate Goals  that teams can act on now. Crucially, each goal should have measurable criteria  so the organization can inspect whether changes are actually moving the needle. This keeps goals outcome-oriented (e.g. improving customer satisfaction) rather than activity-oriented, and it ensures every level of goal is aligned with delivering real value. Empiricism and Experimentation with Value-Focused Goals of EBM Key Value Areas (KVAs):  A cornerstone of EBM is measuring value and capabilities in a balanced way . EBM defines four broad Key Value Areas  which act as lenses on different aspects of organizational performance. These KVAs help teams and managers focus on what to improve and avoid blind spots. EBM: Four Key Value Areas The four KVAs are: Current Value (CV):  How much value the product or service delivers to customers today  (e.g. customer satisfaction, revenue, market share). Unrealized Value (UV):  The potential future value that could be unlocked if the organization better met all possible customer or user needs – essentially the gap between current value and what could  be achieved (e.g. untapped market segments, additional features that could attract new customers). Ability to Innovate (A2I):  How effectively the organization can deliver new capabilities or improvements (e.g. innovation rate, technical excellence, experiment frequency). This reflects the organization's capacity to adapt and innovate in response to market needs. Time to Market (T2M):  How quickly the organization can deliver a new idea or change and gather feedback on it (e.g. release frequency, lead time for changes). Intended Application of EBM   EBM was initially formulated in the context of software and product delivery organizations adopting Scrum, but it is broadly applicable to any enterprise seeking to improve its results under uncertainty. It is especially useful when an organization has adopted Agile practices but wants to ensure those translate into real business value. For example, a company might use Scrum for development; EBM provides the management framework  to measure whether Scrum is delivering the expected improvements in customer value, time to market, etc., and to guide further changes. Typical applications of EBM include setting organizational OKRs or targets in terms of KVAs, assessing the impact of transformations (e.g., “Are we actually reducing time-to-market with this new process?”), and steering investments toward initiatives with evidence of high impact. Because it is framework-agnostic, EBM can overlay any process or structure, providing a way to “measure, manage, and increase the value [an organization] derive[s] from their product delivery” ​. Ultimately, it helps organizations “improve outcomes, reduce risks, and optimize investments”  by empirically guiding decisions at all levels. How OT and EBM Complement and Contrast Each Other Because Org Topologies and EBM operate in different yet related domains (structure vs. measurement), they can be used together in a complementary fashion. Complementary Use Cases In an organizational transformation, one can use Org Topologies to design the change  and EBM to drive and verify the change . For example, if a company’s strategic goal is to improve innovation and adaptability, Org Topologies might suggest moving toward an Adaptive Topology – merging discovery and delivery functions into autonomous product units. EBM would complement this by tracking Ability to Innovate  and Unrealized Value  metrics to see if the structural change actually increases innovation output or unlocks new market value. In fact, Scrum.org notes that their EBM framework is a good way to ensure “rigorous experimentation and a balance between value indicators”  during change efforts​. Meanwhile, Org Topologies “offers a powerful tool for assessing the [current] situation and outlining the changes needed”  to reach those objectives. Together, OT can tell you what  to change in your org design, and EBM can tell you whether those changes are producing the desired results . This closes the loop between design and outcome: Strategy Alignment:  Org Topologies helps translate strategic objectives into an appropriate organization design (e.g. choose a topology that fits a strategy of rapid delivery or one that fits a strategy of innovation)​. EBM ensures that those strategic objectives are clearly articulated as measurable goals and provides feedback on progress toward them​. The two together ensure that structure and strategy are continually aligned and validated. If strategy shifts, EBM will catch changes in outcomes, and OT provides a mechanism to adjust structure accordingly. Navigating Change Safely:  Both frameworks stress incremental change, so used together they encourage a safe-to-fail approach. Org Topologies might implement a pilot re-organization in one product line (Elevate step with experiments), and EBM would measure the pilot’s impact in terms of value (did customer outcomes improve? did time to market improve?). If the metrics show positive evidence, the new design can be rolled out wider; if not, the organization can iterate on the design. This complementary approach reduces the risk of large-scale changes – you’re not “flying blind” with a new org structure because EBM is instrumenting the change with data. Balancing People and Performance:  Org Topologies brings in the human element – making sure people understand the why of changes, and that roles and team boundaries are set up for collaboration rather than confusion​. EBM brings in the performance focus – making sure the changes actually deliver business results, not just feel good. In some transformations, there’s a risk of over-focusing on org charts and forgetting to measure outcomes (which EBM prevents), or conversely over-focusing on metrics and ignoring morale or clarity (which OT prevents by involving people in design). Together, they provide a more holistic transformation: structural, cultural, and outcome-based  considerations are all addressed. Contrasting Considerations On the other hand, using both requires understanding their different mindsets. Org Topologies might identify a structural problem  (say, too many narrow-component teams causing slow integration). EBM might identify a value problem  (say, low customer satisfaction). These may or may not point to the same solution initially – it takes skilled interpretation to connect the two. For instance, EBM could reveal a problem (low Current Value) that is due to factors outside org structure (maybe a poor product-market fit or outdated technology). Org Topologies might propose structural changes that need careful justification via evidence (to avoid reorgs that don’t pay off). In some cases, one framework might challenge the other: EBM’s data might suggest that a recent structural change (inspired by OT) is not yielding results, which could mean re-thinking the change or giving it more time. Conversely, an OT practitioner might caution that certain performance drops are expected short-term during re-structuring and that patience is needed. Therefore, while they complement each other, it’s important to synchronize cadence  and perspective  – using EBM’s evidence to inform Org Topologies decisions, but also using Org Topologies wisdom to interpret EBM data in context. Another contrast is in scope of impact : Org Topologies changes can have far-reaching consequences on people’s roles, team identity, and day-to-day work (which can be disruptive even if ultimately beneficial). EBM’s introduction (measuring things, setting new goals) is usually less structurally disruptive but can change mindsets and accountability. An organization needs to manage both the structural change management and the cultural shift to evidence-driven management. Leaders might choose to introduce EBM practices first (to identify where change is needed and build a culture of empiricism), or introduce Org Topologies first (to fix glaring structural bottlenecks), or do both in tandem. There’s no one right sequence, but it’s wise to communicate how they interrelate so teams don’t feel like “yet another initiative” piled on. Elevating Kata: Measure and Improve Value with EBM for Enhanced Performance and Agility When integrated thoughtfully, Org Topologies and Evidence-Based Management can reinforce each other to significantly enhance organizational performance and agility. Here are some ways an organization might combine the two frameworks: Data-Driven Org Design:  Use EBM metrics as diagnostics  to drive Org Topologies interventions. For example, suppose EBM reveals that Time to Market  is too slow and Current Value  is stagnating. This quantitative evidence can trigger a closer look at org structure: perhaps teams are organized in a Resource Topology with many dependencies causing delays. Org Topologies would then provide a method to redesign toward a Delivery or Adaptive Topology (e.g. introduce more cross-functional teams, reduce hand-offs) to address the problem. After making structural changes, the organization continues to track the relevant KVA metrics. If Time to Market improves and Current Value starts rising, it validates the structural approach; if not, further adjustments are made. In this way, EBM identifies the symptoms, OT treats the root cause , and EBM then measures the treatment’s effectiveness. Continuous Feedback into Structure:  Apply an EBM loop within the OT “Elevate” phase . As Org Topologies changes are implemented incrementally, each change can be treated as an EBM experiment. Define an expected outcome (e.g. “by merging Team A and B into a single value-stream team, we expect deployment frequency to double in that product line”), implement the change, and measure the outcome (deployment frequency is a proxy for Time to Market KVI). This creates a tight feedback loop: structural change → metric outcome → learn → next structural change. It prevents the organization from over-correcting or making broad changes without evidence. Essentially, OT provides the actionable changes  and EBM provides the measure of success , enabling a scientific approach to organizational evolution . Strategic Goal Alignment Workshops:  An integrated practice could be running a workshop where leadership uses EBM to set or refine strategic goals/KVAs, and simultaneously uses Org Topologies mapping to evaluate if the current org can meet those goals. For instance, leadership might set a goal to increase Unrealized Value  (capturing a new market segment). In the same session, using Org Topologies maps, they might discover that the current structure has no dedicated product team exploring that new market (perhaps all teams are tied up delivering current features). This insight leads to an Org Topologies design solution (e.g. create a new “Explore” team archetype or reassign an existing team’s mandate to include the new segment). They would then implement that and use EBM to monitor if Unrealized Value (e.g. percentage of market captured or new customer adoption) starts to go down, indicating value is being realized. This illustrates how strategy → structure → metric integration can happen in a seamless flow. Combining Language and Measures:  Org Topologies provides a common language  for org structure (with terms like CAPS, WHOLE, topologies, etc.), and EBM provides a common language for value and improvement (CV, UV, etc.). Together, they can help different parts of the organization communicate. For example, an agile coach might say “We need to elevate from a CAPS-1 to a CAPS-3 team to reduce dependencies,”  and a product manager might add “Yes, that should improve our Time to Market.”  When both the structural change and the expected outcome are clearly expressed, it creates alignment between organizational development efforts and business results. This integration of lexicon – structural terms coupled with value metrics – ensures everyone understands not just what  change is happening, but why  (what outcome is expected). It ties the abstract concepts of org design to concrete business metrics that people care about. Ensuring Balanced Change:  EBM’s four KVAs ensure that while pursuing one improvement, you don’t hurt another. An organization integrating OT and EBM will use those metrics to check that a structural change aimed at one dimension doesn’t inadvertently damage another. For example, moving to a Delivery Topology might speed up delivery (better T2M) but, if done in isolation, could lead to feature factory syndrome where lots of output doesn’t increase customer value (CV)​. By keeping an eye on Current Value and Unrealized Value, leaders can detect if they are churning out features with no outcome – and then course-correct by incorporating more “Adaptive” elements (e.g. ensure teams also have discovery capability, not just output focus). Thus, the EBM measures act as a compass  ensuring Org Topologies changes truly lead to agility (ability to respond) and  real value creation, not one without the other. Scaling and Sustaining Gains:  Over time, as an organization iterates between OT-driven changes and EBM-driven measurements, it can develop a capability for self-tuning . The structural changes (OT) solve immediate bottlenecks, and the measurement (EBM) ensures new bottlenecks or opportunities are quickly identified. This synergy can accelerate an agile transformation or any continuous improvement initiative. Org Topologies changes might happen at a slower cadence (since structural moves take planning), while EBM cycles can happen very frequently. An integrated approach might use EBM continuously (say, quarterly outcome reviews, monthly metric check-ups) and use Org Topologies periodically (say, an annual structural review or on-demand when EBM indicates a plateau). When both are embedded into the management practices, the organization is equipped to adapt both its strategy execution and its structure in concert . This leads to what we might call organizational agility  in the truest sense: the organization can reconfigure itself (structure, teams, processes) and redirect itself (goals, investments) with relative ease, based on evidence, to seize opportunities or avoid threats. Key Metrics Aligned to Organizational Topologies The Evidence-Based Management (EBM) Guide (2024)  Appendix provides example Key Value Measures (KVMs) that organizations can use to gauge value and improvements. Each organizational topology – Resource , Delivery , and Adaptive  – emphasizes different goals, so certain metrics from the EBM examples will be more suited to each. Below is a table of three exemplary key metrics fit for each topology, along with explanations of how each metric aligns with that topology’s characteristics and goals. Resource Topology Org Goal: maximizing resource utilization and specialization Metric (Key Value Area) Alignment with Resource Topology Product Cost Ratio   (Current Value) Measures total product expenses relative to revenue. A lower cost-to-revenue ratio reflects greater efficiency in resource utilization, supporting a Resource-focused organization’s aim to optimize costs and maximize the output from each resource. Revenue per Employee   (Current Value) Indicates how efficiently each employee (resource) generates value. A higher revenue per employee means the organization gets more output per resource, aligning with the Resource Topology’s goal of maximizing resource use and efficiency. On-Product Index   (Ability-to-Innovate)   The percentage of time teams spend working directly on product value (vs. overhead). A high on-product index means most of the workforce’s time is spent on productive, value-adding work, which aligns with maximizing resource productivity in a Resource Topology (minimizing idle time or context-switching). Delivery Topology Org Goal: maximizing output and predictability of delivery  Metric (Key Value Area) Alignment with Delivery Topology Release Frequency   (Time-to-Market) Measures how often the product is released (e.g. daily, weekly, etc.). Frequent releases indicate a high throughput of features to customers, matching the Delivery Topology’s emphasis on steady output and regular delivery of value. This metric shows the capability to deliver predictably and often. Lead Time (to Value)   (Time-to-Market) The time from an idea or requirement being proposed to it being delivered and benefiting the customer. Short lead times demonstrate fast turn-around from concept to delivery, reflecting the Delivery Topology’s goal of rapid, predictable delivery of proven value. Change Failure Rate   (Ability-to-Innovate) The percentage of releases that result in failures (e.g. require hotfixes or rollbacks). A low change failure rate means releases are generally stable and successful, supporting the Delivery Topology’s focus on predictability and quality in output. This ensures that increasing release speed doesn’t come at the cost of reliability. Adaptive Topology Org Goal: maximizing outcomes and innovation through fast adaptation Metric (Key Value Area) Alignment with Adaptive Topology Customer Satisfaction   (Current Value) Gauges how happy customers/users are with the product (e.g. via surveys or NPS). High customer satisfaction indicates the organization is delivering valuable outcomes, not just outputs. This aligns with the Adaptive Topology’s goal of maximizing customer-centric outcomes (delighting customers through continual learning and adaptation). Time To Pivot (Time-to-Market) Measures how quickly the organization can change direction in response to feedback or market changes. A short time to pivot reflects true business agility – the hallmark of an Adaptive Topology – demonstrating easy, cheap change based on learning and a capacity to rapidly adapt strategy. Innovation Rate   (Ability To Innovate)   The percentage of effort spent on developing new product capabilities (versus maintenance). A higher innovation rate means the organization dedicates more of its resources to creating new value. This supports the Adaptive Topology’s focus on innovation and exploration, ensuring the organization can continuously evolve and deliver novel solutions. Summary In summary, Org Topologies and Evidence-Based Management are distinct but highly complementary frameworks. Org Topologies  provides the “where and how to change”  from a structural perspective, ensuring the organization’s form enables agility and aligns with its purpose. EBM  provides the “whether and why to change”  from a value perspective, ensuring the organization’s operations remain focused on delivering measurable value and that any change is justified by evidence. Their key principles differ – one is about designing the system , the other about measuring and steering the system  – yet they share a foundation in agile, empirical thinking and can mutually reinforce success. By integrating the two, organizations can avoid the pitfalls of structure-blind improvement or improvement-blind structure. Instead, they gain a powerful combined approach to become both well-organized and continuously learning – ultimately enhancing performance, adaptability, and agility in a sustainable way.

What is Elevation by Org Topologies?  Elevation by  Org Topologies  refers to the process of enhancing an organization’s design and functioning to achieve higher levels of adaptability, innovation, and resilience. This method involves a structured approach to understanding the current state of an organization, identifying capability and value gaps, and designing a visionary path forward. By utilizing Org Topologies’ mapping and assessment techniques, organizations can navigate their transformation journey systematically. This elevation process fosters a more holistic understanding of organizational systems, allowing for continuous improvement and alignment with strategic goals. The ultimate aim is to create sustainable, high-performing Topologies that can effectively respond to changing market conditions and drive long-term success. According to the theory, there are three types of topologies. A traditional SAFe adoption is either a Resource Topology or a Delivery Topology . Both of these ecosystems are characterized by reliance on lower-level archetypes (Incomplete Tasks and Capabilities level) that are not aligned with business stakeholder needs and customers' journeys. Thus, to yield expected results, such archetypes require extra management capabilities, roles and processes. Note that the Adaptive Topology requires a completely different set of archetypes residing in the top right quadrant of the map: Three Topologies Reasons Why SAFe Adoption Needs to Be Elevated* * The reasoning below is based on numerous observed SAFe adoptions of various sizes. If your SAFe adoption avoids many of these drawbacks, you are an exemplary exception— keep up the great work! 1.  Lack of True Agility : Many organizations implementing SAFe do not achieve the level of agility intended. They often get stuck in lower archetypes (e.g., TASKS-1, or CAPS-2) with significant dependencies that slow down the development process and reduce overall responsiveness to change. 2.  Dependency Management : SAFe tends to manage rather than eliminate dependencies. This management approach consumes time and resources, reducing the system’s efficiency and effectiveness in delivering value. 3.  Push System Pitfalls : Although SAFe is designed to operate as a pull system, it often functions as a push system. This misalignment leads to decreased adaptability and responsiveness to customer needs, ultimately impairing the system’s performance. 4.  Siloed Teams and Fragmented Backlogs : Teams often work in silos with their own backlogs, resulting in local optimizations that do not align with the broader organizational goals. This fragmentation complicates prioritization and reduces transparency and predictability in delivering customer value. 5.  Inadequate Organizational Design : The typical SAFe implementation does not address the root causes of organizational inefficiencies. It often fails to align with strategic goals, resulting in suboptimal configurations that need continuous adjustments and elevation. 6.  Slow Feedback Loops : SAFe’s dependency on program increments (PIs) with 8-12 week cycles limits the frequency of customer feedback, making it difficult to quickly adapt to changing market conditions and customer requirements. 7.  Suboptimal Use of Agile Release Trains (ARTs) : ARTs frequently operate as loosely connected teams rather than cohesive units focused on common goals. Elevating ARTs to function as high-performing, integrated teams of teams can significantly enhance their agility and value delivery. 8.  Misalignment with Business Needs : SAFe’s structure often separates product management from teams, leading to designs that are difficult to implement and creating waste. Integrating product management and development teams can help align solutions more closely with business needs.  By addressing these issues and elevating SAFe adoption, organizations can improve their adaptability, enhance customer value delivery, and create more cohesive and responsive development ecosystems. A "Team of Teams" Concept from Org Topologies A "team of teams" is an advanced organizational concept where multiple specialized teams are integrated to work collaboratively on broader business problems, creating a larger, cohesive unit. This approach enhances scalability and adaptability by leveraging the combined skills and expertise of different teams to address complex challenges that span their individual scopes. Key Features of a Team of Teams: Business Problem Focus : Teams are combined to address business problems at a higher level, often encompassing entire customer journeys or significant business areas. Self-coordination : The integrated teams coordinate among themselves, eliminating the need for external coordinators. Shared Backlog : A single business-level backlog is used, ensuring all teams work towards common goals in synchronization. Higher Adaptability : By working in a shared cadence (e.g., synchronized sprints), teams can adapt quickly to changes and dependencies that arise during the development process. Simpler Org Design : by allowing your stakeholders and product managers to work with the cohesive unit – a "team of teams" and now pre-cut and pre-assign for the individuals and individual teams. Synchronous Work on Business Objectives: In contrast with traditional sequential work, which is planned upfront, the teams within the "team of teams" are able to work synchronously, contributing together to the shared business objectives. This is similar to a great Scrum team, where the whole team works as one to complete an end-to-end single piece of customer-facing functionality before moving to the next one. The last point is critical: it gives us an observable differentiator whether your teams are working as asynchronously (individually) or together as a true "team of teams". Not how a traditional ART is not a "team of teams". And the fact that the dependencies between different teams in an ART are being analyzed upfront and managed externally to the teams, deprives the teams of the ability to collaborate just-in-time, share work, and thus work synchronously. This is so by design: in SAFe because it is given that they are blocking dependencies between the teams, the goal of the framework and its method is to save the team from dealing with the dependencies. From the systems thinking perspective, such an over-management is a quick fix -- it will not make the system better over time, and the system will always require such an intervention (i.e., PI Planning and Upfront Dependency Management) for the system to work. Our core belief: a framework (or any management system that we apply) should 1) improve that ecosystem, not merely provide a crutch and 2) become less needed in a long run as the system has healed, improve and acquired new capabilities to deal with those historical problems in an inherent way. Towards Elevated ARTs, one eARTs at a time: 1. Pick an ART to get elevated. SAFe adoption is usually advised as a big bang, a "one size fits all" transformation. But once you are ready for a SAFe adoption, nothing stops you from experimenting independently on the ART level. Not all the ARTs need to undergo the same transformation and at the same time. The context matters. Size matters. Steady acquisition of new skills and capabilities matters. The willingness of people to participate voluntarily in experiments matters. So go an ART at a time, provided they can deliver value understood by the business (if not - consider merging the ARTs or pick the ones that do). Pick in ART that has more intrinsic chances of being converted into a "team of teams". Make sure all the members of an ART understand the ultimate goal and the challenges of the journey. Make sure they want to solve those challenges. The challenge must be accepted first before addressed. 2. Elevated an ART's Backlog to Business Objectives. In practice, an ART often functions as a collection of individual teams rather than a cohesive unit. To achieve a higher level of organizational agility, aim for an ART to reach the B-level archetype (a "team of teams"), characterized by a focus on business value and a higher degree of adaptability. This requires all the teams in an ART to share the same context. They should stop seeing individual features or tasks being fed to them as their work. Bigger, challenging business objectives should be used to unite them and help them see they need each other to work together on those. So, present a united backlog formulated on the level of business objectives to all teams in the ART. You don't need to create special roles to do this work. The existing group of product managers, Product Owners plus selected team members and stakeholders shall become up with a list of prioritized business objectives. In most cases, such a list already exists. 3. Contain the dependencies and allow for synchronous work of multiple teams.  SAFe tends to manage dependencies rather than addressing the root causes of their existence (i.e. focus on component development rather than end-to-end customer-facing functionality). To elevate an ART to be able to self-manage cross-team dependencies is the goal here. This can be achieved by minimizing WIP and allowing the teams to work together on a single business objective and in a shared cadence. In most cases, some form of technical coaching will be needed to teach the teams to integrate across the teams continuously. Dispersing the teams or lighting up the team boundaries is usually very helpful in this period. It's absolutely OK (and must be taught and appreciated) for the team members from different teams to work together on some core pieces of functionality. The "team of teams" should be more important than the individual teams within. 4. Improve an ART at a time. Don't cancel any existing SAFe rituals, but first add processes that will allow the teams to have a shared context and a cadence. Postpone your judgments about the speed or performance of your Elevated ART (eART). Remind yourselves and the others of the goal: creating a cohesive unit which can act together as one -- jumping on bigger problems and learning and working in sync. Work as one and learn as one: apply inspection and adaptation as well as managers' support to solve raised impediments via overall retrospectives, joint backlog refinements, cross-team mobbing sessions, collecting multi-team architectural workshops, and joint increment reviews. Elevating SAFe Adoption with Org Topologies™

Review Bazaar is one of the Elevating Katas that help to elevate your organization to the higher archetypes: This article aims at helping you to conduct the most awesome Sprint Review  people have ever witnessed. An additional benefit of the Bazaar mode: it works with large crowds, so ideal when you work with multiple teams on a shared initiative. This type of Sprint Review approach is commonly used in the higher archetypes  (PART-3, PART-4, and WHOLE-3 and WHOLE-4). The main purpose of the Sprint Review (SR) is to collect feedback . After seriously inspecting the product, several changes to the backlog or action points for solving impediments should be identified. The Scrum Guide says: “During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next. The Product Backlog may also be adjusted to meet new opportunities. The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation." You must have witnessed them at least a hundred times: those Sprint Reviews where each team gets their moment of fame to broadcast what they have been sweating on over the past couple of weeks. How disappointing it is to look at PDF documents, PowerPoint, and wiki pages full of awesome designs or other fantasies the team spent the CEO’s money on. Someone occasionally asks a polite question to prevent awkward silence. The hurdle praises the demo with a dutiful round of applause. Of course they do; they are next in the queue... We can do much better than this The Sprint Review is supposed to be a thorough inspection  of working software. Sitting in a room looking at slides or screenshots will not likely spark a creative buzz. Did you ever do a successful inspection of anything without being allowed to touch it? No. So users should get hands-on with the product  and the developers should observe them . (Read that again!) Only then will we collect sensible feedback. The attendee will click the wrong buttons, browse back, refresh, and do everything else you can imagine that was not included in the happy flow. In addition to inspecting the product, teams need to share their status  and provide insight into their learning ability  with stakeholders by discussing the challenges they face. This elicits collaboration because the people funding the teams benefit from getting the teams unstuck. The Sprint Review is an opportunity for stakeholders to interact with the teams  to learn what decisions they can take to maximize their ROI . There are various formats for conducting a Sprint Review. I have tried some with different rates of success. The format that worked best for me is the Sprint Review “Bazaar”  or “Science Fair.”  This works particularly well with CAPS-3 and PART-3 cross-functional feature teams  working on a single backlog managed by one PO. That makes things easier, but having multiple backlogs and multiple POs will not prevent you from having a successful Sprint Review Bazaar. The Tips The Product Owner (PO) needs to invite the right people . All teams belonging to a tribe or department, working on the same product or value area, should be present. Invite internal and external customers involved in the product development process or who consume the delivered value. (Don’t invite real customers randomly, since lack of context can hinder the Sprint Review.) Make sure the PO announces which features  will be inspected so stakeholders can decide if they should join. Most importantly, don’t forget “the one who pays the bills,”  like the CEO. Knowing they’ll be there adds healthy pressure. But for your first Bazaar, don’t push too hard—treat it like a rehearsal. When it works, word will spread. Don’t focus the Review on teams doing their dance —shape it around delivered features . This might require members from different teams (especially in CAPS-2 or PART-2 contexts) to collaborate on a single inspection of end-to-end functionality. That means preparing a workshop or hands-on session, observing the visitors, and engaging in feedback dialogue. Combining multiple team Reviews makes the session more valuable for stakeholders. They can visit one event and get updated on multiple investments. Core Concepts of the Bazaar: 1. Parallel inspections.  Each delivered feature gets a "shop." Attendees choose two shops to visit per Review. 2. Instant transparency.  Teams clarify feedback, provide a rough complexity estimate. The PO shares what will happen next: act, refine later, or discard. Preferably, hold the Review in your regular workspace. The development time is over, so no one is “missing work.” A dedicated room is fine, but not required. Just space the shops out well. Teams should create big banners  naming the feature and shop. For remote participation , use a good meeting room with strong AV equipment. A local facilitator is key to success here. To ensure quality, plan prep sessions  with the PO and teams. The Scrum Master and PO are critical in asking the right questions and raising the bar. Stick to the standard Sprint Review timebox . Don’t overextend. The Scrum Master must facilitate strongly . Arrange a whiteboard, projector/screen, snacks, drinks—keep it informal and engaging . Step-by-Step Format The Sprint Review is hosted by the PO. The SM facilitates. Start on time. Always. Even if no one shows up. 5-minute Welcome  – PO welcomes stakeholders and teams, recalls Vision and Sprint Goal. Keep it focused on the delivered software. No ops updates. 5-minute Intro  – SM explains the agenda, hands out sticky notes and pens, reminds attendees to give feedback , and keeps the strict schedule. 5-minute Feature Pitches  – A member from each team pitches their feature shop. One-liner format. 20-minute Review Round 1  – Stakeholders visit a shop, interact, give feedback. Teams observe and self-organize to prioritize. 10-minute Feedback Merge  – Everyone regroups. PO invites feedback. SM clusters stickies. Others can help—this goes fast. 20-minute Review Round 2  – New shop visits. Teams rotate roles—observers become visitors. This fuels cross-team learning  (especially useful for CAPS-2 and PART-2 environments with incomplete teams). PO organizes Round 1 feedback. 10-minute Feedback Merge  – Another group feedback session. PO emphasizes inputs that affect the next Sprint. Business stakeholders are invited to speak in the group, not one-on-one. 10-minute Break  – PO and SM to organize the acquired feedback of round 2 and prepare for the close. 15-minute Conclusion  – PO elaborates on collected feedback, grouped by feature. Team members give context and rough estimates. PO explains which feedback will be acted on and thanks participants. 20-minute Informal Wrap-up  – Space for 1-on-1 questions, clarifications. SM runs a quick ROTI to inspect the Sprint Review format itself. Awesome, right? Try the Sprint Review Bazaar once. Evolve it. Do it again. If your teams are at CAPS level  today, this Elevating Kata helps them practice PART-level collaboration . Your teams and stakeholders will never want to go back. Roland Flemm & Alexey Krivitsky for Org Topologies™

How work units learn inside an Adaptive Topology. What Are Learning Modes? Learning Modes  are lightweight, deliberate patterns that help individuals and teams continuously learn across boundaries— without reorganizing . They are to learning what interaction modes (from Team Topologies) are to coordination: repeatable, intentional behaviors  that make learning systemic. In an Adaptive Topology, learning is not a side activity—it’s the primary flow. Learning Modes describe how that learning happens inside the structure. How They Differ from Elevating Katas Elevating Katas  are structured practices that help an organization move from a Resource or Delivery Topology toward an Adaptive Topology . They drive transformation—by shifting roles, rituals, responsibilities, or mindsets. Learning Modes  describe how work units operate once they’re inside an Adaptive Topology , where continuous learning is part of the work itself . Think of Elevating Katas as change agents , and Learning Modes as operating patterns  for evolved teams. Why Learning Modes Matter Dynamic reteaming is often used to plug skill gaps. But this disrupts teams and slows progress . Learning Modes offer a better alternative: practices that support multi-learning within long-lived teams , enabling them to evolve from within. The Four Learning Modes Scouting Mirroring Weaving Synthesizing Each mode enables learning across different dimensions: individuals, teams, roles, and systems. 1. Scouting Explore the unknown. Sense early. Small groups or individuals go outside their team to gather insight from other domains, users, or markets. Scouting brings early awareness of friction, trends, and ideas. Example: A backend developer joins customer support sessions to learn common complaints. An AI agent might suggest, “Team X solved a similar problem—want a summary?” 2. Mirroring Build empathy. Transfer tacit knowledge. One person shadows another in a different role to understand their challenges, decision points, and context—not to replace them, but to see through their lens. Example: Developers sit with real users to observe how they work—learning what to improve or automate based on actual behavior and struggles. 3. Weaving Learn across teams. Integrate perspectives. Multiple teams work together—temporarily or regularly—on a shared challenge. This mode breaks silos and builds cross-team coherence. Example: Several teams collaborate to solve a major customer problem, combining technical, business, and support perspectives. 4. Synthesizing Institutionalize the learning. Insights from other modes are codified into shared tools, practices, or standards. This mode ensures learning sticks and scales. Example: After repeated Mirroring between QA and Dev, teams co-develop a shared onboarding template and update their Definition of Done. What Learning Modes Enable Cross-role learning without reteaming Capability growth inside stable teams Resilience without overload Continuous adaptability in a fast-moving context What Learning Modes Are Not Not Elevating Katas  – which change the structure or culture to help reach an Adaptive state Not interaction modes  – which focus on delivery coordination (like X-as-a-Service or Facilitation) Not team reshuffling  – which breaks trust and momentum How AI Accelerates Learning Modes Learning has always required time, trust, and exposure. But with AI agents now embedded in everyday tools, learning can happen faster, just-in-time, and context-aware . Here’s how AI augments each learning mode: Scouting + AI Agents can proactively surface relevant examples, documents, or team artifacts. AI copilots can “scout” across internal tools, Slack, Confluence, or code to find prior solutions. → “This pattern was used in a similar case—want to see the code or talk to the team?” Mirroring + AI AI agents can track sessions, summarize insights, or suggest questions to deepen learning during a mirroring experience. → “While observing the user workflow, notice how they hesitate on this step. Want to explore why?” Weaving + AI During cross-team problem-solving, AI tools can surface common dependencies, conflicting priorities, or shared risks. Agents can document shared learnings across teams automatically. → “These 3 teams use different auth flows—would you like a synthesis report?” Synthesizing + AI AI can generate first drafts of shared artifacts—onboarding guides, updated playbooks, or code documentation—based on conversation logs and patterns. → “Here’s a suggested update to the team’s Definition of Done based on what was discussed.” Without AI, learning across teams is expensive and slow. With AI, it becomes ambient and constant— multi-learning becomes a background capability. Learning Modes don’t change. But AI makes them cheaper, faster, and easier to sustain and with manageable levels of cognitive load. In Summary In an Adaptive Topology, learning is the work. They help teams stretch, connect, and grow— without needing to be rebuilt. Used consistently, they reduce the need for structural change and make adaptability scalable.

Org Topologies Pitch and References Download the latest slide deck with a high-level pitch and multiple references that can help see the field of application for Org Topologies: Org Design Drives Performance 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. What scope? Org Topologies works at the level of the entire organization or parts (divisions, groups, teams). You may wonder: Why another approach? And you would be right, as the market is full of canned change ‘solutions.’ OT offers a custom  path by inviting you and your people to create  your change, not consuming common yet often mediocre ideas. 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. OT helps to overcome those significant change risks by making it possible for people to visualize, discuss, understand, and finally shape the  change that’s fit for their  purpose. Strategic Org Design Org Topologies, being a strategic org design system , helps you align all the moving pieces so that your (1) business strategy, (2) organizational goals, and (3) change process work together cohesively to drive the desired organizational performance. The OT toolset equips leaders to: Visualize and map the current organization at the level of divisions, groups, teams, and individuals. Evaluate and highlight areas where the org structure supports or hinders performance. Address the critical questions: What is strategically important now versus long-term? What requires immediate focus, and what can wait? Create a shared vision of organizational change and define incremental low-risk steps towards the chosen direction. Drive systemic, transparent, and lasting change while maintaining operational momentum and flexibility. Identify where AI will best support an org goal and business objective. Leaders, powered by Org Topologies, can provide a lasting competitive advantage to their organizations by paving a systematic, well-designed path to sustainable change. Benefits of Org Topologies In general, OT helps organizations to get change going  by offering them a systemic change management method that allows to: Discover options to improve the performance of product development and service organizations. Learn to apply long-term optimizations over short-term quick fixes. Define the North Star for organizational development, ensure that it stays fit for purpose. Have the tools to assess, monitor, and progress toward a target state. Establish a shared language to communicate organizational development and engage everybody in the change. Prevent costly reorganizations, through design experiments and continuous improvements. Own the change and provide clarity on the target org design and the reasons for change. Make org design one of the critical managerial tools to gain a competitive advantage. Download the Primer for more details on how Org Topologies help drive strategic org design.