ORG TOPOLOGIES 

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

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

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

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

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

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

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

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

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

Org Topologies Pitch and References Download the latest slide deck with a high-level pitch and multiple references that can help see the field of application for Org Topologies: Org Design Drives Performance Leaders set business objectives and define strategies to achieve them, yet often lack the tools to sustainably drive organizational performance. The good news is that this can  be learned and thoughtfully applied today at organizations. Org Topologies (OT) will help you get the desired change going. How do you define and successfully lead the change that’s right for your organization? Here’s a key point: Different goals —rapid delivery, global adaptability, resource optimization, or amplified innovation—require different and tailored org designs. As a leader, you can  define that goal and use the approach offered here to evolve your organization in the chosen direction. What scope? Org Topologies works at the level of the entire organization or parts (divisions, groups, teams). You may wonder: Why another approach? And you would be right, as the market is full of canned change ‘solutions.’ OT offers a custom  path by inviting you and your people to create  your change, not consuming common yet often mediocre ideas. Why does change fail so often? First, existing solutions may seem suitable when analyzed superficially but, in fact, don’t fit your unique context. Second—an underappreciated factor behind failed change—people, when not owning  the change ideas, won’t fully accept them and won’t go the extra mile to make them work. As a result, the promised benefits of change often remain unfulfilled despite all the wasted resources and opportunities. OT helps to overcome those significant change risks by making it possible for people to visualize, discuss, understand, and finally shape the  change that’s fit for their  purpose. Strategic Org Design Org Topologies, being a strategic org design system , helps you align all the moving pieces so that your (1) business strategy, (2) organizational goals, and (3) change process work together cohesively to drive the desired organizational performance. The OT toolset equips leaders to: Visualize and map the current organization at the level of divisions, groups, teams, and individuals. Evaluate and highlight areas where the org structure supports or hinders performance. Address the critical questions: What is strategically important now versus long-term? What requires immediate focus, and what can wait? Create a shared vision of organizational change and define incremental low-risk steps towards the chosen direction. Drive systemic, transparent, and lasting change while maintaining operational momentum and flexibility. Identify where AI will best support an org goal and business objective. Leaders, powered by Org Topologies, can provide a lasting competitive advantage to their organizations by paving a systematic, well-designed path to sustainable change. Benefits of Org Topologies In general, OT helps organizations to get change going  by offering them a systemic change management method that allows to: Discover options to improve the performance of product development and service organizations. Learn to apply long-term optimizations over short-term quick fixes. Define the North Star for organizational development, ensure that it stays fit for purpose. Have the tools to assess, monitor, and progress toward a target state. Establish a shared language to communicate organizational development and engage everybody in the change. Prevent costly reorganizations, through design experiments and continuous improvements. Own the change and provide clarity on the target org design and the reasons for change. Make org design one of the critical managerial tools to gain a competitive advantage. Download the Primer for more details on how Org Topologies help drive strategic org design.

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