ORG TOPOLOGIES 

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.

The Org Topologies MADE method introduces Elevating Katas to get change going. “Kata” was popularized in management via Toyota, implying a disciplined and repeating pattern for improving. Each Elevating Kata is a repeatable, structured pattern or routine 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. Each Kata targets a specific org design element (structure, policy, process, …) and aims to shift in ways that provide incremental and scalable improvements. When we speak of Elevating Katas we mean specific interventions or methods that guide an organization from its current level of maturity and flow towards more effective, systemic, and higher-order modes of working. Each kata focuses on a particular area (such as governance, practices, roles, events, or artifacts) and is designed to shift mindsets, structures, or processes in a way that provides incremental, scalable benefits over time. By repeatedly practicing an Elevating Kata, organizations internalize more adaptive behaviors, enhance their management capabilities, and ultimately create a more responsive and learning-oriented culture. Key characteristics of Elevating Katas include: Purposeful Routine:  They are not one-off changes but ongoing practices that teams perform regularly. Incremental Improvement:  Each iteration builds on the last, gradually increasing proficiency and confidence. Systems-Level Focus:  They often address underlying organizational design elements—like governance models, role definitions, and multi-team events—to improve end-to-end product delivery. Empowering Teams and Leaders:  By embedding these katas, organizations empower members at all levels to take ownership, adapt quickly, and focus on value. Cultural Shift:  Over time, Elevating Katas influence not just processes, but also the culture, encouraging transparency, continuous learning, and a broader understanding of “product” and customer outcomes. In short, Elevating Katas are deliberate, repeatable, systemic, and strategic improvement routines that help organizations lift their practices to a higher, more impactful level. "STRATEGIC" IS THE KEY HERE Below is the method we've crystalized over the year that leads the way to strategic org design : "Change MADE Real" method You can  learn about the Change MADE Real  method and its four steps, as it is essential to understand the MADE method to see the place of Elevating Katas in the landscape of Org Topologies. Elevating Katas are principles, guidelines, and practices for systemic change. They are vehicles for the MADE method as they drive the elevation of an org ecosystem towards the top right archetype group of the map: Elevating Katas in the MADE method Here's how to make sure that the application of Elevating Katas is systemic: Holistic Focus The Star Model suggests that changes must work at the system level, not just tweak one element. Elevating Katas, by their nature, aren’t isolated improvements; they target multiple facets—governance, roles, events, practices, and artifacts—ensuring shifts in behavior permeate through structures, processes, and ultimately how people collaborate. Aligning Structures and Processes With Strategy For an organization’s strategy to truly drive capabilities, the operational design must support it. Elevating Katas introduce routines (such as multi-team Product Backlog Refinement or vertical slicing of work) that bring strategic goals into daily practice. This ongoing, repeated alignment of work routines with strategic direction ensures that structure and processes consistently support the desired capabilities and outcomes. Enabling People and Role Evolution The Star Model emphasizes that people and their roles must be in sync with overall organizational design. Elevating Katas like “Elevate Product Ownership” push beyond conventional role definitions, helping individuals expand their influence and understanding. Over time, these repeated learning loops shape new competencies, reinforce role clarity, and ensure that teams operate in harmony with new structures and strategic objectives. Reinforcing Desired Behaviors and Culture “Culture programs” on their own often fail because they focus on abstract values rather than tangible changes in working patterns. Elevating Katas bridge the gap between desired cultural traits (like collaboration, customer-centricity, or continuous improvement) and everyday actions. By practicing these Katas systemically, the organization hardwires new behaviors into its fabric, leading to a naturally evolving culture—rather than attempting top-down cultural mandates. 5. Rewarding Continuous Improvement Because Katas are iterative and repeatable, they create a continuous feedback loop. Over time, as these new practices become second nature, the organization inherently “rewards” them through improved outcomes—faster cycle times, better product-market fit, and more engaged teams. This closes the loop between the “Rewards” element of the Star Model and the actual behaviors that drive performance and cultural evolution. Elevating Katas serve as the micro-level routines that continuously align the various elements of organizational design. They turn strategic intent into actionable steps, align structures and processes, enhance roles and competencies, and reinforce behaviors—thereby making the entire system function cohesively, just as the Star Model prescribes. EXAMPLES OF ELEVATING KATAS Elevating Katas are not one-off workshops or temporary campaigns. Instead, they are ongoing, disciplined practices that embed a new way of thinking and acting into the organization’s fabric. Each kata focuses on a particular dimension of how work is done—governance, roles, events, practices, or artifacts—offering a continuous improvement loop. By systematically revisiting and refining these routines, teams learn incrementally and develop deeper capabilities. Below are some examples to give you a taste of what the Katas are. Kata: Expand the “Product” Definition Teams regularly revisit and broaden their view of the “product” to include not just a single application or service, but the entire ecosystem of customer experience, business processes, and complementary offerings. Kata: Elevate Product Ownership Product owners move beyond backlog management to become strategic influencers, actively connecting business goals with delivery teams. By consistently engaging in strategic alignment sessions and working closely with customers and stakeholders, product owners gradually learn to prioritize work that delivers the highest impact. Read more . Kata: Hold Multi-Team Product Backlog Refinement (PBR) Multiple teams that share a product domain collaborate in joint refinement sessions. Practicing multi-team PBR regularly ensures alignment, surfaces dependencies early, and harmonizes priorities across different delivery groups. Read more . Kata: Slice Work Vertically Rather than building features layer by layer (e.g., back-end first, then front-end), teams deliver thin, vertical slices of functionality that span the user interface, business logic, and data layer. Repeatedly practicing vertical slicing enables the team to deliver incremental value faster and reduce the risk of late integration issues. Kata: Merge Product Backlogs Instead of each team maintaining its own isolated backlog, organizations merge them into a single, shared product backlog. This practice, repeated regularly, leads to unified prioritization and improved transparency, ensuring that all teams work toward the same strategic objectives. Kata: Define Shared "Done" Teams adopt and periodically refine a common set of quality criteria that must be met before work is considered complete. Repeated application of this kata drives consistent quality standards and reliability across teams. Read more about DoD in LeSS . Kata: Self-Select with Open Space and FAST One way to sustain a broader work mandate is to allow teams and individuals within the Team-of-Teams to self-select work and their peers with the necessary skills to create value together. Read more about FAST , which stands for "Fluid Adaptive Scaling Technology".  To facilitate self-selection at scale, this method combines 1) outcome-based product management, 2) open space technology, and 3) dynamic re-teaming. Kata: Implement Beyond Budgeting Organizations abandon rigid, annual budgeting cycles in favor of rolling forecasts, dynamic resource allocation, and more decentralized decision-making. Over time, this kata helps the organization become more responsive, adjusting investments as market conditions evolve. Read more on Beyond Budgeting . Kata: Lead with OBEYA Strategically Borrowed from lean management, “Obeya” involves creating a dedicated space (physical or virtual) where decision-makers convene regularly. By visually displaying strategic metrics, progress indicators, and customer feedback, leaders can make more informed, rapid decisions. Read more about Leading with Obeya . Katas: Design Tailwind Career Paths Instead of promoting through narrow, hierarchical ladders, individuals advance through capability growth and learning breadth. This kata involves regularly identifying new skill areas, setting capability-building goals, and providing supportive conditions—coaching, resources, and challenging projects—so individuals continuously gain new competencies. Over time, by repeating this practice, organizations cultivate multi-skilled, adaptable professionals whose career “tailwinds” come from developing a broad, flexible skill set aligned with strategic needs rather than climbing a predefined ladder. Read more . Kata: Apply AI Strategically 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. 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. More on applying AI strategically . Kata: Measure and Improve Value with EBM 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. More on OT with EBM . More Katas We are collecting and documenting Elevating Katas. Browse our Knowledge Base to learn more. Toward a Collection of Elevating Katas Conclusion Leaders, rather than micromanaging or launching episodic “transformation programs,” can establish a handful of carefully chosen katas and ensure they are faithfully practiced. Over time, as people develop fluency in these routines, the organization’s agility and resilience increase. This approach to change is subtle but powerful, as it leverages the human capacity to learn by doing. Rather than relying solely on workshops or memos, it uses ritualized action to shape behavior and mindset. Elevating Katas embody the principle that lasting organizational change arises from systemic coherence and incremental, behavioral shifts. By focusing on daily routines—how teams refine backlogs, how product definitions are broadened, how budgets are allocated, and how product owners engage with strategy—these katas directly influence the elements of Galbraith’s Star Model. The result is a more agile organization, one that continuously aligns its strategy, structure, processes, people, and rewards. These katas do not offer a magic bullet; they demand patience, consistency, and intentional practice. Yet, this very requirement ensures authenticity. As habits form, culture evolves organically, and the organization’s capacity to learn and adapt deepens. In a world where the only constant is change, Elevating Katas serve as reliable instruments for shaping the future, guiding organizations toward sustained performance, relevance, and growth.

Scrum is often implemented at the team level, which can limit achieving business agility at scale. Moving beyond this "team-level agility" to a more holistic approach fosters in-team and inter-team collaboration, aligning with the " second wave of Agile ": Drive the Second Agile Wave Five Reasons To Elevate Scrum Overcome Limitations of Team-Level Scrum : Solely implementing Scrum at the team level can create silos and hinder cross-team collaboration, leading to dependencies, integration issues, and slower delivery. Achieve Business Agility : Elevating Scrum enables organizations to respond to changing customer needs and market demands more effectively by fostering collaboration and alignment across multiple teams working towards shared business goals. Enable Innovation : By breaking down silos and promoting a holistic view of product development, elevating Scrum empowers teams to experiment, learn, and adapt more quickly, leading to increased innovation and better customer outcomes. Optimize for Flow and Learning : Elevating Scrum involves optimizing for both flow efficiency (delivering value quickly) and outcome orientation (focusing on business results), resulting in a more adaptable and resilient organization. Enhance Human Potential : Moving from task-focused work to a more collaborative and outcome-oriented approach, elevating Scrum enables individuals to contribute their full potential and derive greater satisfaction from their work. How to Elevate Scrum? Establish a Single Product Backlog : Instead of separate backlogs for each team, create a single product backlog reflecting the organization's strategic priorities and customer needs (OKRs work nicely here), aligning all teams towards shared goals and reducing dependencies. Empower Product Owners : Ensure Product Owners understand customer needs and business objectives, and are empowered to make decisions that optimize value delivery. Elevate their role from managing team-level backlogs to owning a broader scope that aligns with business outcomes. Foster Cross-Team Collaboration Implement practices such as multi-team product backlog refinement , shared sprint goals, and joint sprint reviews to facilitate knowledge sharing, collaboration, and alignment across teams. Promote Shared Ownership : Encourage teams to take ownership of a broader scope of work that extends beyond their immediate areas of expertise. This involves cross-training team members, promoting a culture of learning, and breaking down silos between development, testing, operations, and other functions. Focus on Business Value Delivery : Define and track metrics that measure the organization's ability to deliver business value, such as customer satisfaction, revenue growth, and time to market. Use these metrics to guide decision-making and continuous improvement efforts. Continuously Adapt and Improve : Regularly assess the organization's product development maturity and identify areas for improvement. Experiment with new practices and tools, using data and feedback to drive continuous adaptation and optimization. By implementing these steps, organizations can elevate their Scrum practices from team-level implementations to a more holistic approach that unlocks the full potential of agility and enables them to thrive in today's rapidly changing business environment. Contrasting Team-Level Scrum and Elevated Scrum Team Level Scrum Elevated Scrum Mapping per Org Topologies Typically: A2 or A3 Moving Towards B3 or C3 Focus Primarily on feature delivery within a defined scope Shifting from a feature-centric to a holistic product or business area focus Structure Multiple Scrum teams, often structured around specific technologies, components, or feature sets Moving away from rigid team structures towards more fluid and adaptable models, such as a "team of teams" working collaboratively on a shared business area Product Backlog Teams maintain separate product backlogs, leading to potential dependencies and coordination challenges Transitioning to a single, elevated Product Backlog encompassing a broader scope of work and fostering a unified product vision Product Owner Each team has a dedicated Product Owner focused on maximizing value within their team's scope Ideally, a single, senior Product Owner with a strategic perspective and authority to make decisions across the elevated scope Top challenges of Team-Level Scrum: Siloed Work : Teams may operate in isolation, hindering cross-team collaboration and leading to a fragmented product vision. Limited Adaptability : Responding to shifting priorities or emerging opportunities may require significant effort due to static team structures and backlogs. Dependency Management : Reliance on other teams for specific skills or components can introduce bottlenecks and slow down value flow Key benefits of Elevated Scrum: Enhanced Adaptability : Teams can easily adjust their focus based on evolving priorities reflected in the unified backlog. Improved Flow of Value : Breaking down silos enables smoother collaboration, reducing dependencies, and accelerating value delivery. Greater Business Alignment : Aligning all teams to a shared backlog and strategic goals increases the impact and relevance of their work. Increased Learning and Innovation : Teams are encouraged to acquire new skills and collaborate across disciplines, fostering a culture of continuous learning and innovation. Key Considerations When Elevating Scrum Leadership Buy-in and Support : Elevating Scrum requires a significant shift in mindset and organizational culture, necessitating strong leadership support to overcome resistance and drive transformation. Shared Understanding and Alignment : Establish a shared understanding of the target operating model, the rationale for change, and the implications for different roles and teams within the organization. Gradual and Iterative Approach : Transforming to an elevated Scrum model is best approached iteratively, starting with smaller pilots or experiments to validate assumptions and refine the approach based on learnings. Key thing to note: elevating Scrum is an org design change. Hence, your management must be involved in this activity, their mere blessing and delegation won't make it a successful transformation. They need to own it and be elevated in their thinking as well. (C) 2024, Flemm & Krivitsky

High-Level Structure of this Article Haier's Transformation Bayer's Transformation Similarities and Differences: RDHY and DSO Studying Org Designs of RDHY Studying Org Designs of DSO Comparing and Contrasting the Two Models Putting It All Together 1. Haier's Transformation The Haier Rendanheyi model ( RDHY ) is an innovative management philosophy developed under the leadership of Haier’s founder, Zhang Ruimin. It represents a radical departure from traditional hierarchical structures by aiming to align every employee’s efforts directly with customer (or user) value creation. Haier’s journey toward a decentralized, customer‑centric organization began in earnest around 2005 . This marked a radical shift away from traditional hierarchical management. Over the following years, and especially around 2012 , Haier further refined its approach by breaking its operations into thousands of micro‑enterprises that directly interact with users, thus institutionalizing the principles of entrepreneurial autonomy and customer‑focused value creation. Reduced hierarchical layers from 12 to 3 across all subsidiaries, achieving a 67% faster decision-making cycle compared to 2021 benchmarks. By 2025, Haier aims to have 60% of revenue from ecosystem services through enhanced AI integration and cross-industry partnerships. Haier's Stock (Qingdao Haier) as of Feb 2025 2. Bayer's Transformation Bayer’s Dynamic Shared Ownership ( DSO ) is a sweeping transformation of its traditional hierarchical structure into a more agile, decentralized system—one that shifts decision‐making and ownership closer to the frontline. Much like Haier’s RenDanHeYi model, DSO is designed to empower employees and create a more responsive, customer‑centric organization, but it emerges from a very different corporate context and set of challenges. Bayer began restructuring its traditional pyramid‑shaped organization into small, empowered squads around 2018–2019 . This initiative accelerated significantly around 2020  in response to performance challenges and the need for faster, market‑responsive decision‑making. The creation of agile, cross‑functional squads is a more recent development of their model. The goal has been to shift power to the frontline teams—while still maintaining interdependent coordination through digital platforms and agile processes. It is still early to judge the success of the DSO's implementation, as Bayer has been just a few years into the change (compared to Haier, who started almost 20 years ago). As of February 2025, Bayer's CEO Bill Anderson, who was appointed in 2023, continues to lead Bayer through a major restructuring program aimed at reducing hierarchy and cutting costs by €2 billion by 2026. Bayer's recovery toward a shiny future is likely still ahead. Bayer's Stock ( BAYN) as of Feb 2025 3. Similarities and Differences: RDHY and DSO While both Haier’s RenDanHeYi and Bayer’s DSO share similar ambitions—namely decentralizing decision‑making, empowering frontline employees, and focusing on customer value—the contexts and drivers differ: Origin: Haier’s model was born out of the need to transform a manufacturing company in a rapidly evolving market in China, whereas Bayer’s DSO is a response to internal performance challenges and the demands of a global pharmaceutical and life sciences conglomerate. Structure: Haier’s approach breaks the organization into thousands of micro‑enterprises and ecosystem micro‑communities, while Bayer is reconfiguring its structure into autonomous, cross‑functional squads within a “flat army.” Cultural Drivers: Both models require a significant cultural shift. Haier’s journey was about aligning every employee’s value with customer value, and Bayer’s DSO is similarly designed to transform mindsets from hierarchical control to shared, mission‑driven ownership. In Summary Haier: Most of the company’s employees are reorganized into micro‑enterprises (and aggregated into ecosystem micro‑communities), but some functions—especially those providing centralized support—might remain outside of the direct micro‑enterprise structure. Bayer: A significant portion of the workforce is restructured into agile, cross‑functional squads, yet certain central functions and employees in corporate support roles are not organized in this way. 4. Studying Org Designs of RDHY Core Principles of RDHY 1. Human-Centric Value Creation At its heart, the model is built on the idea that “Ren” (人, meaning “people” or “employees”) and “Dan” (单, referring to “orders” or customer demands) should be “HeYi” (合一, meaning “integrated”)—in other words, the personal value of every employee is directly tied to the value they create for users. This “win-win” concept drives a culture where every individual is seen as an entrepreneur , with incentives and rewards linked to how well they serve customer needs. 2. Decentralization and Self-Organization Traditional middle management and rigid bureaucracies are replaced with a network of micro‑enterprises (MEs) or autonomous units. Each of these small units (often composed of about 10 people) operates almost like an independent startup within the larger organization. This decentralization enables rapid decision-making and agile responses to customer feedback, leading to what Haier calls “zero distance” between the employee and the end‑user. 3. Entrepreneurial Autonomy Rather than a top‑down, command‑and‑control system, the Rendanheyi model delegates authority to the lowest levels. Employees are given not only decision‑making power but also a share in the success of their projects. This entrepreneurial spirit is encouraged through systems that reward innovation and accountability, making every micro‑enterprise responsible for its own profit and loss . Work Units of RDHY Haier’s RenDanHeYi model isn’t limited to just the autonomous micro‑enterprises (or MEs). Over time, the model has evolved to include several complementary unit types: Micro‑enterprises (MEs): MEs in the Haier RenDanHeYi model are small, autonomous business units—typically comprising 10 to 15 employees—that operate as independent profit-and-loss centers within the larger corporate structure. They are empowered to make critical decisions, hire and manage talent, and directly engage with customers to identify and meet their needs, thereby fostering a highly entrepreneurial culture where every employee acts as a mini‑entrepreneur. These MEs are the foundational building blocks of Haier’s decentralized, agile organization, and they often collaborate and interconnect through ecosystem micro‑communities (EMCs) to share resources and co‑create value, ensuring that the company remains responsive, innovative, and closely aligned with market demands. Ecosystem Micro‑Communities (EMCs): Micro‑enterprises are not isolated; they are designed to interconnect. Groups of micro‑enterprises come together to form EMCs, which are essentially clusters or communities that collaborate to address more complex user scenarios. In practice, EMCs are often divided into subtypes (for example, “solution EMCs” and “experience EMCs”), with one set focusing on developing solutions (such as R&D or manufacturing) and the other on user engagement and experience. This grouping helps the organization tackle larger market challenges while still maintaining the agility of small entrepreneurial units. Supporting Shared Services and Platforms: In addition to micro‑enterprises and EMCs, Haier has built internal service platforms that function as support units. These platforms manage essential services—such as HR, procurement, and logistics—thereby reducing the need for traditional middle management and allowing the micro‑enterprises to focus on value creation and customer engagement. For example, platforms like COSMOPlat serve as internal marketplaces where these units can interact, bid for services, or share resources in a transparent, market‑based manner. Together, these three layers create a dynamic ecosystem in which individual entrepreneurial units drive rapid innovation and customer-centricity, while centralized platforms and inter-unit communities ensure coordination and resource sharing across the entire enterprise. Disclaimer Below are publicly available real-life examples (see the References at the end of the article). It is worth understanding that these are probably some of Haier's most advanced and successful cases -- that's why they have been promoted. These examples are great for illustrating the power of the model. When we later in the article illustrate the mapping of these teams with Org Topologies, it is worth remembering that those assessments are likely the outliers -- in the positive direction. We predict that not all the teams at Haier are as advanced and would probably be assessed lower on the map. The same applies to Bayer's example teams, which are assessed further below. Our intention is not to create a statistically correct assessment -- we simply lack the data for such a study. Our goal is to show the qualitative (not quantitative) potential of these two very different models. Our mission is to inspire other organizations to get the change going . Real-Life Examples of MEs Mask Supply Microenterprise: During the COVID‑19 pandemic, a small group of Haier employees recognized a critical shortage of protective masks. They quickly formed an ME to source raw materials, organize production, and distribute masks at scale. While it emerged to solve a specific crisis, it evolved to manage the entire supply chain for this product line, leveraging external suppliers and digital tools for smart contracting. Smart Home Appliance Microenterprise: One of Haier’s flagship MEs focuses on the development of integrated smart home solutions. This unit is tasked with designing, producing, and continuously refining products like refrigerators, washing machines, and air conditioners by directly engaging with customers. Its work spans the entire value chain—from R&D and manufacturing to marketing and service—and it often collaborates with other MEs within an Ecosystem Micro‑Community (EMC) to address complex user scenarios. GE Appliances Microenterprise (Global Adaptation Example): Following Haier’s acquisition of GE Appliances, parts of the U.S. business were reorganized into autonomous micro‑enterprises. Each ME targets a distinct product line (for example, air conditioners or washing machines) and is empowered to handle everything from product innovation to market launch, tailoring solutions to local customer needs. This structure has allowed the unit to operate with startup-like agility while contributing to the overall brand’s performance. Mapping Haier's Org Design with Org Topologies The Org Topologies map offers a visual aid to help make sense of the org design, beyond frameworks and ambiguous terminology. The horizontal axis represents the Scope of Skills Mandate: the levels of skill composition that work units are allowed to apply doing certain work. From being Functional to End-to-End and even Expanding beyond that. The vertical axis represents the Scope of Work Mandate: the levels of work that the units are expected to perform. From the lowest Task level to Partial and even Whole Business. Below are the assessments of the sample value-creating units of the Haier's RDHY model: Mask Supply Microenterprise Horizontal:  Expanding – Although this unit initially formed with a functional/multi‑skill  base to address a crisis, it rapidly integrated external partners and digital contracting, continuously acquiring new capabilities. Vertical:  The unit is responsible for a specific product line (protective masks) and manages a substantial portion of the supply chain without covering a fully diversified business, hence assessed as Partial‑Business Focus level. Smart Home Appliance Microenterprise Horizontal:  This flagship unit covers the entire value chain (from R&D and manufacturing to marketing and service), operating independently to deliver complete End‑to‑End smart home solutions. Vertical:  It functions as an independent profit‑and‑loss center with Partial‑Business Focus , managing a complete business segment that delivers end‑to‑end value to customers within the larger landscape of Haier's product lines and services. GE Appliances Microenterprise Horizontal:  Following Haier’s acquisition, this unit was reorganized to handle an entire product line (e.g., air conditioners or washing machines) with full End‑to‑End autonomy, mirroring a startup-like approach. Vertical:  It is structured as a standalone profit center responsible for delivering a complete business solution in its segment: Partial‑Business . Each of these units is dedicated to a distinct product line (for example, air conditioners  or washing machines ) and is empowered to manage everything from product innovation to market launch. Here's the visual representation of the assessment: Haier's RDHY Model: Assessing Value-Creating Units Now let's assess the Supporting Shared Services and Platforms Horizontal: These are typically mapped between the Multi‑Skill  and Expanding levels as they are capable of building internal service platforms. We don't possess the exact details of their composition or dependencies on other units, so we assume they are mostly complete units. Vertical: Positioned in the Task Focus to Capabilities Focus  range. Their responsibility is narrowly defined—to manage critical support tasks and provide operational capabilities. They do not handle complete business outcomes but instead, ensure that the processes and resources are in place for the MEs and EMCs to function efficiently. On the map, it looks like this: Haier's RDHY Model: Assessing Supporting Units We did not assess Ecosystem Micro-Communities (as clusters of MEs) because our focus is on fine-grained work units. Evaluating larger groups, such as ecosystems or business divisions, does not accurately reflect workers’ mandates and usually creates a misleading picture. 5. Studying Org Designs of DSO Core Principles of DSO 1. Mission‑Driven Value Creation Bayer is shifting the focus from traditional quarterly KPIs to outcomes that are aligned with its long‑term mission —"Health for all, Hunger for none." This means that decisions and rewards are now tied directly to how well teams create real, tangible value for customers. 2. Network of Autonomous, Cross‑Functional Teams Instead of a rigid, top‑down hierarchy, Bayer is restructuring into a “flat army” of multidisciplinary, self‑governing teams (often referred to as “squads”). These teams are empowered to make decisions independently, drawing on diverse skills that span functions such as R&D, marketing, and supply chain management. This decentralized model encourages faster, more informed decisions at the point of customer contact. 3. Shared Ownership and Empowerment DSO replaces conventional management control with shared ownership. In practical terms, this means that frontline employees—from field sales reps to technical advisors—are given real decision‑making authority and are held accountable for outcomes . Their performance and even their compensation become directly linked to the value they deliver to customers, fostering a strong entrepreneurial spirit across the organization. Work Units of DSO Bayer’s Dynamic Shared Ownership (DSO) model reconfigures the organization into several types of work units that work both autonomously and collaboratively. Although detailed internal information is not fully disclosed publicly, industry reports and management insights suggest that Bayer’s new structure includes the following key units: Agile Squads: These are small, cross‑functional teams (typically 5–15 members) composed of employees from various disciplines—such as R&D, marketing, sales, and supply chain—who are empowered to make quick, autonomous decisions. Squads are responsible for executing on specific projects or market opportunities and are oriented toward rapid innovation and customer responsiveness. Cross‑Functional Cells: In certain strategic areas, Bayer has set up specialized cells that bring together experts from multiple functions to tackle complex, integrated challenges. These cells often work on end‑to‑end value creation projects, such as new product development or digital transformation initiatives, ensuring that every aspect from conception to market delivery is coordinated. Centralized Support Platforms: Although the aim is decentralization, Bayer maintains certain central service units that provide shared standardized functions and services (e.g., IT, HR, procurement, finance) that underpin Bayer’s agile squads. These platforms support the agile squads by delivering standardized tools, resources, and process frameworks that enable faster decision‑making and smoother inter‑team collaboration. Rather than engaging directly in market‑facing innovation, they streamline operations, reduce overhead, and enable faster decision‑making by automating routine tasks and ensuring consistent processes across the organization. Integration and Coordination Forums: These forums, which include regular “scrum‑of‑scrums” meetings, digital collaboration platforms, and designated liaison roles, exist to synchronize the work of Bayer’s agile squads. They facilitate the sharing of progress, resolution of inter‑squad dependencies, and alignment of outputs with overall corporate strategy. Essentially, they serve as the glue that connects autonomous teams while ensuring that collective efforts drive toward shared business outcomes. These forums ensure that while squads operate independently, their outputs and strategic directions are aligned with overall corporate objectives. Each of these work units contributes to the overall DSO approach by combining decentralized autonomy with the necessary mechanisms for coordination and shared value creation. This blend of independence and interdependence is central to Bayer’s efforts to transform into a more responsive and innovative organization in today’s fast‑paced market environment. Disclaimer There is not much information publicly available on this model compared to the RDHY. For once, DSO is much younger. Secondly, its power is yet to be seen. Lastly, all the information we are basing our assessment on has been pushed out by Bayer's marketing itself, which is likely their best-case scenario and some early, hard wins. So, we hardly know anything about the model's downsides and how broadly the model has been adopted in the enterprise. Yet, not being quantitatively accurate, we believe that our analysis can be useful to see the potential of the DSO model (not its particular implementation at Bayer, which is yet to be studied thoroughly in years to come). In any case, DSO is by far the boldest change model that we know of in the pharma and chemical industry. If it is proven to be successful, we will see its spread in the industry. Then, we will get more data and insights to perform a more thorough study. Real-Life Examples of Squads Bayer Crop Science Squad (Southern Iowa): Led by Barry Jacobson in Bayer Crop Science, this squad is composed of field sales representatives, technical agronomists, and customer business advisors. The team is tasked with rapidly developing proposals based on direct interactions with farmers and local ag retailers. They identify specific challenges in the field, collaboratively design solutions, and implement them without the delays of traditional approval hierarchies. Their work has led to faster decision‑making and improved responsiveness to market needs, directly aligning with Bayer’s push for frontline empowerment. Bayer Italian Innovation Squad (Healthcare/Pharma): In Bayer’s European operations, an agile squad was formed to address a pressing healthcare challenge. This team, drawing talent from R&D, design, and operations, collaborated to develop a tool designed to make injections easier for hemophiliac patients. By rapidly iterating their solution over a period of just 2–3 months, the squad demonstrated high responsiveness and creativity. Their cross‑functional collaboration allowed them to innovate swiftly while directly addressing user pain points—a critical aspect of Bayer’s transformation. Bayer Global Design Teams: Bayer has instituted around 70 design teams globally, which operate as agile work units responsible for redesigning key corporate processes—ranging from supply chain management to digital transformation initiatives. These teams work cross‑functionally to reengineer and optimize processes across the organization. Their efforts are critical for aligning disparate parts of the business under the new Dynamic Shared Ownership (DSO) model, ensuring that innovation and efficiency improvements are integrated throughout Bayer’s operations. Mapping Bayer's Org Design with Org Topologies Similar to Haier's assessments above, below are the Org Topologies mapping for Bayer's sample value-creating units: Bayer Crop Science Squad Horizontal:  This cross‑functional Multi‑Skill squad (including field sales reps, technical agronomists, and customer advisors) combines diverse expertise to develop and execute market-specific solutions. Vertical:  It is focused on a specific segment within the crop science division ( Partial‑Business Focus ), delivering targeted outcomes rather than managing an entire business. Bayer Italian Innovation Squad Horizontal:  This   agile squad, drawing talent from R&D, design, and operations, was able to take a healthcare innovation (a tool for easier injections) from concept to market in 2–3 months, delivering a complete End‑to‑End solution. Vertical:  Their mandate is centered on a specific innovation project within the healthcare/pharma segment ( Partial‑Business ) rather than an entire business vertical. Bayer Global Design Teams Horizontal:  Composed of multidisciplinary experts, these teams work on comprehensive process redesign and digital transformation, integrating a wide array of skills to deliver full solutions ( End‑to‑End ). Vertical:  Their primary focus is on enhancing and optimizing operational processes (e.g., supply chain, digital workflows) rather than managing a complete business line, assessed as a Capabilities Focus . Below is the visual representation of this assessment: Bayer's DSO Model: Assessing Value-Creating Units Below is the Org Topologies mapping of the sample supporting units of Bayer: Centralized Support Platforms Horizontal:  These platforms support the agile squads by delivering standardized tools, resources, and process frameworks that enable faster decision‑making and smoother inter‑team collaboration. That sounds like spanning the whole range from Functional to End-to-End . Vertical:  Placed in the Task Focus  to Capabilities Focus  range. Their work mandate is narrowly defined—they are responsible for specific support tasks or developing certain operational capabilities, not for managing a complete business or customer value chain. Integration and Coordination Forums These are merely events and virtual teams, so we won't assess them. And now on the map: Bayer's DSO Model: Assessing Supporting Units 6. Comparing and Contrasting the Two Models Both Haier’s micro‑enterprises (MEs) and Bayer’s agile squads are advanced work units—but they excel in different dimensions of organizational transformation: Haier’s Micro‑Enterprises (MEs): These units are highly advanced in terms of decentralization and entrepreneurial empowerment. Each ME functions as an independent profit‑and‑loss center with full decision‑making authority and direct customer engagement. Their structure not only dissolves traditional hierarchical boundaries but also integrates deeply into larger Ecosystem Micro‑Communities (EMCs), enabling a near‑seamless alignment between employee incentives and user value creation. This radical shift—where nearly all operating staff are treated as mini‑entrepreneurs—is a breakthrough in dismantling bureaucracy and fostering sustained innovation. Bayer’s Agile Squads: Bayer’s squads are advanced in adopting agile, cross‑functional collaboration within a traditionally hierarchical, large multinational context. These squads (typically 5–15 members) are empowered to work rapidly and iteratively, leveraging digital collaboration tools to shorten decision cycles and respond to market demands quickly. Although they enjoy significant autonomy on project‑specific tasks, they still operate within a framework that includes centralized support functions for strategic alignment and resource sharing. This approach excels in creating rapid, flexible responses but may not be as radically decentralized as Haier’s MEs. Both Models rely on the Shared Supporting Units that enable the work units by offering standardized commodity services and platforms Managing Interdependency with Digital Contracting and Agile Coordination MEs and Squads can do a lot independently, yet they are interdependent and should not function as broader silos but rather find ways to collaborate with each other. Here, Haier and Bayer apply different strategies to achieve that. Digital contracting  is a cornerstone of Haier’s RenDanHeYi model, enabling its vast network of micro‑enterprises (MEs) to function as an integrated, agile ecosystem. Rather than relying on traditional, paper‑based agreements, Haier employs digital contracting through platforms like COSMOPlat and the Workbench. These systems utilize smart contracts and blockchain  technology to automate and secure agreements between MEs and their external partners. When an ME issues a digital tender  for a service or resource, competing units bid for the work, and once agreed upon, the contract is automatically executed and recorded on a blockchain. This not only streamlines negotiations and minimizes errors but also ensures that payment is directly linked to the value created for customers—embodying Haier’s “paid by users” principle. In essence, while each ME operates with significant autonomy, digital contracting ensures they remain interdependent, sharing resources and expertise across Ecosystem Micro‑Communities (EMCs). In contrast, Bayer’s Dynamic Shared Ownership (DSO) model addresses alignment and coordination among its agile squads through a set of complementary digital and procedural tools . To manage dependencies across these squads, Bayer employs agile ceremonies  such as “scrum‑of‑scrums,” where representatives from different squads meet regularly to synchronize efforts, resolve conflicts, and ensure alignment with the company’s broader strategy. Additionally, Bayer relies on digital collaboration platforms  that provide real‑time transparency through shared dashboards, performance metrics, and project updates. Dedicated liaison roles further facilitate coordination by managing inter‑squad dependencies, ensuring that overlapping resources and joint initiatives are effectively integrated. In summary, Haier’s digital contracting system transforms micro‑enterprises into semi‑independent, entrepreneurial nodes that operate through automated, transparent agreements—ensuring that autonomy is balanced with ecosystem collaboration. Bayer’s DSO, on the other hand, emphasizes agile alignment among its squads through structured coordination mechanisms, digital tools, and dedicated liaison roles. Both approaches aim to dismantle traditional hierarchies, yet Haier’s model focuses on creating a tightly integrated digital marketplace for value exchange, while Bayer’s strategy is centered on aligning and coordinating autonomous teams within a larger corporate framework. 7. Putting It All Together Haier’s RenDanHeYi model, initiated around 2005 and refined by 2012, dismantles traditional hierarchies by reorganizing most employees into small, autonomous micro‑enterprises that operate within an interconnected ecosystem. It decentralizes the organization into small micro‑enterprises (MEs) that are integrated into a broader ecosystem through digital contracting and Ecosystem Micro‑Communities (EMCs). On the horizontal axis (scope of skills mandate), these units are positioned as "end-to-end" to “expanding”—they begin as end‑to‑end units but continuously acquire new skills and external capabilities via digital tools. Vertically (scope of work mandate), some MEs (e.g., Smart Home Appliance or GE Appliances units) are mapped as “partial business” because they manage the full value chain for a given product line, while others—like the Mask Supply Microenterprise—operate at a “partial business” level, focusing on a specific product segment with some dependency on shared services. Org Topologies mapping of Haier's RenDanHeYi (RDHY) Model In contrast, Bayer’s Dynamic Shared Ownership (DSO) model— an ongoing roll-out started in 2018 —restructures the organization into agile, cross‑functional squads that work rapidly on specific projects. Bayer’s squads, supported by centralized platforms and coordination forums, are generally positioned as “multi‑skill” units with a “partial business” mandate. On the horizontal axis, these squads generally fall within the “multi‑skill” to “end‑to‑end” range, reflecting their integration of diverse expertise to rapidly deliver innovations and adapt to market feedback. Vertically, the squads are mostly positioned in the “capabilities” to “partial business” zone, as they are tasked with delivering specific projects or capabilities rather than running an entire, standalone business. In addition, Bayer reinforces alignment and coordination through centralized support platforms and integration forums that help manage interdependencies among squads. Org Topologies mapping of Bayer's Dynamic Shared Ownership (DSO) Model Both models aim to shift decision‑making to the frontline and foster customer‑centric innovation. Yet, Haier’s approach is more radically decentralized and ecosystem‑integrated, while Bayer’s model emphasizes agile alignment within a flatter, more coordinated corporate framework. We long to see how the two models play out in the future: a broader spread of RDHY to the West and the DSO's promise to help Bayer cut costs with self-management and a shortened distance to the customers. The Org Topologies mapping offers a radical new approach to a shared language. This enables us to analyze different scaling frameworks and change models more thoughtfully to focus on what truly matters — elevating the locked intelligence power of organizations. Sources and references used in this study Management Innovation Made in China: Haier’s Rendanheyi  (PDF, July 2018, California Management Review / ResearchGate). The 4th International Rendanheyi Model Forum – Haier  (Haier’s official global website). RenDanHeYi: Pioneering the Quantum Organisation  (Global Focus Magazine). Zhang Ruimin  (Wikipedia page). Shattering the status quo: A conversation with Haier’s Zhang Ruimin  (McKinsey Quarterly, July 27, 2021). Overview of the Rendanheyi Model  (Institute for Competitiveness, India). How Bayer's Dynamic Shared Ownership Just Might Be A Flat Army  (Forbes). Dynamic Shared Ownership (DSO) Webinar – Bayer  (YouTube). Bayer aims to sustainably improve performance with new organization  (Bayer’s official website). Bayer's Radical Move to Dynamic Shared Ownership  (Liberty Mind, Medium article). Reinventing big pharma: Bayer's shift towards Dynamic Shared Ownership  (Medium). Ep.53 Dynamic Shared Ownership: The Future of Leadership. Guest Lars Bruening – DSO Catalyst at Bayer Pharmaceuticals  (Nate Leslie website). Case Study: Bayer in Action — How a Dynamic Shared Ownership Model is Transforming the Standard of Global Operational Excellence  (Manufacturing IT/OT Summit). The Scoop Podcast: How Bayer’s New Operating Model Is Transforming the Company  (The Scoop Podcast).