ORG TOPOLOGIES 

Company context Flo Health is on a mission to build a better future for female health — an area of health care that has been overlooked and underserved for too long. Founded in 2015 and now Europe's first femtech unicorn, Flo is the world's #1 women's health app, with over 380 million downloads, 78 million monthly active users, and 5 million paid subscribers globally. It is the #1 OB-GYN-recommended app for period and cycle tracking among 500 surveyed US obstetricians and gynecologists and backed by a team of 120+ doctors and medical experts. Flo supports women and people who have periods across their entire reproductive lives — from menstruation and fertility to pregnancy and perimenopause. The app combines AI-driven personalization, medically reviewed health content, cycle and ovulation tracking, and a private peer community into a single daily health companion used by 1 in 4 women in the United States every month. With over 500 people across the company and more than 350 in product and engineering alone, Flo is not a start-up navigating its first scaling challenge. The organizational complexity is real: 20+ cross-functional product teams, multiple value streams, and a product surface that spans mobile, AI, content, medical, and commercial. And yet, for a period during the company's growth, the organization struggled to ship large, cross-functional bets at the speed and with the ownership clarity the business demanded. This is a case study about why that happened — and what we did about it. The starting point: A domain-oriented structure Flo's product and engineering organization is built around two primary value streams. The first — value creation — owns the core user experience: cycle tracking, health insights, symptom logging, content, and the daily product interactions that bring 78 million users back to the app every month. The second — value capture — owns monetization and commercial performance: subscription flows, paywalls, pricing experiments, and the conversion and retention mechanics that turn engaged users into paying subscribers. Surrounding both streams is a broad supporting infrastructure: medical experts, analytics, marketing technology, product marketing, social growth, and user acquisition — functions that don't sit within either value stream but are essential to delivering meaningful outcomes. Each team within these streams has a dedicated product manager and engineering manager. Teams are domain oriented — they own their area deeply, they know their users, and they have the expertise to execute within their scope. This structure has not changed, and that's intentional. The challenge Flo faced was not that the domain structure was wrong. Domain teams are effective at owning and improving their product slice. The challenge was that Flo's most important opportunities — the bets that could meaningfully move the business — didn't fit inside a single domain. They required coordinated delivery across six, eight, and 10 teams simultaneously. And the existing structure had no answer for that. On an Org Topologies™ map, this is a classic tension within a Delivery Topology. Domain teams — Tracker, Health Monitor, Onboarding, Monetization, Chatbots — are PART-3 units: complete end-to-end within their scope and deliver partial solutions within the women's health ecosystem. Platform teams — Survey Engine, AI Platform — are CAPS-3 units: building infrastructure and capabilities that other teams depend on, with value delivered indirectly. Directing roles — product managers, designers, analysts — sit in WHOLE-1: they think at the whole-solution level but are incomplete without the teams that execute. The archetypes were in place. What was missing was a single accountable owner at the whole-solution level. Without one, cross-domain initiatives had no single accountable leader — and coordination collapsed into informal escalation. What made the structure hard Flo's biggest opportunities weren't domain sized. Perimenopause — a new health vertical targeting a chronically underserved user segment — required changes to onboarding, the home screen, the symptom checker, content, notifications, chatbots, and monetization. That's six or more teams. The challenge wasn't capability. It was coordination. When a cross-domain initiative needed to ship, someone had to drive it. But the structure didn't designate who. The result was a recurring pattern: A new initiative was identified as a priority; someone informally stepped up to lead it or was informally nominated; that person spent most of their time negotiating priorities and chasing alignment rather than driving the work forward; domain teams received competing requests from multiple stakeholders with no shared priority framework; and conflicts escalated directly to the CPO or CTO — informally, often via whoever raised their voice loudest. Planning reflected the same dysfunction. Each team prepared its backlog based on its own domain priorities. Cross-team dependencies were rarely made explicit upfront. There was no shared program timeline — each team had its own, built in isolation. Predicting a delivery date for a cross-functional initiative was nearly impossible. In practice, "done" meant "when the last team finishes their backlog." Priority conflicts were resolved informally or simply deferred until they surfaced mid-delivery, at which point the only options were escalation or a missed date. The turning point In November 2025, as Flo was preparing for our 2026 planning cycle, product and engineering leadership gathered for a working session with a clear agenda: The company's strategic ambitions had outgrown the way we organized delivery. Flo's 2026 priorities were sharpening around two directions: deepening the core product experience and expanding into new health segments. To pursue both simultaneously, the company had identified a small number of high-stakes, high-impact initiatives — what we call big bets. These weren't incremental improvements to a single domain. They were bets that required the entire organization to pull in the same direction, across every function, for an extended period. The session surfaced three conclusions that became the foundation of the new model: Flo's most important opportunities were cross-functional by definition — no single domain team could own them. Coordination through informal leadership wasn't scaling. The organization needed designated, explicit ownership. We needed a structural answer to a deceptively simple question: Who is accountable for this initiative, end-to-end, from insight to business outcome? The answer was the general manager model. Describing the framework was the easy part. What followed — aligning teams, changing behaviors, and navigating the tensions that come with any real organizational change — is still very much a work in progress. This case study is as much about that ongoing journey as it is about the design itself. The new structure: General managers and virtual teams What a GM is A general manager (GM) at Flo is a single-threaded owner of a strategic initiative — a big bet. The GM is accountable for the full life cycle: vision, strategy, delivery, go-to-market, and commercial outcomes, including revenue, average revenue per user, and lifetime value. The GM role draws on the Amazon single-threaded leadership model: one person, clearly accountable for the success of a single initiative from end to end. Critically, the GM is not a project manager, coordinator, or second product manager. They own outcomes, not outputs. They lead through influence and shared goals, not authority or direct management. In its fully realized form, the GM role is a dedicated, full-time position — a director or VP-level leader reporting directly to the CPO, focused entirely on one big bet. The scope of the role demands it. Coordinating across the product, engineering, design, marketing, medical, analytics, and commercial teams simultaneously is a full-time job. In practice, Flo's current GMs are VPs and directors of product who hold the GM role in addition to their functional responsibilities. A VP of product has a distinct job: line-managing teams, developing people, and driving a broader product agenda. Naming this tension honestly is important. The GM model is sound. The current implementation is a stepping stone toward a structure where GM is a dedicated role — not a hat worn on top of another. The core team structure Each GM leads a core team — a virtual, cross-functional group of dedicated representatives from every relevant function: product, engineering, design, marketing, medical, analytics, and commercial. These representatives are not merely consulted; they are personally committed to the initiative for its duration. Dedication is time phased — not every function is needed from day one. Representatives join when their function becomes critical to the program, and their level of commitment reflects the current phase — discovery, delivery, or go-to-market. The core team sets initiative direction, sprint goals, and cross-functional alignment. The actual execution happens in domain teams — the same engineering and product teams that have always existed in the organization. Domain team product managers (PMs) and engineering managers (EMs) manage sprint-level priorities in coordination with the relevant core team representative. This is the key design principle: the GM model is an overlay, not a replacement. Domain teams retain their structure, expertise, and line management. On the Org Topologies map, this overlay sits within the Delivery Topology, adding a WHOLE-1 coordination layer on top of the existing PART-3 and CAPS-3 archetypes without changing their fundamental structure or reporting lines. The core team provides the cross-functional ownership layer that was previously missing, but it does not merge directing and doing into a single unit. Those remain separated. The model draws on Large Scale Scrum (LeSS) principles to guide line managers' operations within this structure. In LeSS, managers are not priority setters or blockers — they are obstacle removers. Their job is to understand what's preventing their teams from being effective, resolve cross-team dependencies, and create the conditions for good work. This is what we expect from engineering and product leaders whose teams are contributing to a big bet: not to compete with the GM's direction, but to enable their teams to deliver within it. Decision rights One of the most important outcomes of introducing the GM model was making decision rights explicit. Before, the absence of a designated owner meant that anyone — any PM or EM — could walk directly to the CPO with a question, conflict, or priority request. The CPO, accessible and engaged, would often resolve things directly. This created a dynamic in which authority was effectively centralized at the top, regardless of the org chart. Area Owner Initiative vision, goals, success metrics GM — full ownership Product strategy and business prioritization GM — decides, informs CPO Monetization and commercial model GM + domain PMs, joint Product execution and feature delivery Delegated to domain PMs Cross-functional dependencies and escalation GM is the escalation owner Resource allocation GM requests; line managers and leadership decide based on program priorities The GM model changed this. Within the scope of their big bet, the GM has full decision-making authority. The CPO is kept informed, not consulted for every call. Resource allocation deserves a specific note. Domain teams report to their own line managers, not to the GM. The GM cannot unilaterally assign teams to a big bet. They make the request, and leadership decides based on company-wide priorities. We attempted a more dedicated allocation model early on, but in practice, teams carry obligations beyond any single big bet, and maintaining full dedication proved difficult. The planning process we've developed for the second half of the year — with explicit capacity rules, sprint-level visibility, and program priorities set before team-level planning begins — is our current answer to making resource allocation more predictable and less reactive. What changed in planning The GM model also forced us to rethink our half-year planning. The domain-first, team-by-team approach that had defined planning before was incompatible with a structure where strategic priorities are set at the program level first. We redesigned the planning process for the second half of the year around five steps: CPO + GM session: The CPO sets explicit priority order across big bets — not "all are important," but a ranked list that domain teams can use to resolve conflicts without escalating. GMs surface their initiative needs: which domain teams, what capacity, what sprints. Known dependencies and conflicts are flagged. Asynchronous engineering director review: Engineering directors review the initiative list within two to three days and flag anything unrealistic or incomplete — no meeting, written comments directly in the planning document. Domain team input: Domain teams provide honest capacity assessments based on their historical baselines — typically targeting ~60% for growth initiatives, with the remainder pre-allocated to tech debt, operations, and support. For each initiative assigned to their team, they confirm whether they can deliver in the requested window, at what capacity load per sprint, and with what risks. They also surface already-reserved sprints and existing commitments that the GM layer doesn't see. Conflict filtering: Before the final session, unresolved conflicts are reviewed and grouped by the head of product operations and the engineering directors. Only what genuinely requires CPO/CTO input goes forward — everything resolvable by program priority order is resolved at this stage. Final session — GMs + engineering leadership: At a decision meeting, not a data-gathering meeting, trade-offs are made, conflicts resolved, and commitments finalized. The process is supported by a shared planning document with an explicit structure: initiative owner, program priority, teams needed, sprint capacity required, dependencies, and a team response column. Focus over parallelism is a stated principle — one initiative completed fully is worth more than three running simultaneously at reduced speed. Teams decide how to sequence their work; the role of the process is to make priorities and constraints visible, not to prescribe how teams operate. What we learned: Honest tensions in the new model Engineering was often left out of discovery In the early months, GM-led initiatives operated with a sequential pattern that looked uncomfortably like a waterfall: design → UXR → content → medical review → engineering. Our own Jira data confirms this: The median pre-engineering gap across product-led epics was five to seven days, but outliers ranged from 31 to 102 days. Two epics in early 2026 had zero engineering tasks after more than five weeks of active work — design, UXR, and content handled all child issues. Pure tech epics showed no such delay, confirming that the bottleneck was in the product and design pipeline, not engineering readiness. Engineers were receiving handoffs rather than participating in cocreation. As one engineering manager put it directly, "This leads us to operate as an agency rather than a true product team." When engineering is excluded from discovery, the team loses its ability to propose technical alternatives, flag implementation risks early, or identify capability gaps that could shape the solution. Technical simplifications go unspotted. The scope of the minimum viable product goes unquestioned. The result is slower delivery and more expensive solutions. We're actively working on this: a mandatory engineering checkpoint after initial design direction but before detailed specs, and a discovery trio model — PM, design, and engineering — starting together at day zero, not in sequence. Race conditions on domain teams The GM model created a new coordination challenge: multiple big bets, each with a mandate to deliver results, competing for the same domain teams. Some domain teams found themselves requested by two or three programs simultaneously — sometimes within the same quarter. The pattern repeated across verticals. One team was fully committed to a big bet. At the same time, another program was still expected to be delivered from the same team in the same quarter, unaware of the existing commitment. Without explicit capacity visibility, GMs made plans in partial isolation. The consequences were predictable and documented: A domain team would receive an urgent, high-priority request late in the planning cycle with no room to drop existing scope. In one case, a request arrived at the end of January — weeks into the quarter — with an expectation to deliver by the middle of the second quarter. Nothing was dropped. Everything slowed down. In another case, home screen experiments from two separate big bets clashed because neither program had visibility into what the other was asking of the same team. The tension was structural: GMs had delivery mandates and OKRs, but domain teams had finite capacity that was never made visible or negotiated at the program level. Each GM was optimizing for their own big bet without visibility into what the others were asking of the same teams. This is precisely the problem the new planning process is designed to address, by creating a shared initiative radar that maps all active programs to the domain teams they require, with capacity and timelines visible before commitments are made, not after conflicts emerge. Priority conflicts at the team level Within a single big bet, the single-threaded owner model surfaced a different, but equally structural, problem: the domain team's own PM had no authority to protect their team's capacity. Multiple product managers within the same program would approach the same domain team independently — each with legitimate work, each unaware of what the others were asking. The team's PM could see the collision coming, but had no process-backed way to resolve it. Without a formal intake mechanism, every request carried implicit pressure. It came from a GM-led program, it was aligned with the company's goals, and it was important. Saying, "Not this sprint," required a conversation that shouldn't have been necessary. The result was that domain teams felt like order-takers rather than owners of their own delivery. The structural fix is clear: All requests, from a big bet to a domain team, must flow through a single, ranked priority list owned by the GM, and every domain team needs a formal intake process that gives their PM and EM the authority to sequence work. Building that discipline consistently is still a work in progress. We expected adaptive; we found something more honest When we designed the GM model, the aspiration was clear: move Flo toward a more adaptive way of organizing — where teams own outcomes end-to-end, where cross-functional collaboration is structural rather than coordinated, and where the organization self-steers rather than being steered. That is not what happened. And mapping the organization honestly — before and after the GM change — made that visible in a way that no amount of internal discussion could. Before the GM model, Flo was already operating as a Delivery Topology: PART-3 domain teams delivering partial solutions within the women's health ecosystem, CAPS-3 platform teams providing enabling capabilities, and WHOLE-1 directing roles thinking at the whole-solution level, but incomplete without the teams that execute. The organization had the right archetypes. What it lacked was a designated owner at the whole-solution level. After the GM model, Flo still operates as a Delivery Topology. What changed is that we added a WHOLE-1 coordination layer — the GM — to explicitly own cross-program priorities, set direction for the virtual team, and hand off work to domain teams in a structured way. The domain teams remain intact. The reporting lines remain unchanged — the fundamental split between directing and doing remains. It is one of the most useful things Org Topologies mapping can do: show you clearly where you are, rather than where you hoped you were going. There is a second, harder tension that the GM model has also surfaced. In the short term, teams are more focused — they know which big bet they are contributing to, and that clarity drives performance. But focus has a cost. When teams orient around program priorities, something else gets deprioritized: domain work, technical debt, and improvements that don't belong to any big bet but keep the product healthy. The teams know what they are not doing. That knowledge lives with the people closest to the work — and making it visible is the next important step. Where we are now The GM model is now operational across Flo's current big bets. The structural foundations — core teams, decision rights, weekly business reviews, monthly business reviews, and capacity rules — are in place. The early signals are encouraging: Escalations to the CPO have decreased. GMs are making decisions within their programs rather than deferring to their superiors. Ownership is more visible. It's now clear who is accountable for each strategic initiative, and that clarity has changed how teams orient around priorities. Cross-program prioritization has become more explicit. Instead of informal competition, programs are ranked, and domain teams have a framework for resolving conflicts without escalation. Team focus has measurably improved. We actively track which teams are working on which big bets, and the concentration of effort on strategic priorities is noticeably stronger than before. But here is the honest mapping. When we introduced the GM model, we hoped it would move Flo toward an Adaptive Topology — where directing, doing, and delivering merge into unified, self-steering units. That was the aspiration. The Org Topologies mapping tells a different story. As the mapping shows, Flo was already operating as a Delivery Topology — and the GM model did not change that. What it added was a WHOLE-1 coordination layer: a designated owner at the whole-solution level that had previously been missing. In Org Topologies terms, this is an improvement within Delivery Topology — making it more fit for purpose, not an elevation toward Adaptive Topology. The organization now coordinates better. It does not yet self-steer. The work is not done. But the direction is now more honest. We have made the Delivery Topology fit for purpose. The next question — whether to elevate toward Adaptive Topology — is a separate decision, with different implications and a different kind of organizational change. What the teams are telling us The three tensions described above — engineering excluded from discovery, race conditions on domain teams, and competing priorities — emerged from structured feedback collection across engineering managers and product leads. But the teams surfaced two additional patterns that deserve naming. The first is planning timing gaps. Late OKR finalization forced teams into double-planning cycles. Teams would plan on assumptions, then replan once direction was confirmed. Without a structured planning window, short-notice changes became especially disruptive. The five-step planning process we introduced for the second half of the year is a direct response to this, locking in program priorities before team-level planning begins, not after. The second is portfolio add-only bias. New high-priority items were added to the initiative list throughout the quarter, but nothing was paused or removed. "Everything is a high priority" dilutes focus and erodes the list's signaling power. When every initiative is a priority, none is. We've since introduced a one-in, one-out rule for portfolio grooming and a monthly review cadence to enforce explicit trade-offs. Together, these patterns point to the same underlying issue: The GM model created clearer ownership at the program level, but initially without the supporting mechanisms that domain teams needed to protect their capacity, sequence their work, and push back on unrealistic asks. Building those mechanisms — intake processes, capacity visibility, portfolio discipline — is the operational work that makes the structural change sustainable. Key takeaways for practitioners 1. Naming the owner is necessary but not sufficient. Introducing a GM or single-threaded owner role creates clarity of accountability. It does not automatically create the conditions for that accountability to be exercised. Decision rights, escalation paths, and planning processes must be redesigned to match the new ownership model. 2. Domain expertise and cross-functional ownership are not opposites. The temptation in transformations like this is to dissolve domain teams and rebuild around feature teams or verticals. We deliberately avoided this — and not just for organizational convenience. Every time you restructure teams, you reset the clock. Managers change, career paths shift, and teams go back to forming and storming before they can perform again. In a large organization, this cost compounds fast. By the time the new structure reaches a state of performance, the strategic context has often already changed. Flo's approach was different: Keep the domain teams intact and preserve their expertise, ways of working, and line management. Add the GM layer as an overlay. The domain teams already know how to perform. The challenge was to give them a coordination structure that enabled them to deliver cross-functional outcomes without abandoning what made them effective. You don't have to choose between domain depth and cross-functional ownership. The overlay model gives you both. 3. Planning must follow priority, not precede it. If program-level priorities are not set before team-level planning begins, teams will plan in silos. The order matters: CPO sets program priorities first; GMs surface initiative needs second; domain teams respond with capacity assessments third. 4. Capacity conflicts are a planning failure, not a team failure. When domain teams receive late, urgent, unresolvable requests, it means capacity was not made visible and negotiated at the planning stage. The fix is structural, not behavioral. 5. Engineering belongs in discovery. Sequential handoff from product and design to engineering is a symptom of a topology that hasn't fully evolved. Cross-functional cocreation from the start of discovery — not just from the start of delivery — is a marker of genuinely adaptive operating. 6. The GM role works best as a dedicated position. Asking a VP or director of product to be the single-threaded owner of a high-stakes, cross-functional program while also doing their day-to-day job is asking them to do two full-time jobs at once. It works as a starting point, and it is how Flo operates today, but the cost is real. The GM role competes with line management responsibilities, people development, and the broader product agenda. For any organization considering this model, the long-term direction is clear: GM should be a dedicated role reporting to the CPO, fully focused on a single big bet. 7. An overlay model improves your topology — it does not change it. Adding a coordination layer on top of existing domain teams — a GM, a program board, a virtual team — can significantly improve how your organization operates within its current topology. It reduces coordination waste, makes priorities explicit, and assigns a designated owner to cross-functional initiatives. These are real and valuable gains. But an overlay does not elevate your topology. If directing and doing remain separated, reporting lines stay unchanged, and domain teams remain in their existing archetypes — you are still in the same topology, just a better-functioning one. Mapping your organization honestly before and after the change will make this clear. In Flo's case, the mapping revealed that we were already operating as a Delivery Topology — PART-3 domain teams, CAPS-3 platform teams, WHOLE-1 directing roles. The GM model added a WHOLE-1 coordination layer on top. The Delivery Topology became better coordinated. It did not become Adaptive. The lesson is not that overlays are wrong. The lesson is that you should know what you are getting. If your goal is to improve coordination within your current topology, an overlay delivers that. If your goal is to move toward Adaptive Topology, you need structural change: different team compositions, different reporting lines, and the merging of directing and doing into unified units. Those are different interventions, and confusing one for the other leads to misaligned expectations on all sides. Vitali Kukharchyk is head of product operations at Flo Health, where he leads the product operations team embedded with general managers and partners with the CPO and CTO on planning, operating model design, and organizational effectiveness. He has 12+ years of experience in product operations and Agile coaching. LinkedIn: linkedin.com/in/vitali-kukharchyk

Our recent book, 10X ORG, by Alexey Krvitsky, Craig Larman, and me, is intended to be a wake-up call: Leaders should reconsider their org design to obtain the compounding performance impact of AI. While most companies are adopting AI in some form, it occurred to me that the projected mass layoffs are not happening (yet). This made me wonder: How are established organizations incorporating AI? A small research study confirmed my expectations: the trend is to add AI on top of the existing organizational design. The short-term AI challenges leaders face now are tool selection, staying in control of the growing number of emerging AI initiatives, and mushrooming shadow IT. Organizational design is not a relevant topic of discussion. Looking at how larger organizations are actually adopting AI in 2026, three dominant approaches have emerged. They differ in sophistication and ambition. But they share something important: all three, in their current form, actively support keeping the existing organizational design unchanged. Use-Case and Centre of Excellence model The most popular of adoption approach. A central team—typically sitting within an innovation or analytics function—is added to the org chart. Their task is to discover, prioritize, and govern AI initiatives (AI use cases) across the organization. Business domains execute them locally. A governance layer ensures alignment with strategic objectives. A change community acts as the connection between central AI ambition and day-to-day operational business reality. Their role is to signal opportunities for sharing learning and reduce duplication across teams and domains. This model works. It has been proven at scale across major financial institutions, logistics companies, and infrastructure organizations. It creates organizational memory, builds AI literacy without demanding restructuring, and gives AI investment a legitimate place in the budget process. From an org design perspective, the AI-CoE is a staff function bolted onto the existing organization. It serves the org. It does not change it. The structural risk lies precisely in its political elegance. By design, the CoE has no mandate to challenge existing structures—even when the use cases it discovers reveal that a handoff between two departments is unnecessary or that a coordination role exists solely to compensate for a process that AI could handle entirely. Over time, the governance board becomes a graveyard for initiatives that are technically sound but organizationally inconvenient, and the discovery pipeline fills with initiatives that will deliver performance gains limited to the scope the teams are working on. The use-case model is very popular, as it builds capability and organizational confidence without deep organizational redesign. Companies are likely to see a local efficiency and productivity boost, but AI will not provide compounding gains across the whole org as it is contained by the existing organizational limitations. Agentic AI and workflow redesign Instead of automating isolated use cases, this adoption approach consists of deploying autonomous AI agents capable of planning and executing multi-step processes end-to-end—across systems, across departments, and without continuous human input. A recent enterprise survey found that while only 8.6% (1) of companies currently have AI agents deployed in production, 85% (2) expect to customize autonomous agents for their specific workflows within two years. The pace of movement here is significant. What agentic AI actually does to an organization is more subtle than most adoption roadmaps acknowledge. It does not remove silos. It removes the friction between silos for routine work. The complexity is not resolved; it is redistributed and becomes invisible. Handoffs that previously required coordination between three departments are automated. The coordination work is handled by AI. But the three departments remain separate, with their own budgets, managers, and KPIs. The org chart remains unchanged, but the work it was designed to organize has fundamentally shifted underneath it. This creates a specific kind of organizational tension. Job content changes as employees shift from execution and coordination to judgment, exception-handling, and oversight, but job titles, reporting lines, and performance frameworks are unlikely to keep pace. Middle management layers, which primarily move information and manage handoffs between departments, find themselves structurally preserved but functionally hollowed out. The technology has redesigned the workflow. The organization that the workflow runs through remains unchanged. Over time, agentic AI makes the org design problem visible in a way that use-case approaches allow organizations to ignore. When a single AI agent does what three departments used to hand off between each other, the question is no longer abstract: why do those three departments still exist in their current form? This approach might lead to organizational redesign after all. Operating-system level AI A third approach is still rare but increasingly discussed among the most advanced adopters. Operating-system-level AI is the condition in which AI functions as the organizational infrastructure—continuously coordinating work, information, decisions, and resources across the entire enterprise. This is not a simple feature to add. It requires creating a technical environment in which the organization operates. The analogy: Just as a phone's operating system doesn't do one thing but manages everything simultaneously—memory, applications, connections, and power—invisibly and continuously in the background. OS-level AI becomes the layer that runs the organization itself. Routing work, surfacing risk, allocating resources, and connecting systems are all part of the infrastructure that simply operates. Most people dismiss this approach as unrealistic. Consistent with findings from Deloitte's 2026 State of AI in the Enterprise survey (3), the prerequisites for this level of adoption point to three organizational conditions: clean, connected data across all systems, organizational trust in AI-driven decisions, and — critically — leadership genuinely willing to redesign how the company operates, not merely add AI to existing processes. Almost no organizations have all three today. The data dependency alone is disqualifying for most organizations: in most organizations, governance has not kept pace with AI adoption, and the underlying data infrastructure required by agentic and OS-level AI exposes decades of technical debt that use-case approaches could quietly sidestep. Similar to Agentic AI, implementing OS-level AI without org redesign doesn't fail dramatically. The existing structure strangles the benefits of AI, inhibiting AI from becoming a competitive advantage. Some examples: A decision that should take seconds waits three days for a human approval chain that nobody redesigned. Data that the system needs sits behind a departmental wall that nobody dismantled. A manager overrides the AI recommendation because the AI's conclusion threatens their team's headcount. Without redesign, this model becomes just another failed use case for which the technology will take the blame. What This Means for Org Designers Drawing a new org chart takes an afternoon. The pain is in the execution. Organizations are made of people collaborating and contributing in specific roles. Once a role exists and someone performs it, it develops its own legitimacy, its dependencies, its political weight. For example: removing a coordinator role doesn't just eliminate a box on a chart—it threatens someone's identity, their reason for existing, and their status and power. This is one of the reasons why organizational systems have a powerful gravitational pull toward keeping things as they are. There is a false assumption running through AI adoption programs today: artificial intelligence can deliver high performance gains without deep organizational change. You can have the efficiency gains, the speed, and the competitive advantage of AI without touching the structure, the roles, the power dynamics, or the reporting lines that have defined how your organization has worked for decades. Senior leadership and shareholders have always wanted more than the organization could comfortably deliver. More speed, more efficiency, more results with fewer resources. The AI promise currently seems both seductive and dangerous because it appears to offer everything without any sacrifice. The gains without the pains: the performance without the restructuring. If I were a business leader, I would love to believe the claim is true. Unfortunately, things don’t work this way. Deloitte’s 2026 report (3) shows that agentic workflows are spreading faster than the governance models designed to manage them, and nearly half of executives report that turning responsible AI principles into operational processes remains an unresolved challenge. This is not a compliance problem. It is an org design problem wearing a technology hat. The organizations that will realize the most value from AI in the next three years are not necessarily those with the most sophisticated models or the best CoE teams. They are the ones willing to continuously ask the harder questions that AI keeps surfacing but organizations keep deferring: Does our current structure still reflect how value is actually created—or does it reflect how value was created before the technology changed? Org Topologies proposes to first consider the org design to make it fit for purpose and then adopt AI to get compounding performance gains at the whole company level. This approach requires first slowing down to accelerate later. Often, that’s not a senior manager’s favorite choice. AI adoptions that do not consider the org design will amplify the organizational dysfunctions over time. My fear is that AI will become so advanced that it can easily hide problems and operate smoothly even in a messy organizational design. But for how long? I predict this approach will give 10X problems instead of a 10X performance gain. Roland Flemm, Org Topologies 2026 (1) a TechRepublic article on trends in enterprise AI adoption for 2026, which referenced a survey of 120,000+ enterprise respondents conducted between March 2025 and January 2026 by Recon Analytics. https://www.techrepublic.com/article/ai-adoption-trends-enterprise/ (2) enterprise AI adoption, referencing a CIO roadmap. https://aircall.io/en-gb/blog/ai-enterprise-adoption/ (3) The State of AI in the Enterprise Deloitte's 2026 AI report tracking adoption and impact: https://www.deloitte.com/ce/en/issues/generative-ai/state-of-ai-in-enterprise.html

Introduction This study is about the replatforming of a big e-commerce legacy application to Salesforce in a retail company. The program lasted more than 3 years, involved more than 150 people. We were not using Org Topologies at that time but we re-organized the program several times and applied elevating katas moving the organization of the program increasingly toward adaptive topology. Below the description of the 3 stages the program went through with each time the mapping, the assessment and the next steps toward the new organization design. To note that for confidentiality purpose, it does not reflect the exact organization put in place but it is very similar. First stage The first "stage" goal was to build the core model of the new e-commerce application that would then be rolled out to approximately 30 countries. It was a replatforming program, therefore the main assumption was that functionally few things should be changed. The main idea behind this the organization design was to optimize the efficiency and reduce lead time toward completion of the replatforming as the respect of the budget allocated was one of the main focus. There were 3 main technologies involved in the migration: the Front end side of the web application, the back-end side and also the integration layer where all the API rest calls were transiting. Organization Mapping Below the list of the teams. None of the teams were able to deliver alone value. To deliver value, most of the time development on all 3 stacks is required. The approach was to have "factories" to build as fast as possible components that were integrated later by a release management team in charge of making sure that all the components are well integrated. Content: This development team was responsible for part of the back-end related to content display, similar to a Backend-for-Frontend approach. Order: This team handled the back-end business logic for order management, including shipping and billing details, as well as confirming product availability through integration with an external warehouse application. Payment: This team managed payment processing, supporting multiple payment methods (credit card, PayPal, Apple Pay). They were also responsible for fraud detection and blocking suspicious transactions when necessary. Integration Factory: This team was responsible for implementing and managing all API layers. All front-end to back-end calls were routed through this layer, ensuring enhanced security, better control of the overall architecture, and enabling integration with external systems beyond the core back-end. Front-End: This team developed and maintained all JavaScript/HTML components running in the web browser. Release Management: This team did not perform development but was responsible for consolidating code tags, packaging releases, and deploying them across environments. Dependency management was a key focus to ensure application stability post-deployment. They were also providing guidelines to development team on how to merge and deploy. Architecture: This team designed the overall solution based on business requirements. While not involved in development, they produced high-level designs and integration diagrams to guide the development teams. Below the mapping of the organization design on the Org Topologies map. The Architecture team was in charge and providing architecture for the full solution, therefore it was related to Directing archetype. For Release management team, it oversaw coordinating the releases, with other development teams, and providing guidelines. It was related to Directing archetype though having less complete view of the solution as compared to the Architecture team. For the other development teams, all were accountable for developing some tasks or capabilities but usually they did not have all the skills to deliver the full value. We can see that the placement of the teams above reflects the configuration of a "Resource Topology" where Architecture team define the solution and other component teams deliver parts of the solution that need to be combined. Below a table explaining in more systematic way the positioning on the quadrant for each team: Assessment After running with this organization a while, many quality issues were raised, above the level of what would be expected for this kind of program. One of the main reasons for the quality issues was determined to be communication between the different component teams. It was decided to adjust the model. Second stage Organization Mapping To improve communication between teams and enable them to be fully autonomous in delivering value, we reorganized the teams to be more cross-functional, meaning each team has all the skills needed to deliver value. Basically, the Front-End team and the integration factory teams were disbanded and integrated to back-end teams that were already more feature oriented. So, Front end team people were added to Content, Order and payment teams. Integration team people were added to Content, Order and Payment teams. As below, how the new organization design looked like. As we can see, now each team, similar to what is called in LeSS feature teams, were able to deliver their tasks or capabilities from end to end. The scope of skills mandate had been increased. For the scope of work mandate, things remained roughly the same with still the architecture team deciding on what the solution should be and the teams delivering parts of it. This organization aligns with the Delivery Topology. Below a table explaining in more systematic way the positioning on the quadrant for each team: Assessment This structure enabled a steadier delivery with less quality issues and the global feedback around it was positive: less issues of quality and of integration. One downside was the feeling of some team members to be less sharing practices with the people of their own technology stack. We initiated some "Community of practices" with Front-end people sharing together, Integration people sharing together and Back-end people sharing together to make up for this. To note that the idea of having truly full-stack people in the new feature team was mentioned but peoples were more interested in developing their expertise in one domain and it was not the priority of the management to investigate further this option. With this topology, it was possible to finalize the core model of the solution to be rolled out on all the countries. Third stage Organization mapping Now that the core model was finalized, it was time to roll it out to all the countries of the retail company. Rolling out the core model in a country is done in two main phases: First, the solution for the country needs to be designed, adapted, tested, and validated by the country. Then, the solution is deployed, with a clear cut-over date, and post-deployment issues are handled. First phase During the first phase, the core model needed to be adapted to each country’s specificities. For example, some countries had specific tax rules or payment methods. These specificities were first identified, then addressed either by: configuration (no code changes), or development of specific modules After this initial design step, the team configured or developed the solution and tested it through regular interactions with business owners and country representatives until validation. Second phase During the second phase (Hypercare), the solution was deployed to production. Post-deployment issues were handled and prioritized based on criticality, with the most critical issues being fixed and deployed within hours. Team organization Each country is dependent of a geographic area and we had 3 of them: Asia Americas EMEA (Europe, Middle East and Africa) For each area: A business owner consolidated and prioritized requirements A development team was assigned Each development team included: Scrum master Architect Business analysts Front-end, integration, back-end developers Testers Compared to Stage 2, teams remained cross-functional and complete, with all the skills required to deliver value end-to-end. Business owners and country representatives were not embedded in the teams but were closely collaborating during solution design and validation. Architects were partially decentralized (aligned per region), but a central architecture group still ensured overall consistency. A release management team also remained in place due to ongoing integration challenges. Mandate analysis As in Stage 2, geographical teams had all the required skills to: design adaptations implement changes deploy and stabilize the solution This confirms that teams were complete in terms of skills. The Scope of Work Mandate evolved compared to Stage 2 but remained at output level. Teams were able to: collaborate with business owners participate in solution decisions at the country level adapt the solution to local needs However, they did not own product evolution, due to: Strategic decisions about new capabilities and user journeys were made by: business owners central architecture These new capabilities were implemented by separate feature teams outside of the rollout Therefore the geographical teams were not in a position to decide what value should be created at product level. Architecture was partially decentralized but still retained a central coordinating role. This means: Teams had some autonomy to adapt solutions But within architectural constraints defined centrally The release management team what still required as there were still: persistent coordination needs across teams incomplete integration autonomy In parallel, the feature teams from stage 2 remained for the standard application development and maintenance. They were not part of the roll out but now those teams were implementing new features and fixing issues with the core model. In the above diagram, they appeared in orange. As it was outside of the program, I will not describe them but finally after the rollout was complete, those teams would be the nucleus of a new organization to support the website. Below a table explaining in more systematic way the positioning on the quadrant for each team: The organization at this stage remains a Delivery Topology, but at a higher level of maturity than Stage 2. This is characterized by: complete, cross-functional teams end-to-end delivery ownership (including deployment and hypercare) strong collaboration with business stakeholders partial decentralization of decision-making However, it does not reach Adaptive Topology as the Scope of Work Mandate remained at output level. Assessment Good feedback came from this organization and country representatives were quite satisfied as the teams were able to deliver the promises and actively collaborate to take decisions on the product when the solution needed to be adapted. Also, the quality of the deployment was good. Though the first countries to be deployed involved several major issues, the number of issues after deployment gradually decreased after each new deployment to production, and the solution proved to be quite stable without major user disruptions at the end. The website revenue was continuing to grow steadily, and, in addition, the performance was improved with a reduction in errors and an increase in successful requests to the website. As explained before, the organization was not adaptive as the Scope of Work Mandate remained at output level for development teams. Central Architecture teams and Business Owners had the control over the work mandate, however not the skill set to deliver value. Central Architecture and Business Owners were making strategic decisions regarding how to evolve the solution to answer new market needs, but those capabilities or new user journeys were implemented inside the feature teams from Stage 2 that were outside of the program. Below the limiting factors preventing the organization from evolving toward an Adaptive Topology: The separation between defining value and delivering value remained, with Business Owners and Architects holding Directing intelligence, while development teams focused on execution. The Scope of Work Mandate of the geographical teams remained at output level, even if they were able to influence local adaptations. The fragmentation of product evolution, where new capabilities were implemented outside the rollout teams, prevented full ownership of outcomes within a single unit. The continued presence of a release management team as the integration and coordination were not fully internalized within the teams. The central architectural governance, although partially decentralized, still constrained full decision autonomy at team level. As a result, the organization achieved strong delivery performance and improved quality, but within a Delivery Topology, without reaching full outcome ownership and adaptiveness. Conclusion This descriptive study shows how a program organization was first designed as a Resource Topology with the idea of efficiency in mind, but then evolved toward a Delivery Topology to address quality issues caused by communication complexity. Finally, the teams were reorganized into more country-aligned units, enabling them to better handle the variability of customer needs and collaborate more closely with business stakeholders. This evolution led to good delivery performance, allowing the organization to achieve higher quality, better stability, and stronger alignment with business expectations. However, the organization remained within a Delivery Topology, as the Scope of Work Mandate for development teams stayed at output level, while product direction and strategic decisions continued to be owned by central Architecture and Business Owners. This separation between defining and delivering value limited the ability to achieve full outcome ownership within the teams. Looking forward, two key questions remain. First, how can the organization better align the definition and delivery of value, reducing the fragmentation between central decision-making and execution teams? Second, how should the post-rollout organization be designed to sustain value delivery to e-retail customers, building on the increased completeness and autonomy developed during the program?

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

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

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

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

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

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

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

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

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