ORG TOPOLOGIES 

LeSS—an org design system for large-scale product development—describes Multi-Team Product Backlog Refinement as one of the key enablers of organization-wide adaptability. Multi-team PBRs are where teams learn from customers, stakeholders, and each other. This is where all the involved teams dive into the problem space to come up with innovative and effective product experiments. Forward-Looking Orgs with AI-Augmentation Today,   AI augmentation   offers a powerful and complementary capability:   accelerating deep, multi-directional learning   during PBRs without compromising the core LeSS design principle of simplicity. We can think of many AI applications that can streamline the learning process, especially in product backlog refinement events. Using my recent post on   Never Read Alone , I explained how AI can enable teams to   interrogate vast datasets , including user feedback, legal regulations, and competitor analysis, with   just-in-time learning via AI-powered dialogs   over any given corpus of knowledge. This amazing innovation must also be used during refinement. And not before or after—a critical aspect. A typical dysfunction of a PBR event is   overpreparation by product managers   and other expert roles who act as knowledge providers, turning the teams into students. Though it is essential for teams to learn, minimizing the associated process waste of knowledge transfer would be beneficial. Namely,   applying AI  right in  the PBRs   to learn and structure knowledge,   by the teams directly, can dramatically reduce the need for an expert or a special role to prepare for these meetings. We predict that this will become increasingly common now, in the age of AI. AIs (even before the hypothetical emergence of AGI) are already more   knowledgeable than any average subject-matter expert  and can easily   cross-pollinate between domains . Teams that find ways to learn from AIs will no longer need to rely on and wait for part-time human experts. Thus, streamlining the learning process makes it way   lean er than imaginable. The main criticism of LeSS-inspired org design is the high cognitive load in teams, potentially caused by the constant need to learn and switch context. AI, when applied systemically and methodically, can reduce the burden of   absorbing complexity   by providing information in a clear structure, in smaller chunks, just in time, with runnable examples, etc. These a few examples I'm bringing above are very different from how most people currently see and use AI. Somehow, the whole narrative revolves around using AI agents as free labor. Although this is probably where many innovations will be made due to obvious economic reasons, AI is not limited to doing things. AI is not (just) a doer, it is a great teacher.

How Org Topologies and Leading with Obeya Strengthen Each Other. Introduction Many organizations struggle with structural inertia—entrenched ways of working that limit adaptiveness and stifle value creation. Leadership teams often find themselves constrained to inherited organizational systems shaped by legacy decisions. As a result, decision-making is fragmented, tough problems persist, and leadership influence on outcomes remains limited. Often, organizational design is overlooked, and without a clear framework to diagnose and elevate organizational design, teams remain constrained by invisible boundaries, reinforcing misalignment between strategy and execution. Without a structured and systemic approach, leadership teams may find themselves reacting to challenges instead of proactively shaping the organization for long-term success. This is where Org Topologies™ (OT) and Leading with Obeya (LWO) come together as a powerful combination. OT helps diagnose and design the right organizational structures to enable strategy execution and value creation. LWO provides a leadership system to connect people to shared goals, monitor performance, and continually improve. Together, they ensure that organizational design changes are both well-founded and continuously reinforced within the leadership system, supporting both strategic alignment and operational execution. The integration of LWO and OT strengthens leadership effectiveness in two essential ways 1. Challenging the leadership team’s position in organizational design Many leadership teams operate within predefined boundaries, shaped by historical decisions, reporting lines, and traditional management structures. However, these boundaries rarely reflect the actual flow of value creation in the organization. As a result, leadership remains stuck with limited influence on the overall results and persistent performance issues remain unsolved. LWO starts with fundamental questions: What is the shared goal? And who do we need to achieve it?  This broadens leadership’s perspective beyond their immediate team,  inviting a broader group to align on shared purpose. OT then challenges whether the existing organizational design truly enables this goal, offering insights into root causes of misalignment and identifying structural adjustments that may be needed. Org Topologies provides a way to assess whether the leadership team is optimally positioned within the system or if its structure inadvertently reinforces these constraints. It maps out how leadership’s - and their organization’s - current placement affects value delivery, creating a deeper awareness of systemic bottlenecks, and possible ways to elevate the organizational design based on the leadership’s optimization goal. 2. Sustaining organizational design changes into the leadership system and operational execution A big challenge organizations face is ensuring that org design changes don’t remain isolated interventions. Even well-designed structural changes risk losing momentum if they are not embedded in the leadership system. This is where Leading with Obeya can play an impactful role. When changes are made to organizational design (OT suggests changes to the organizational design), LWO ensures they are integrated into leadership decision-making and remain a continuous focus. It prevents organizational design changes from being a one-time fix by embedding them into the leadership system’s regular focus, reinforcing them over time. By treating LWO as a strategic elevating kata  within OT, leadership teams develop a rhythm of assessing, reinforcing, and evolving organizational design in alignment with strategy and business goals. This ensures that structural changes are not only implemented but sustained, while adapting to evolving needs. How Org Topologies improves your leadership system Beyond optimizing organizational design, Org Topologies also helps leadership teams reflect on and improve their organizational system. It provides a structured way to assess whether leadership is positioned effectively to drive strategic goals or merely reacting to existing constraints. By visualizing different Org Topologies archetypes, leadership teams can recognize how their organizational design influences decision-making, collaboration, and the ability to drive effectively execute your strategy. This creates an opportunity to refine leadership effectiveness itself, ensuring that leaders are not just managing within a system, but actively shaping it. How Leading with Obeya helps organizations in their current organizational setup Leading with Obeya provides a way to align leadership focus, improve collaboration, and drive continuous improvement within the current system. Many organizations struggle with fragmented decision-making, misaligned priorities, and a lack of end-to-end visibility. LWO addresses these challenges by creating a shared space where leadership teams can connect their goals, strategies, and execution efforts in a structured and visual way. Instead of waiting for an organizational redesign to solve systemic issues, LWO helps leadership teams work effectively within their current setup while identifying necessary adjustments over time. By reinforcing a rhythm of structured problem-solving, learning, and adaptation, LWO enables organizations to navigate complexity, improve decision-making, and create a culture of continuous alignment and improvement, which also enable organizational design elevations. A systemic approach to leadership and organizational design Together, Org Topologies and Leading with Obeya provide a systemic approach that ensures both leadership effectiveness and organizational design work in harmony. OT offers a way to analyze structural constraints and identify opportunities to elevate organizational design. LWO provides the leadership practice to sustain and refine those shifts over time. By combining these two perspectives, organizations move beyond reactive leadership and static design, creating an environment where continuous improvement, alignment, and execution become second nature. Looking ahead In future articles, we will explore practical ways to apply this combined approach in different organizational scenarios. We will dive deeper into methods for assessing leadership positioning, overcoming common design challenges, and ensuring that leadership systems actively support organizational evolution. Learn more about Org Topologies in the primer , on the website  or in one of the classes .  Learn more about Leading with Obeya on the website  or  one of the classes .

We noticed a quote from this post by Al Shalloway : "I don’t see Agile as dead, or even dying. But it has stagnated." From the Org Topologies™ perspective, we agree: Agile has stagnated—but not due to a lack of intention. Rather, the Scope of Work Mandate  and the Scope of Skills Mandate  have remained narrowly constrained. In other words: Agile is often restricted to TASKS-level teams —where short-term iteration and local optimization dominate. And when scaled, it's frequently distorted through heavyweight frameworks , producing rigid, fragmented structures (e.g., large clusters of CAPS-1 or CAPS-2 units with PART-level coordination overhead). The Core Problem: Shallow Application, Deep Resistance We've seen many root causes blamed for this stagnation: Frameworks that don't scale well. "Agile transformations" that never reach beyond superficial restructuring. Certification mills that reduce deep change to role-based rituals. But the deeper truth? True change is hard —especially systemic change that requires rethinking the organization from WHOLE-1 or WHOLE-2  perspectives. As organizations grow, they build fortresses of local optimization . Fiefdoms. Silos. Middle layers dedicated to risk and cost minimization. These manifest as low-elevation ecosystems  composed of disconnected CAPS and TASKS units, with no shared value clarity and fractured coordination. From the Cheetah to the Map Agile once promised the agility of a cheetah—lean, fast, adaptive. But that promise requires more than rituals. It demands systemic elevation : broadening both skill scope and ownership scope across the organization. Without that, organizational entropy sets in —and agility becomes theater. To keep agility alive, we must redesign for it . The Antidote: Consolidation Through Elevation Org Topologies™ offers a visual and systemic way to do this. At the heart of elevation are two imperatives: Skill Consolidation : Achieved by forming complete teams  (CAPS-2 and above) with the skills needed for fast-flow delivery. Value Consolidation : Achieved by designing business-oriented ecosystems —like PART-2 , PART-3 , or ideally WHOLE-level ecosystems —where groups of teams co-own broad customer or stakeholder value. While DevOps and XP gave us ways to improve team-level fluency (horizontal movement), value consolidation requires upward movement . It means climbing out of the CAPS zone into PART and WHOLE ecosystems, where alignment, flow, and stakeholder-centricity can thrive. Why the Agile Team Isn’t Enough Local agile (i.e. team-level agility) is necessary, but insufficient. Elevating an organization requires: A shared backlog  owned by elevated product leadership. Cross-team coordination in cadence , not via separate, delayed handovers. Integrated value domains  that align business and tech under common goals (e.g., moving from CAPS to WHOLE). In most organizations, we see confusion when we ask: “What is your Product?” That’s the Product Gap . Low-level Product Owners manage features and tasks (CAPS-level), while true product management sits far away (at WHOLE-level). The gap leads to broken feedback loops and poor adaptability. A Way Forward: Productize in 90 Days You don’t need to boil the ocean. You need a thoughtful start. Here’s how Org Topologies™ suggests you can begin consolidating value and elevating your org: A Seven-Step Path Toward Productization: Find the Value Domain  – what whole does this system serve? Form Teams for the Domain  – multidisciplinary, elevated units. Form the Leadership Team  – elevated product leaders (not just POs). Agree on Initial and Future Structure  – current state and north star. Apply Product-Level Scrum  – not at team level, but across a team of teams. Strive for Zero Distance  – reduce the gap between makers and customers. Strive for Broad Specialization  – teams should span more, not less. This progression will move your org toward higher-elevation ecosystems , such as PART-2 or WHOLE-1, where true business agility lives. Own the Change As Org Topologies™ emphasizes, change must be owned , not rented. Frameworks won’t save you. What will? Systemic clarity, shared language, and design-fit elevation . So no, Agile isn’t dead. But it needs to grow up —from team-level improvements (TASKS and CAPS) to whole-system transformation (PART and WHOLE). Let’s stop pretending that a scaled framework can do the thinking for us. Let’s start mapping, assessing, and elevating . © 2023 Roland Flemm and Alexey Krivitsky for Org Topologies™.

Introduction For the past year, I have been working as an Agile consultant at an IT company that manages business-critical IT infrastructures for their customers. This company is a classic project organization that bases most of its organizational structure on ITIL 4 and Team Topologies. The organization has 8 customer-specific application teams and 7 generic application teams. Their main product is 24/7 managed services.   The generic and customer teams are overseen by a substantial layer of middle management (amount unclear), comprising various groups that coordinate and manage their operations. This middle management layer, in turn, reports to and is directed by the C-suite leadership to align the work with the organization’s overarching strategy and goals.   This experience report analyzes their past years Obeya transformation journey in retrospect using Org Topologies™.   The management group Working with the middle-level management group revealed that they operated as a pool of separated individuals (at the B0 and A0 levels) rather than a cohesive team or a functional group. The image on the right is a mapping of the individuals working in this management team. Their environment was characterized by an excess of meetings, frequent hand-offs, and poor collaboration, which raised critical questions: How do they ensure they are doing the right things? How do they know if they are on track? How do they measure whether they are delivering real value to the customer? Addressing these issues became a priority. The initial goal became to help the businesspeople elevate to B1, forming a unified and functional management group with a business area focus. However, simply bringing these individuals together in a room wasn’t enough. initial situation The relationship between the A0 managers and other teams (not mapped here as this document only focuses on the management group) is critical but strained, as their ability to create value heavily depends on the execution and collaboration of the operational teams. The managers, operating in isolation before intervention, relied on fragmented communication with Y1 teams to push tasks related to technological components, often through top-down directives. However, their limited scope and lack of alignment with both the customer-specific teams (CTs) and generic teams (GTs) created inefficiencies and gaps in understanding how value flows through the organization. This disconnect hindered their ability to provide meaningful strategic direction or ensure that work being executed by other teams aligned with customer and organizational goals. Elevating the A0 businesspeople to the B level, with a broader perspective, was essential to bridge these gaps and foster a more collaborative relationship across teams. To address this gap, the Elevating Kata [1]  of Obeya was introduced, enabling a broader scope of work, improving alignment, and enhancing collaboration across the group. Elevating Kata is a collection of guidelines from the Org Topologies approach. Applying Elevating Kata helps improve a chosen organizational ecosystem with its org design (departmental, group of teams) to create new desired organizational capabilities. [1]   https://www.orgtopologies.com/post/elevating-katas-structured-repeatable-routines-for-improvement     Implementing Obeya: A Journey of Transformation Obeya , derived from the Japanese term for "large room," is a method that serves as a workspace and a system for strategic alignment and collaboration. It is rooted in principles that foster inclusive and sustainable decision-making, enabling organizations to navigate complexity while pursuing long-term value creation. As an elevating kata, Obeya is a disciplined practice that integrates visual management, structured problem-solving, and systemic thinking to connect strategy with execution. It emphasizes transparency, ownership, and collaboration, creating a shared space—physical or digital—where diverse perspectives converge to solve problems, align on goals, and drive continuous improvement. By integrating principles from Lean and Agile methodologies, Obeya helps organizations adapt flexibly to change, focus on customer value, and develop resilient, high-performing teams​​.   In this organization, the Leading with Obeya  method was adopted as a structured framework to bridge strategy and execution while fostering collaboration and effective leadership. Leading with Obeya focuses on creating a shared visual workspace where all critical elements of organizational governance to strategy, performance, problem-solving, and execution are interconnected and continuously monitored. This approach ensures transparency, alignment, and timely decision-making. The methodology revolves around five key areas displayed on the Obeya walls:  Strategic Direction – A clear articulation of where the organization is headed and the necessary capabilities to achieve its goals.  Performance – Key indicators that track progress towards these goals, highlighting successes and challenges to prioritize focus areas.  Tough Problems – A designated space to identify and resolve critical issues using structured problem-solving methods, such as root cause analysis.  Plan to Value – A roadmap outlining the steps needed to create value for customers and the organization, ensuring to connect the initiatives worked on and the strategic initiatives. i.e. making sure we do the right things..  Act and Respond – An adaptive space to address emerging issues, requests, or changes, enabling swift action and policy adjustments when necessary. Initially, the introduction of the Obeya method played a pivotal role in elevating the businesspeople from A0 to B1, transforming them from isolated individuals into a cohesive and strategically aligned management group. Before the Obeya, the businesspeople functioned without a unified perspective, leading to fragmented communication, scattered priorities, and a lack of clarity about whether their actions aligned with organizational goals. By implementing the Obeya framework, these individuals were brought into a shared, visual space where strategic objectives, performance metrics, and key challenges were displayed transparently. This enabled them to develop a broader understanding of the organization’s priorities and their role in achieving them. Through structured discussions, performance dialogues, and problem-solving routines, the group began to work on collective goals and align their efforts with the organizational strategy. The Obeya also promoted collaboration and mutual accountability, helping the businesspeople transition from reactive, task-oriented behavior (A0) to a more proactive, strategic mindset (B1), where they contributed as a unified management team. However, cracks started to show after the first half year of the Obeya implementation, preventing the Obeya from realizing its promised benefits. With Obeya Pitfalls and Problems     The main pitfall encountered during the Obeya implementation was the tendency to layer the Obeya method on top of existing routines rather than using it to replace and streamline outdated processes. This approach led to overlapping efforts, where teams continued to rely on legacy systems, meetings, and reporting structures alongside the new Obeya framework. Instead of simplifying workflows and fostering alignment, this created additional complexity, increasing the burden on team members and diluting the impact of the Obeya. It became clear that without retiring redundant routines and fully integrating Obeya into the organization's way of working, the method's potential to enhance decision-making and collaboration would remain underutilized​.   Another critical problem was failing to establish a clear "Why" for the Obeya implementation, which resulted in a lack of ownership and engagement among participants. Without a compelling purpose that linked the Obeya method to the organization’s strategic goals and the team’s daily work, many individuals viewed it as just another tool or process rather than a transformative approach. This ambiguity undermined commitment, as participants struggled to see how their contributions within the Obeya aligned with broader objectives or created tangible value. As a result, the absence of a shared purpose led to inconsistent participation and limited the method’s ability to foster collaboration and drive meaningful outcomes​​.   A third challenge that amplified the lack of ownership was that the team didn’t create their own Obeya process, further distancing them from the method. By not involving the team in designing the workflows, visuals, and routines of the Obeya, the process felt imposed rather than organically developed. This missed opportunity to leverage their input and adapt the Obeya to their specific context not only reduced engagement but also reinforced the perception that it was just another external tool. As a result, the team struggled to take full ownership of the process, exacerbating the lack of alignment and accountability that stemmed from an unclear "Why"​.   The last significant difficulty was the team’s heavy reliance on senior leadership figures within the Obeya, which had far-reaching consequences when those leaders left the company. Without these key figures to anchor the process, the team experienced a drop from B1 to A1, as the absence of strong leadership caused a decline in strategic focus and ownership. Over time, this situation worsened, with the process becoming increasingly diluted and disconnected from its original purpose, ultimately regressing further to an A0 level. This shift reflected a complete erosion of the collaborative culture and shared accountability that the Obeya was intended to foster. The over-dependence on senior leaders not only highlighted vulnerabilities in the team's dynamics but also underscored the critical importance of distributing responsibility and embedding the process deeply within the team’s way of working to ensure its sustainability​​. Effect of absence of leadership Lessons Learned, Opportunities for Growth One of the key observations is that Obeya does not inherently reduce systemic organizational complexity but rather exposes it, creating a clear and visible starting point for meaningful organizational change. By exposing workflows, dependencies, challenges, and outcomes in a transparent and structured way, Obeya brings previously hidden complexities to the surface. This exposure does not simplify the organization but instead makes its intricacies more understandable and actionable. Seeing these complexities clearly enables teams and leaders to identify bottlenecks, misalignments, and inefficiencies that may have been obscured within siloed operations or legacy processes. While this can initially feel overwhelming, it also provides a powerful opportunity to address systemic issues and lay the foundation for broader organizational transformation​​.   Another key observation is the inherent fragility of organizational change, which became strikingly apparent when the Obeya process began to fall apart following the departure of key leadership figures. This fragility was a direct consequence of the team’s over-reliance on senior leaders to drive the process, compounded by a lack of ownership among team members. Without these pivotal leaders to sustain direction and accountability, the Obeya quickly lost its strategic focus, coherence, and purpose. The process, which initially held promise as a tool for alignment and empowerment, became fragmented and diluted. This underscores the delicate nature of change initiatives: without a robust foundation of shared ownership and active participation at all levels, even the most thoughtfully implemented practices can collapse under pressure. The experience revealed that organizational change is not only about introducing new methods but also about embedding resilience into those methods to withstand inevitable shifts, such as leadership transitions​​. Redesigning for the Future: From Obeya to Systemic Transformation The organization's future envisions a radical shift in management’s role, transforming it into a high-functioning product team guided by the principles of Obeya. This evolution focuses on three key pillars—productizing the company, fostering an outside-in focus, and emphasizing system optimization over local improvements. These elements, cultivated by the discipline of Obeya as an elevating kata, can potentially move the group to a solidified B1-level team, where strategic alignment, adaptability, and value creation become the norm.   The first step in elevating management is to productize the company, treating the organization’s capabilities and services as integrated products. The management team shifts its focus from reactive task allocation to delivering value as a cohesive product team. The Obeya serves as a central hub, visually connecting strategy, execution, and outcomes, ensuring all efforts are aligned toward shared objectives. As an elevating kata, Obeya instills continuous learning and improvement into this productization, enabling the team to refine their approach iteratively. Over time, this disciplined practice can embed a proactive and value-driven culture, reinforcing the team’s position at a stable B1 level.   In the improved design, decision-making is driven by an outside-in focus, centering on customer and market needs. The Obeya becomes the lens through which external data, customer feedback, and market trends are integrated into strategy and execution. This focus transforms the team’s mindset, encouraging them to evaluate success based on their ability to deliver tangible value to customers. As the team internalizes this practice through regular Obeya cycles, they elevate their strategic awareness and align more effectively with the organization’s overarching goals, further solidifying their B1 maturity.   A key component of the future design is system-wide optimization, prioritizing the health of the entire organization over localized gains. Obeya’s visual tools highlight dependencies, inefficiencies, and opportunities across the organization, enabling teams to collaborate across silos and try to make decisions that maximize current system performance. By embedding this systemic perspective into Obeya routines, the team not only solves immediate issues but also develops the capability to address root causes and long-term challenges. This approach fosters resilience and builds a culture of collective responsibility.   Through the discipline of Obeya as an elevating kata the team is more empowered to continuously refine their practices and strengthen their strategic and operational alignment as a shared responsibility. Over time, this disciplined focus has the potential to transform management into a unified, product-oriented team firmly positioned at the B1 level, driving sustainable growth and value creation.   Conclusion This vision of elevating management into a product-oriented team through Obeya is just one piece of a much larger puzzle—an ideal stepping stone toward a comprehensive organizational redesign with Org Topologies. While Obeya exposes and provides a framework to address complexity, truly solving systemic issues requires rethinking the organization’s structure, workflows, and cultural dynamics on a broader scale. By integrating this approach with larger transformative initiatives, the organization can move beyond local optimizations to create a cohesive, adaptable system designed to thrive in an ever-changing environment. In retrospect, while implementing Obeya was a valuable step, it was ultimately only a temporary solution. The reason for this is that, although Obeya serves as a powerful elevating kata, it alone is not enough to drive lasting organizational transformation. Galbraith was right, true change requires more than just a new practice; it demands that all elements of organizational design be aligned and reinforce each other. Without addressing the broader systemic factors such as structure, processes, rewards, people, and strategy, the impact of Obeya remained limited. A more comprehensive approach, combining Obeya with a redesign of these other elements, would have created a truly sustainable, systemic change. This experience showed the value of Org Topologies™ as a tool to deeply understand how an organization functions and why certain changes succeed or fail. By mapping out the interactions between different elements, Org Topologies™ provides the clarity needed to design a more resilient and adaptive organization. This journey toward systemic redesign is an ongoing effort, and I look forward to sharing more insights and strategies for addressing these larger challenges in an upcoming article. Stay tuned!

OT’s concepts have been tested and applied across diverse industries, addressing challenges from agile scaling to organizational silos. Below are several case studies illustrating the context, challenges, and outcomes. Business Banking Transformation Journey at de Volksbank Case study: Business Banking Transformation Journey at de Volksbank De Volksbank is a 200-year-old bank (~3,000 employees), undertook a sweeping agile reorganization to become more customer-centric and faster in delivering value. In 2022 the bank “flipped” to a new model with 14 cross-functional “Hubs” (each a business-value area with P&L responsibility integrating business, IT, and operations). Org Topologies was used to map and assess each phase  of this journey – from the pre-Agile setup, through a pilot, to the new structure – using OT’s visual org scans . This enabled the bank’s leaders to see structural bottlenecks and improvements  at each step. The outcome was an aligned organization design (customer-journey teams within value hubs) and clearer insight into how the transformation affected capabilities. The OT case analysis highlighted how the bank improved cross-unit alignment and identified further design adjustments needed to support its strategic goals. Case Study: Studying change at de Volksbank with Org Topologies Introduction of Org Topologies™ in European Fintech Case study: Introduction of Org Topologies™ in European Fintech In one European fintech (2022), Org Topologies was introduced as a way to diagnose the organization’s design and readiness for scaling. At the time, OT was still in a draft stage, yet the fintech’s use of it “contributed to improved awareness of needed changes to org design and [generated] ideas on how to move forward” . This case, contributed by an early adopter, showed OT’s value in surfacing hidden issues  (for example, misaligned team scopes or capability gaps) even before a formal change framework was widely available. The immediate result was a set of actionable redesign ideas and increased leadership consensus on what to change, providing a clear roadmap for the startup’s next evolution. Case Study: Introduction of Org Topologies™ in European Fintech Studying LeSS Adoption at Poster POS Inc. with Org Topologies Case Study: Studying LeSS Adoption at Poster POS Inc. with Org Topologies™ Poster POS Inc.  (Ukraine) is a cloud-based SaaS provider for restaurants and retail (HoReCa sector). Despite turmoil (industry COVID impact and war in 2022), Poster demonstrated resilience and sought to increase adaptability through a 2021 reorganization. Inspired by Large-Scale Scrum, they aimed for “global optimization with a whole-product focus”  by moving to customer-focused feature teams. Org Topologies was applied to analyze their transformation journey . Three OT scans were conducted: (1) the pre-LeSS structure (many component-oriented teams and siloed roles), (2) the initially envisioned LeSS-based design, and (3) the improved LeSS-like design actually implemented. Using OT’s archetypal maps, the company identified structural drawbacks in the initial plan  (e.g. areas where team design still caused bottlenecks) and corrected them before full implementation. The result was a more cohesive “feature team”  organization that aligned technology teams with customer-facing value streams. This contributed to Poster’s ability to restore profitability and even grow B2B clientele during adversity, validating that the new organization design increased adaptability and value delivery. Case Study: Studying LeSS Adoption at Poster POS Inc. with Org Topologies Summary Each of these cases demonstrates OT’s real-world impact in different contexts. Common themes in outcomes include greater structural clarity , alignment of organizational shape to strategic intent, and an empowered path for continuous improvement. In large enterprises (like banking), OT helped manage complexity and maintain strategic alignment during an agile overhaul. In smaller tech firms and startups, OT provided the blueprint to scale up effectively and address organizational bottlenecks early . Across the board, Org Topologies served as a diagnostic and design lens  – revealing the root causes of challenges (e.g., fragmentation, slow delivery, misaligned teams) and suggesting structural changes to resolve them. Executives in these cases gained a fact-based view of their organization’s current state and a set of concrete options for redesign , rather than blindly adopting off-the-shelf frameworks. Importantly, the OT approach is industry-agnostic , as evidenced by its application in finance, technology, and services, fulfilling its promise of being “wide open: it applies to Farms and Pharma, Software and Services”

The initial context: This story took place in a European fintech in 2022. This story is told anonymously from the perspective of an organizational consultant. The first draft version of Org Topologies™ was not yet launched when this mission started. Org Topologies™ was introduced to the company at the very end of the mission. This case study is a story about how Org Topologies™ contributed to improved awareness of needed changes to org design and ideas on how to move the change forward. This case study also illustrates what the contribution of OT was to moving the change forward. Some of the initial wishes for improvement, as expressed by the company, when the consultant was engaged: Become an even more customer-oriented org Be a leading tech-/ product organization with a focus on continuous learning and insight New ways of working, e.g. common principles and processes. As stated by the company: “The org shall be founded on empowered teams  who set clear directions for their* products based on the overarching strategic direction and vision for the org as a whole.” Changes to the org design were initially not  a mandate (*to be commented further down) In Org Topologies™, the wishes would map like this: Characteristics of the org context before the OT introduction The company was a merger of two companies. Two different B2B products. Two different contexts for providing value. Both legacy products were well-positioned in their respective markets. One product targeted at companies in need of a payment solution. The other product focused on companies in need of highly trusted user authentication. The company was strongly demanded to keep the lights on, 24/7, for their legacy services. Outages would cause severe impacts for the users. Some argued that the high-quality demands required them to keep a traditional organizational design compliant with established methodologies- and handover processes. Their good market position depended on two things: Being highly trusted for their quality and safety. Staying at the very front in their competitive market. Point 2 was causing a strong need to continuously improve the user experience without losing track of point 1. A part of the company came from a power- and rule-oriented org culture. That culture included a quite monumental project methodology.  Comprehensive processes and task handoffs between units and single-skill specialized people were dominating. Some processes were argued as unalterable due to laws and industry regulations. Other parts of the company consisted of people whose background was dominated by more agile approaches to product development. Overarching org design: High-level illustration of the company. 15 groups/ teams + sales- and admin units like HR, Marketing/PR, Legal, Internal office services, and support. Approx. 200 people in the whole company. The pre- Org Topologies™ period: The consultant built a broad in-company network including people from different units- and hierarchical levels of the organization. The outcome of this was a better understanding of the status quo. Despite this, it was a complex matter of understanding the whole product at a full-picture level. Different go-to persons could sketch parts of the full picture. Access to these go-to persons was limited due to their very tight schedules and their priority towards burning operational matters. Here is a snapshot of some of the consultant's notes from this period: Talking about organizational design is a sticky matter. Kind of a taboo for some. The high amount of product components. The company calls these components products. When they initially expressed a wish to found the company on empowered teams who set clear directions for their* products, they meant such different components. Almost every product component has a manager whose roles are named things like Product Owner, Product Manager, Technical Product Owner, Business Product Owner, etc. No common understanding of what these different role names mean in their context. Some teams include both roles such as “PO”, Project Manager and Tech lead The high degree of single specialist positions (heard: “it's not in my job-description”) Several of the teams experience blocking dependencies versus other teams. Waiting for other teams, followed by “fighting” for priority in other teams’ backlogs. UX/ UI is organized as a specific unit. Sometimes they hand over their stuff for implementation by developers within teams. (some “PO's” and other higher-in-the-hierarchy people from the teams are actively involved in using their mental faculties to understand, learn, or solve problems. And making decisions. Other “PO's” are treated more as order-takers expected to execute design, architecture and specifically described functionality by UX/UI and more senior product -roles). Separate department for testers (Y1 group) Separate operations department (acting as Y0 individuals) Three teams are quite empowered with broad skill sets within the team. Two of them are given responsibility for value stream parts of the product. (A2). One of them has a complete skillset to create the whole feature by the people within the team (A2) One team calls them a Scrum team, though the people within the team are directed by a project manager titled as Scrum Master. Single-task-single-person orientation within the group. Lacking a common goal for the sprints. (Y1) The largest team (The new app team, 15+ persons) includes some people who are very inspired by the approaches suggested in the book named Empowered  and other things they call “the product literature”. Others in this team are inspired by Scrum and some practices articulated as agile. Seems to be an ongoing conflict based on arguments that redefine the Scrum definition. Several of the people in the New app team  feel like order takers of tasks given to them. (Y2) One of the team members reached out to me to share concerns about lack of structure, motivation, and sometimes chaotic scenarios where important stuff falls through the cracks. Hard to establish a company-wide common language. A significant amount of people have strong opinions of what agile is - or not is. Some perceive the ingredients of agile as binary things - i.e. either autonomous or not. The original content and intentions articulated as agile often have been redefined or diminished. Some developers have really bad connotations of the word agile. One of the developers said: “those agile people who came up with the idea of estimations should personally go say sorry to all the developers in the world. The estimations demanded in agile methods have caused so much pain and hurt people badly”. (Diving deeper throughout that conversation, it turned out this person had been exposed to people who used practices associated with agile but done in ways causing scapegoating and time-consuming no-value overhead.) Why the consultant introduced Org Topologies™ to the company: The consultant shared his list of observations with his mentor when they met in October 2022. He also shared how he felt a need to help the company see the characteristics of different parts of the org with an objective, non-judgemental, and agnostic approach. The mentor pointed him to a very early draft version of Org Topologies™. He found the following potentially useful:  structured way to articulate , and help the company see, the different levels of team autonomy in terms of completeness of skills within the team. (At that time, there was an ongoing discussion about team autonomy.  Binary, - like yes or no) Help the company become aware  of how its org design is dominated by component thinking rather than the whole product. A more neutral language  to avoid words like i.e: agile, waterfall, lean, scrum, empowered teams, and product thinking. (These words had turned out to be disturbing for constructive reflections about org design.) A way to help people connect better to a  common direction  for transformational efforts.  As Org Topologies™ emphasized adaptiveness as optimizing goal, it fitted another important learning during this mission: After a 1:1 chat with the CEO, the consultant noted: “I connected the word agile with the organization’s ability to respond to changes. We reflected together on how affected the company actually is by frequent changes in everything from laws and regulations to customer needs, competitors' offerings, new tech, dying tech, etc, etc. With high enthusiasm, the CEO stated that: “It's not enough that the employees accept  that we need to respond to changes frequently. They really need to EMBRACE  CHANGES !” The consultant understood Org Topologies™ as a tool supporting the communication of this. The introduction of Org Topologies™ to the company: The consultant shared the information on Org Topologies™ with some people in the leader group and his network within the company. At this time the materials consisted of the OT website, a download, and a recording from a conference. The consultant felt that Org Topologies™ made it easier to communicate and help them own the following awareness:  The company's initial perspective that each of the teams owned their  product was replaced by a slightly increasing whole-product (whole business) perspective. With the more holistic product perspective, it also became clear that product prioritizations needed to be done at a more holistic level. They concluded that a person placed at leadership level 2 in the org in reality was acting as the product owner. They started reflections on how to optimize their organizational design towards an ideal where they were in a better position to embrace changes. Key stakeholders started talking to each other in new ways: I.e “That department is obviously a Y0 / Y1”, “I don't think the C3 level is realistic, but maybe we can reorg team X, Y, Z and start optimise them more in the direction of B2/ B3”. The org scan based on their status quo, Nov 2022: (This org scan is done in retrospect almost a year after the verbal assessment done in Nov 2022. Might not be accurate, but made to illustrate the essence) Using Org Topologies™ for a brief assessment one year later As mentioned, the introduction of Org Topologies™ happened at the very end of the consultancy mission. If the timeline was stopped there, the consultant's experience report would be that it felt helpful for communication and awareness. October 2023: A brief assessment was done with two of the transformational enthusiasts in the company. Some of the highlights as perceived by those: 1. Overall, more talk about the holistic product perspective. “I feel that we have lifted the perspective. We used to have long discussions concerning the task-level. Not so much of that any more”. 2. The New app team  used to be a hotspot. The other teams used to have a lot of dependencies on what happened there. This has changed now. Their org design has changed. They are now divided into smaller collaborating teams and the dependencies are reduced significantly. Teams coordinate more directly with each other. 3. The Forgotten PW team  has moved vertically towards a more product-part focus. ( Now named onboarding and issuance )This includes a more holistic customer-centric perspective. The PO now influences the org to apply organizational development as a tool to get more value. He knows where he is going.  The team had also heightened their focus on necessary multi-learning while ascending on the Y-axis. The vertical indicators were reflected in an expansion of the team's scope of work, and there was a deepening of their overall product understanding. The team had been proficient at engaging with customers. Subsequently, they reduced the distance to an even broader segment of the customer base. Observable growth indicators in this team: The red arrow illustrates that the team reduced the distance to customers by having more direct dialogue with them.  The team's focus moved toward a more holistic part of the product (onboarding and self-service admin where reset PW is just one of the features). As the team fixed the burning matters that were the reason for establishing a "forgotten PW team" the focus- and the team's scope of work matured in a more holistic direction. The same people stayed in the team and they learned new skills, increasingly building a broader product understanding.   The "forgotten PW" feature was still a part of their responsibility, but no longer their only focus. The green arrows illustrate that the org involved them, and shared more of the holistic customer domain. The team's scope of work increased to a more holistic perspective. The people in the team were motivated by this. The team members in this team are forward thinkers and feel that they can provide more value for the company by having a more holistic perspective on what they are creating. 4. The Biometrical R&D team  has increased their multi-learning capability even more by exploration of the whole product. They are moving towards a broader understanding of the core, serving as an engine for the whole product. They have started to simplify by building elements from the core component in ways that reduce the dependency on that component team. Increasingly becoming more capable of solving whole product needs. Observable growth indicators in this team: The red arrow illustrates that the team reduced the amount of blocking cross-team dependencies by learning more about the functionality that a legacy platform team owns. This team can now go faster and doesn`t need to wait anymore. The reason is that they have learned how to create a broader scope of functionality in their own code-base. Done by multi-learning. The team identified highly frequent reciprocal dependencies and developed their skills to deal with those within the team. Leaving the team with only some pooled dependencies. The functionality is replaced in the code base accessible by this team, and they can not go faster without waiting out the more rigid processes as they did. The green arrows illustrate that the team has grown more complete in regard to their skills. The focus on multi-learning moved them from A2 to A3. Though they are still not B they are more "B-ready”. This team could probably be a catalyst for a change towards B for all the teams involved in this product part.  Conclusion The introduction of Org Topologies™ helped communicate and reason about the status quo. It supported the consultant’s efforts to create awareness of blockers/ delays caused by the narrow scope of work in several of the company's organizational building blocks.  There are some signs indicating that this awareness led to, or at least contributed to, changes in organizational design optimizing for better flow and increased adaptiveness in product development. In Org Topologies™ terms; contributions to reduced transaction costs and switching costs. This experience report presents a personal view on the change story by the credited writer. Should you have alternative views or additional details about this particular company's change story, please do not hesitate to contact Org Topologies and submit your version for publishing. Elevating Katas (addition of December 2024 by Alexey Krivitsky): This article by Steinar 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 (Deep Improvements Only): Adopting a Whole-Product Perspective Repeatedly mapping and reevaluating team scopes from isolated components toward broader product domains. Over time, this sustained focus on holistic ownership helps teams better understand end-to-end customer needs, reducing fragmentation and dependency. Expanding Multi-Learning Within Teams Encouraging team members to continuously broaden their skill sets and product understanding. Repeatedly filling skill gaps and addressing recurring dependencies shifts teams from narrow specialization to more complete, customer-focused capabilities. Systematically Reducing External Dependencies Incrementally incorporating previously external tasks (e.g., operations or platform integrations) into team skill sets. This ongoing practice consistently lowers lead times, enhances responsiveness, and fosters more adaptive, continuous value delivery. Iterative Organizational Redesign with Holistic Prioritization Regularly realigning responsibilities and boundaries based on evolving product goals. By repeatedly refining structures to align with strategic objectives, teams achieve faster, more streamlined delivery and better organizational coherence. Establishing Regular, Objective-Based Assessments Incorporating neutral frameworks like Org Topologies in a repeated cycle of diagnosis and action. Each assessment informs targeted improvements, ensuring the organization continuously evolves toward higher adaptability and flow efficiency. Increasing Direct Customer Interaction Embedding routines where teams regularly engage with customers or user feedback. Over time, these habitual feedback loops guide more precise product choices, strengthen customer alignment, and improve the speed and relevance of delivered solutions. More on Elevating Katas here .

Org Topologies ™ : A brilliant frame to clash "expectations" with "conditioning" and to let them explode. Let me explain. Once upon a time... There was a Y0 group in the realm of HR. A land where decision power lies beyond their domain. Their courageous manager believed that the team could thrive and perform better. She acknowledged internal and external limitations, just enough to believe "the team" to be of A1 nature, when given time to map them onto the Org Topologies ™ . When it comes to expectations towards them, she naturally assumed they would act as if they were A2 . Desired collaboration, knowledge exchange, and approaching challenges together as if those were features. She wanted "the team" to generate brilliant ideas as a result of working together as a group. Her and the company's aspiration was to elevate "the team" to B3 status. To gain full empowerment in shaping the recruitment process and campaigns in the company. To take the lead in strategic talent pool planning. To shape actions of today that would become the company's reality tomorrow. In the meantime… All the measurements were aimed at Y0. All KPIs were focused on throughput, and all tasks required a single skilled individual to perform them. These tasks were designed for execution, not for collaborative problem-solving, and there was no room or desire to change that. Communication was directed at Y0. Expectations were set for individuals. Messages were channeled to individuals. Tasks were divided for individuals to execute, with no room or appetite for change. The career path was aimed at Y0. Annual paths, goals, and assessments were centered on personal objectives. The one-on-ones, the reviews, and ultimately, the grades were built solely around individual performance. Collaboration was discouraged. Techniques like swarming or pairing were branded as wasteful in the pursuit of achieving KPIs. Customer collaboration and knowledge transfer were limited to a minimum to allow more time for individual work to meet quotas. Following the plan was paramount, while prototyping, experimenting, and the pursuit of innovation were acceptable only if they could yield immediate benefits. Therefore… The team remained at Y0 as conditioned . They were a group of skilled professionals sitting in a shared workspace. Competencies and work areas were cleanly separated. With few occasional meetings, they quickly returned to their tasks. The team focused on a consistent flow of individual tasks, optimized for high proficiency and low collaboration, much like a well-oiled engine. The problem didn't lie with the team but with the manager and company expectations. Let's venture into the woods… All the conditions that surrounded these professionals led them to believe they should act as Y0, like solitary bobcats hunting alone. They had been hired this way, measured this way, communicated to this way, provided with a corporate development path shaped this way, and delivery techniques-wise incentivized to behave this way every single day. Expecting this group to transform into a pride of lions or a wolf pack, into an A2 or even into a B3 type of team, simply by stating it as a managerial expectation, without introducing any changes to the Organizational Structure, was irrational. It was as effective as having a face-to-face coaching session with a hungry grizzly bear about the benefits of becoming a vegan—it just wasn't going to happen. Clashing expectations with conditioning… Org Topologies ™ provides a brilliant framework to set the stage for such discussions. Engaging organizations in journey like the one described above: Acknowledging that the team is currently a Y0 Recognizing that the manager actually perceives them as A2 Understanding what the board's aspiration to elevate them to B3 really means Recognizing that the upstream dynamics, KPIs, career paths, and practices that promote Y0 Observing the confusion when all the above come together Initiating a rewarding coaching quest to bridge the disparity, unlock human potential, and enable individuals to excel.

The Engineering Manager’s job includes helping their team become more effective at solving problems, and collaborating with other teams and departments to achieve results that their own team cannot achieve alone. EMs work to improve software development processes, encourage collaboration within the team and with the team’s stakeholders. They help the team to structure their work. A complex software system is made from many components, and most development requires changes across several components. Which teams get to work on which components? The answer to this question has a large and often unacknowledged impact on how Engineering Managers spend their time. The more components a team can work on, the less time an EM spends on negotiating with other EMs. But, the tighter a team’s focus, the more inter-team coordination is necessary. John Cutler calls this invisible work A huge source of "invisible work" in companies is managers having to essentially manage sideways to sort out dependencies, etc. It is basically asking managers to be the human load balancers of the org instead of focusing on their teams, and connecting with customers. Marcus, a good friend of mine, is an Engineering Manager at a Big Tech company in the US. During our regular video chat, I introduced him to Org Topologies ™, and learned something about the work of EMs in Big Tech. Org Topologies is a diagnostic showing what kind of organisational dynamics your team structure is generating. Also, how changing team structures in specific ways can bring about changed dynamics. Hi Steve! Hey Marcus! So one of my consulting clients has a complicated development process, with lots of meetings and tickets. Their managers and architects are super busy just keeping things connected up. The company’s senior management feels that product progress is slow, and they’re right. We’ve both seen that before. The first step is acknowledging you have a problem. Right. I’m showing them how to use the Org Topologies chart as a navigation aid: First figuring out what kind of team structure they have, and what kind of problems and benefits come with that. Then, where on the chart they’d like to end up. Finally, what it’s going to look like getting there. Sounds too easy… There’s a lot of nuance to the tool, and a bunch of work to actually make the changes. That’s one of the reasons we’re charting it out — so that we can work one step at a time, and take everyone on the journey together. Okay, I’m interested… tell me how it works. The map shows an organisation through the lens of what kinds of results an individual team can achieve on their own. Within a team, while there are norms and conventions, there doesn’t need to be so much formal process. The longer a team has worked together, the less formality is needed. But between teams, we need coordinating roles or project management systems. Scope of work The vertical axis is called Scope of Work. What kind of a goal can a team take on? The rows are labeled Y A B C. Let’s start on the cherry blossom row “Feature focus”. Cherry blossom ? How poetic! Oh wait… you mean the red row Row A . Teams are asked to make product features, where a feature is some new or changed functionality that the system should provide. Work on a feature is usually focused on a single system component, maybe with dependencies on other components. It’s common to see several A teams, each owning a system component. Work is assigned to teams based on what component is involved in the work, and there are project management systems to track dependencies. The one component to one team model is popular, maybe because when a team is solely responsible for something it’s easy to hold them accountable[1] for that thing. But it means that a team can only change their own component; for anything else, they need to make arrangements with another team. That sounds like my team There’s also task-focused work ( row Y ), where individuals or teams are given narrowly-focused and often technical work to do. You see this sometimes when a team seems to work together, but each team member is working on a different near-term goal. In this case, it’s wrong to call them a team, as there is no shared objective they’re working on together. It’s like a football team, but where each team member is playing a different match. So, we call these units instead. No, we don’t do that. We actually have shared goals every two weeks and everyone on the team contributes Row B product part focus is where a team is asked to provide a customer outcome or business need. They can work across many components as necessary to create the desired outcome, even while other teams are doing the same for other customer needs. Teams collaborate with other teams as needed, without needing to assign work to dependent teams, and without external project management. The top row C, whole product focus, is the same. Each team can work across any part of the system that is needed to get something done. The difference between B and C is in how much of the system, and how much of the business domain of the system, teams are responsible for. At B, a team works on parts of the business domain and parts of the system. At C, a team can be effective across everything, because they are supported and equipped to learn as they go. If a component is owned by several teams, how does that work? Shared ownership could lead to chaos Sure, if there’s an “anything goes” approach, it’ll be chaotic. Code quality, tech debt, and all that stuff. Fortunately, there are several ways to share ownership in more structured ways. A team can have a stewardship or guardianship responsibility for a particular component, and when another team wants to make changes, the guardian team helps them with the change design, and reviews the changes. So, there can be lighter-touch involvement between teams than “add it to their backlog and wait”. That’s how it works here. You “file tickets against other teams” when you need something changed in a component owned by another team File tickets against sounds like getting parking fines It does. Actually, it often feels like a kind of punishment, because the team receiving the tickets now has more work to do that they hadn’t planned for. That’s how we normally work. But sometimes, if you know the other manager well, and there is trust, there’s an opportunity to work in a more shared way. There are other teams that you share components with sometimes? Not usually — we have this B-ish collaboration sometimes, but it requires Engineering Managers to put time and energy into enabling it. After the feature is done, things fall back into the usual pattern on the A row. Getting work done despite the organisational structure. That’s a good way to put it. A lot of an EM’s job is helping things to work well despite the organisational structure So, that can happen, but it takes extra efforts to make it work, and it’s not sustainable without continuing to apply the effort. Wouldn’t it be nice if the organisational structure supported the requisite work, instead? (Marcus offers a knowing smile) Changing structure is difficult; it affects career ladders and how people are seen within the organisation, and lots of other things. Is there anyone who has a broader remit than one or two components? Sure, some senior managers have a broader B-row kind of scope. But they’re also rather disconnected from what the teams are actually doing. There’s also SVP and VP level executives whose actions make it harder or easier to “work despite the structure”. Often because their actions impact how much trust there is between team-level engineering managers. Okay, high levels of trust is needed for work despite the structure ? It’s the most important thing. I get the rows now; tell me about the columns. Completeness of skills The columns are about completeness of skills . They’re labeled 0 1 2 3. My guess is your team is a multi-skill unit Do we have to be a “unit” ? I’d prefer to be called a Team You were in the Feature Focus row A, so it’s quite likely you are a team. We still call the column “unit” because when there’s a narrow task-focus (row Y) there’s usually not a shared goal, limited amounts of interdependency. So while there’s people doing work, there’s not a lot of team work. Ad hoc collaboration is possible within a unit. But the structure of the organisation determines how coordination between units happens. So, people in the same unit can work together with little overhead; but when multiple units are involved, we typically see some level of bureaucracy. Got it. We do have multiple skills: development, test, design, deployment. There are two things[2] that regulate whether a team can do some work without needing to be blocked by others outside the team. Can they work on the component areas of the product as required? Does the team have the requisite skills? This second point is about all the skills needed to take a feature from the point where we recognise that it’s something we want to do, all the way through to shipping the feature to users. That probably includes design, test, coding, integration, deployment, release. Are the requisite skills known on the team? And if they are, are they allowed to use them; or do they need to hand off to another department for some kind of security test, or deployment? No, we’re good. In most cases we can release all the way. A single-skill individual, column 0, would be like a Database Administrator who deals with the Oracle database. I worked in a company once where there was one DBA (Microsoft SQL Server this time), and he was the only one allowed to edit stored procedures and do certain deeper database stuff. To get him to do something, you would send him an email, and a bit later he’d do it and mail you the results. He was in the same office most of the time. Okay, let me guess… Y0 for the task-oriented DBA Exactly, Y0 single skill individual. Now imagine there’s a whole department of DBAs, managed by a senior DBA. Across the whole department they know different databases. A few can do deep performance tuning; others specialise in 5th and 6th Normal Form. Y1, functional unit Almost right. Column 1 for “functional unit”. But we don’t know about the Y — if they’re task-focused. From the description it sounds likely, if the database is one of several system components. But if the product is in fact a database, and their customers / users interact with it directly (maybe using a B.I. tool like Looker or Tableau), they might be at A1, B1 or C1. So it depends on what the product is: what are customers paying for, and users expecting to use? Multi-learning teams Got it. So right-hand column: what’s a Multi-Learning Unit? A team that has support to learn new skills of different kinds (domain knowledge, technical knowledge), and learning perhaps being more like figuring out proofs-of-concept together, rather than being sent by a manager on a 3 day training course then being expected to have a new skill. Teams that learn by doing and collaborating; rather than having to add people to the team to bring in new skills. Going further, groups of teams that choose when to take the most direct line to delivering a feature, and when to take the “scenic route”, slowing down in order to acquire new skills and knowledge. Optimising capability and learning across the entire group. Developing ways of predicting what skills and knowledge will be needed in the mid-term future, so by the time they’re needed the teams are prepared. If our tech stack is stable, and our business isn’t changing, is there much benefit to being multi-learning? Maybe not! But over the course of months and years, technology changes whether we want it to or not. Whether it’s software versions, new internet protocols (e.g. HTTP/3), consumer hardware (new iPhone models)… And a business that doesn’t change either has a captive market, a monopoly, or owners with a lot of disposable income. If there’s a lot of employee turnover, people won’t stick around for long enough to learn and then apply those learnings. But that’s a sign of more serious problems. Okay, I think I understand how the Org Topologies chart works Teams at my company are more or less at A2, multi-skill teams with feature focus. Sometimes Engineering Managers make special efforts to get teams together and soften the unit boundaries, so we’re at a B2-ish place, working across several components. But this lasts only as long as needed to get some specific feature delivered. The organisation’s structure and politics naturally returns to A2. Is there anything EMs can do to shift the organisation out of A2, perhaps into B2? Would there be a benefit to this? We’ve shown we can work in a B2-ish way when there’s trust between the EMs and teams, and when the need is there. But to do so long-term would mean changing a lot of things — progression / incentive structures, technical practices around component ownership, company-wide project management… Engineering Managers can support such a change, but it needs to be driven by more senior roles. Starting a journey with intention, you need to know where you are. If you’re planning to go somewhere, it helps to know where you’re starting from. And even if you’re happy where you are, maybe it’s reassuring to understand more about why this is the place to stay. Learn more about Org Topologies . [1]: In many companies, hold accountable is business jargon for blame. The company’s leadership want to be able to blame specific people if something bad happens. They are reluctant to give this up, even if it means having less effective teams. Part of the reason for this is that they don’t understand what blame is, and what might be used instead. Blame is an organisational development tool, and a particularly blunt and clumsy one. Wielding it always causes unintended consequences, chronic wounds that resist healing. Giving up blame, and switching to more subtle and precise organisational development tools is an important enabler that allows companies to shift into the top-right area of Org Topologies. [2]: A third thing that enables teams to have dependencies without blocking: whether the other team is available to them without the need for a backlog. Both teams work on dependent features at the same time, and are fully available to each other to mutually adjust the features as they are developed. But this is for another conversation.

This article is a detailed analysis of James Shore 's talk at the AgeofProduct . We recommend watching the full video of the talk . We're looking at this case study from the viewpoint of Org Topologies™ to understand better the chain of transformations he is describing in this talk. The story he is sharing spans several years while he was helping a company to move away from a rigid multi-team constellation of component teams to an org design based on mainly stream-aligned teams of Team Topologies ® and later on to a more fluid FaST - ecosystem. The meta-level goal of this article is to demonstrate the power of Org Topologies™ as an approach to visualizing and communicating org design and org change ideas. Thus, this article contrasts three different organizational designs showing their significant differences. First Org Design: Component Teams In the video, James Shore first shares his definition of component teams: In the Org Topologies™ language, we are trying to avoid the black-and-white definitions like 'component teams'. That's why we have a map of 16 archetypes, with 7 of them being the most recognizable . If we map the 'component teams' as James describes them, they will be represented by the orange post-its on the map below as Y2 and Y3 archetypes. The exact classification will depend on how incomplete or complete those work units are in terms of their technical capabilities: In James' words: "Component Teams ... is the most common thing I used to see and actuallty the most common thing I still see today.... This is where each team is focused on a particular technical part of the system... A front-end team and a back-end team... The database team... Or the Ops team... People who are focused on specific technical areas. James was hired to help that organization with component teams because "the work was grinding to a halt." This is not surprising if we analyze an ecosystem of such teams: structurally, such teams cannot independently ship customer features or work on business objectives end-to-end (that's why they are mapped at the Y-level, the task focus level. They can't complete user features); they cannot see the bigger picture, simply because that is not their focus; therefore, such teams require external specialists and functional groups to provide them with detailed requirements and task breakdowns and help them coordinate and integrate their tasks into a shippable valuable piece of software. An organization that has such an organizational design will have many blocking dependencies, hand-offs, queues, coordinating roles, upfront plans, dependency boards, and integration issues to manage. Such an organization will be too busy dealing with its world of self-imposed complexity. Rather than being customer-focused, outcome-oriented, and product-centric. The mapping below depicts all the overhead archetypes that are needed to complement the Y-level archetypes for the whole system to deliver a working product (individuals and groups dealing with analysis, design, coordination, integration, operation, etc.): No surprise such organizations would want to improve, eventually. But in our experience, the required management awakening can take years. Why is it so hard to change? An org design with component teams is very sticky. First of all, the developers in component teams might not see a problem at all! They strongly focus on what they are good at (and everyone likes to have focus). They feel a strong sense of ownership (of components). All the excessive complexity such a component organization needs is handled by people external to the developers. So, the developers usually don't feel the burden. Sometimes, when you talk to the developers of component teams and ask whether they know of many cross-team dependencies, they might surprisingly respond: "No, not at all!". Component teams might not see the dependencies, as each team has its task-level backlog that someone external to the team populates and manages. They live in an illusion of independence. "We can do those tasks without any other team," they'd say. And they would be correct. But from the value flow viewpoint, a feature touching multiple components that are owned by different teams has to be broken down into separate tasks. And those separate parts of the feature sit in many different team-level backlogs. Will they be picked up by different teams simultaneously and worked on in a single cadence? Very unlikely. So there are dependencies and asynchronous work that slows down the delivery of value, but one needs to see the bigger picture to see that. This can be summarized by this famous definition of a cognitive bias described by Daniel Kahneman in his book "Thinking, Fast and Slow": What You See is All There Is (WYSIATI) says that when presented with evidence, especially those that confirm your mental model, you do not question what evidence might be missing. The dependencies are between the backlogs, not within them. But these dependencies are not what the teams are looking at... That's why component teams might linger in sweet ignorance of being 'efficient' and 'productive'. This can be illustrated with the following map overlay: See how this illusion of independence and the focus on internal concerns (better developers' focus, stronger developers' ownership) create a dysfunctional organization where rich collaboration and joint work of multiple teams becomes almost impossible. James reports that the company had 200 engineers, 300 people in the R&D, and 42 teams. And based on his value-stream mapping analysis, it had 97% of waste or wait time! So they were spending months on something that would take just 2–3 days of work. That was caused by all that waiting and asynchronous, unaligned work of the component teams. James wonderfully describes in one passage the dynamics and culture such an organization exhibits, showing how such companies "get killed by their cross-team dependencies": A team would start working on something, but they would need another team to do something, so they would hand off and then they would wait. And while waiting they would take on other work. So when another team came to them saying "we need something from you", they said "sorry, we're in the middle of something" and now that team would wait... They created what James calls "the spaghetti diagram". Each card represents a team and every line represents a blocking dependency: Second Org Design: Stream-Aligned Teams James has helped the organization of 42 component teams to move away from the spaghetti state by redefining the responsibilities and making, what he calls, "full ownership teams.", which is very similar to the "stream-aligned teams" popularized by Team Topologies: Looking at this organizational redesign through the lens of Org Topologies™, this was a move from a Y-level team setup of entangled component teams to an A-level setup with the majority of teams being able to work on customer features end-to-end. And that is a great improvement! That organizational improvement helped the company to grow and got up to about 67 teams. However, with the new design and increased number of teams, the company started running into new problems, which were mostly around product management . And this is not surprising: Every new solution will create new (better) problems. In an earlier article, we made an extensive analysis of the Team Topologies, and concluded that such a setup creates a low-level ecosystem: So the "product management" problems referred to in the story by James are caused by the fact that the stream-aligned teams are focusing mainly on what they are good at already. They build and deliver features that lie within their field of expertise. And that is not a coincidence, That’s intentional. In the language of Team Topologies: "The goal is to optimize for fast flow of change". Because of this optimizing goal, stream-aligned teams will be given work that is in their field of expertise because that is the fastest way to get that work done. They will be given some set of features in which they can develop deep expertise to be fast at shipping those changes. That's why the steam-aligned teams are mapped at the A-level, the feature focus level. Because of the relatively narrow scope of work, stream-aligned teams " did not truly own a significant portion of the final product " (a direct quote from James in the video). A rhetorical question: what happens when you have work units that are fixed to work only on given parts of the whole (components or feature sets)? You will have dependencies between the teams! But we agree such dependencies are less strong than between the pure component teams. So the new setup is an improvement compared to the previous state. According to the storyline, the new org design with stream-aligned teams was significantly better than the initial one with component teams. With the stream-aligned teams, you can focus more on external concerns such as shipping features to serve known user needs, getting fast feedback thanks to the fast flow of change, and then improving the product features. That feedback cycle is the essence of agility. Yet, James also mentions issues related to this design. One issue had to do with not having enough "specialties" such as UX, Security, and SREs (site reliability engineers) in each team. In other words, the teams were incomplete (A2 as per Org Topologies™). In this phase they had to deal with two different kinds of dependencies: product-level dependencies, due to the narrow scope of work (features) in teams specialization dependencies, due to the incompleteness of skills in teams The second issue mentioned is of greater importance. It had to do with the architects (likely a C1 archetype, as per Org Topologies™) not being able to constantly match the team structure to the changing business and architectural needs. This is substantial: the "essential agile" team archetypes, as per the illustration above, cannot sustain business-level agility. By design, such teams tend to be stuck at whatever they are already good at (they have a feature focus). Thus, they are not fluent and unresponsive when it comes to changes in the product strategy or changes in the architecture. They can't adapt quickly and easily. They are stuck to build and ship fast what they know how to build and ship (remember: the fast flow of change is the goal for stream-aligned teams). To keep the organizational design and the business strategy in sync, narrowly specializing teams (like all stream-aligned teams) need to be reorganized regularly. This is expensive and difficult. James concluded in his story that the architect group failed at that task. But our view on that is that the task of realigning the team structure to the strategy is too complex to be performed by anyone regularly. And the scale they had (40+ teams) was also not making it less of a challenge. So the next step the company was heading toward was to craft an organizational design that would enable true (business-centric) agility. This should be a design where the structure is in constant re-alignment to the business needs. A fluid structure. Third Org Design: Towards True Agility with FaST James got excited about the FaST . He learned it from Quinton (Ron) Quartel and Paige Watson around 2019. FaST stands for Fluid Scaling Technology, and is about combining open space technology (a tool for self-organization) with a frequent opportunity to change team compositions. The reason FaST appealed so much to James, in his own words: What we were doing in the Team Topologies approach is that we were scaling horizontally . We're adding people by adding new teams... That requires careful design... Ultimately we're talking about making a big design change to the organization and potentially reflecting that also in the architecture... Sort of a top-down approach ... and to be done in kind of a big bang way. So the self-managed, bottom-up, and incremental approach offered by FaST was appealing to James, being much more in the spirit of agile: In the FaST approach we're scaling vertically . We're adding people by having more people participating in one virtual team (a Collective), having more people act as a single team. Essentially, James ran an experiment in that company with a subset of seven very tightly coupled stream-aligned teams (around 50 developers) and turned them into a FaST Collective. This essentially is a single large team that regularly self-organizes into temporary small teams based on the work at hand. James concludes with these five key takeaways: We conclude that FaST has helped to design and sustain a high-level product-centric ecosystem in that company. James also talked a lot about the high transparency such an ecosystem created for its business stakeholders. And we know in empirical process control, transparency is a prerequisite for proper inspection and adaptation. Hence, it is an enabler for better steering and governing. So the third organizational design was displaying better manageability and higher adaptability than the other two options (component teams and stream-aligned teams). This positions FaST in the top-right corner of the Org Topologies™ map, potentially spanning the area from B2 and B3 up to C2 and C3. And where does a FaST collective as described in the video live, exactly in the land of FaST? The vertical aspect: It depends on the size of an organization: with only 50 people in R&D, all developers would belong to a single Collective. And by definition, that Collective would own the whole product. Therefore, that would be a C-level ecosystem. We cannot imagine the constant creation of temporary teams with hundreds of developers in an open space every other day (we are open to learning that this is possible, so we need more case studies, experience reports, or invitations to implement this). However, for now, with the facts that we have, we believe that with hundreds of developers, there will be a need for several Collectives. And likely each Collective will own its product part. Therefore, this would be a B-level ecosystem. The Collective described in the video was formed from seven tightly coupled teams, while the rest of the organization remained unchanged. Although it was not clear in the video whether the Collective worked on the whole product or just its part, it is safe to assume that they worked on a product part. Therefore, the case presented in the video would be classified as a B-level archetype. The horizontal aspect: For a work unit (a team, a team of teams) to qualify for a multi learning unit (Y3, A3, B3, or C3) it needs to exhibit a unique observable behavior: over time people in that unit are acquiring new skills, hence they 'multi-learn' (we borrowed this term from an HBD article ). Multilearning is very much different from multi-skill work. In the latter case, people with existing skills work closely together, utilizing their existing skills. In a long-living stable team with a broad product scope, it is simply not possible to keep utilizing one's existing skills forever without being constantly under or overloaded. That's because a constant match between the existing skills and the demand for skills is highly unlikely in a complex work environment (i.e., product development). That means, the fewer skills you have, the bigger the chance you won't be able to utilize them all the time when working on the business priorities. So, in a long-living stable team, to stay relevant, one will have to acquire new skills that are currently in higher demand, hence: multi-learn. That's the dynamics expected in LeSS with feature teams (as a side note: in the video James is misusing the term 'feature teams' equating them to 'stream-aligned teams'; which is a big misunderstanding). In FaST, people have a chance to change work and with whom they work every few days (for the next FaST cycle) because of the built-in fluidity. Will the people be acquiring new broad skills in such a fluid environment? Or will they follow the work and maximize utilization of their existing skills? Will a back-end developer self-volunteer to work (and multi-learn) a front-end task for the next cycle, or will she be pulled in to contribute with her existing back-end skills? That is very contextual and will depend on many things, including personal motivation, stress, level of engineering practices, code-sharing policies, coaching by the managers, the existing reward systems, HR policies... So we can't say that FaST will always be fostering the creation of multi-learning work units, though, we believe it is not impossible, but FaST alone (as a process) won't suffice. Hence, it is safe to assess the target org design in James' story at B2-level Collective. Summary This case study illustrates the power of the Org Topologies™ approach in assessing different organizational designs and organizational change ideas from the viewpoint of structural facts and observed inter-team dynamics. We encourage you to apply it at your workplace and report back. There is a growing learning community: join us in Slack attend our educational events report back your experience reports (C) 2023, Alexey Krivitsky and Roland Flemm. Org Topologies™. This experience report presents a personal view of the change story based on the provided references. 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.

De Volksbank is the fourth largest bank in the Netherlands. The bank was formed two hundred years ago from regional savings banks. Today, de Volksbank focuses on consumers, independent entrepreneurs, and small and medium-sized enterprises. The bank operates mainly in the areas of payments, savings, and mortgages. In 2021 a new four-year strategic agenda was introduced focusing on growth by strengthening customer relationships and further increasing the banks' social impact. To realize this ambition, a transformation was initiated that aimed at implementing a uniform agile way of working with independent, integrally responsible customer journey teams. The new strategy should make the bank more customer-centric and enable them to get better, faster, and more effective at delivering value to customers. The transformation impacted the whole bank. In March 2022, about 3,000 people faced either a change of work, a change of team, and/or a change in the way of working. In the new structure, the bank was split into 14 "Hubs". These are value areas with P&L responsibility. Each hub is responsible for a specific customer journey. A Hub is set up integrally, which implies that each hub contains business, IT, and operations. The entire organization "flipped" to the new model in March 2022. This case study analyzes the transformation journey using Org Topologies™ Scans and focuses on the Business Banking Hub. It covers three organizational design phases: Org scan of the pre-agile setup before August 2021. Org scan of the 2022 dVM pilot . Org scan of the current layout per February 2023. We will clarify the stages with OT maps using the following symbols: More explanation and background information on Org Topologies™ that help to understand this case study can be found here and here . 1. Pre-transformation setup before August 2021. The department "Business Banking" was divided into three sub-departments: Operations, Business Lending Sales Support, and Customer Onboarding. These departments were focused on servicing business customers. A single team "monitoren en verbeteren" (monitor and improve) was responsible for product development. This was the department's R&D team. The picture below is a detailed view of the Business Banking department in deVolksbank prior to the transformation. Of the 10 people in "monitoren en verbeteren", 6 were tasked to improve the operational workflow of the three operational teams. They had task scope, no product vision, and no value-based prioritization of work. They were working on improvement requests given to them by the operational teams. These requests did not necessarily have high customer value. They were working as individuals on unprioritized tasks (three operations groups with different requests). They did not have the skills or authorization to make software and configuration changes in the banking systems. Their work was restricted to: specifying changes requested by the operational teams, assigning them as tasks to technical teams somewhere in the adjacent IT group , chasing progress. Working as individuals on unprioritized tasks (three operations groups with all kinds of change requests) makes them a Y0-level group on the OT map . The queue of work was huge due to the long waiting times for the work in progress. Larger and more complex initiatives were hard to implement and took many months, sometimes years to complete. Tasks belonging to these initiatives got stuck in the worklists of teams in the IT department due to unclear decision processes. The people were used to working in an environment where asynchronous communication via email requests was the norm. They were spending most of their time lobbying in IT to get their requests prioritized and negotiating with a vast landscape of stakeholders. A huge amount of time was wasted waiting. The other 4 people worked as a Scrum team focusing on New Business Lending products. The subgroup's work was specifying and accepting changes in collaboration with an external software company that developed a New Business Lending product. This team specified customer-centric features for the vendor to develop. The team and their PO were decomposing the customer requirements into tasks to hand them over to the vendor's development teams. This makes them an analyst team for the external developers, archetype A1 in "the speculation department" on the OT map. The New Business Lending team did not suffer from the bank's IT dependencies but had 100% dependency on their external vendor and they had some dependencies on business stakeholders ("Brands"). They were able to deliver value much faster than the teams with internal IT dependencies. The developers at the vendor were processing tasks for multiple clients. The vendor did not have dedicated teams per client but had two groups of developers working on specific parts of the product. 2. Pilot with feature teams 2021-2022. Prior to the bank-wide adoption, a new self-invented model (based on team topologies and Spotify) called "dVM" (de Volksbank samenwerkingsModel) was piloted in the Business Banking department. It is noteworthy to mention that this transformation initiative was driven by the Business side of the bank, not by IT, which is more common. The people working in the R&D team "monitoren en verbeteren" were placed into four groups, each focusing on a specific customer journey. Each group contained one R&D team and one or more service teams. The R&D teams focused on developing products and the service teams kept their focus on daily operations, serving the customer. There was a tight feedback loop between them. The operational teams were important stakeholders, providing valuable customer feedback. Each R&D team had its team PO, prioritizing work on value. The following groups were created: The Customer Onboarding group: everything related to smoothly welcoming new customers. The New Business Lending Group: building new business lending solutions. The Business Lending Maintenance Group: Supporting existing business lending solutions. The Bloxx group: developing an approach allowing business customers to configure their own service and product catalog Each R&D team was formed with cross-functional business people. Each team was able to address a full range of business problems (features) related to their domain but they had no technical expertise. This makes them A1-level teams (analyst teams, or "the speculation department"). The backlogs contained customer-centric features instead of service-oriented tasks. The fact that the R&D teams did not have IT capabilities was a problem because most of the changes they were working on required changes in IT systems. Some teams were able to do no-code changes, but all 'n all, their technical capabilities were limited. Although still low on the Org Topologies™ map, this setup was experienced by the team members as a huge improvement because now: they were working full-time in a steady team, they were working on the specification and delivery of customer features, they were working on high-value work because work was prioritized on customer value. At the same time, having limited capabilities combined with end-to-end responsibilities was frustrating. They were wasting time chasing their changes to be delivered. We gradually improved this situation by extending their (technical) capabilities. This desire for autonomy was not appreciated by the surrounding organization. Don't forget this was only a very small pilot in a very big bank, so not surprisingly, the team's appetite for mandate, capabilities, and speed was causing resistance in the remainder of the bank. The New Business Lending team continued working with the external vendor. In the beginning, this made their life relatively easy since they had limited dependencies on the technical infrastructure and IT teams of the bank. However, the number of teams at the external vendor had grown and now were organized as component teams: Each vendor-component team had a team "PO" managing their team's backlog. Coordinating the work across the other vendor teams was difficult and slowed down the development process. An additional complication was that the external vendor was not solely focused on delivering the bank's requirements but they were also productizing the requirements to market them to other customers. This makes total sense, but it was not helping the bank. In summary, from the bank's point of view, the vendor's business model and organizational design had a negative effect on the quality of service. The other three teams were depending heavily on the bank's IT teams. The IT departments worked as component teams (Y0 and Y1 archetypes). Due to the high number of technical dependencies and the lack of support for the new feature teams, the Customer Onboarding PO got completely stuck. She had to split customer requirements to feed the IT component teams, she had to fight to get her work prioritized, and she had to bend over backward to find a way to get her changes integrated across multiple release calenders. Not a job you would envy... The Bloxx team was fortunate because they were the first team to have developers in the team. However, there were some startup problems here too. The developers in the Bloxx team were working under the strict guidance of the bank's PEGA group. This group had a strong architectural drive and was focused on building centralized and reusable solutions for the whole bank. The PEGA developers were telling her how to change the specifications so the solution could fit into the PEGA architecture. It was the world upside down: the Bloxx PO found herself being a lobbyist trying to get the PEGA developers in her team to build what she needed. One thing all teams had in common was their dependence on "the brands". The bank exposes its services in the Dutch market using four distinctive customer-facing brands. These brands had different and conflicting requirements for the solutions built by the four R&D teams. The brands were powerful: they were deciding on requirements and approved or rejected the changes created by the R&D teams, often on the technical level. Customer Onboarding tried to get around this problem by adding a brand specialist to their team. This person was working as a proxy on behalf of all brands. In practice, this did not work because the brand specialist's decisions were overruled by other (brand) stakeholders. The dedicated teams were able to deliver in a regular Sprint cadence, which was much faster than before (weeks instead of months). But their mandate was not respected by the unchanged organization. In addition, the contradictory demands of the business stakeholders, and the complex IT environment were frustrating them. These were the most important learnings from the pilot that helped to improve the dVM org design: Feature teams with a PO to prioritize work on value and the operational teams' focus on servicing the client resulted in faster delivery of better solutions and better service to the customer. Reducing the power of the stakeholders (i.e. brands) by clarifying the R&D team's mandates is required. Reducing the influence of (middle) management by repurposing their role in the service of the teams is needed. Teams should be bus-dev-ops teams by adding all technical capabilities to the teams required to deliver "Done". Clear responsibilities and capabilities of the feature teams attract stakeholders who are in need of the capacity to get things done and try to feed their changes into the feature teams. This was unexpected behavior that actually proved this initiative was successful. Creating feature teams creates much resistance in the organization surrounding these teams. Gradual change is more complex to manage. 3. De Volksbank SamenwerkingsModel (dVM) in Feb 2023. The pilot setup with R&D teams and service desk teams (operations) close together in groups was implemented in the whole bank. All four Business Banking R&D teams gained autonomy by growing their technical capabilities. Some reached A3 (autonomously working end-to-end on customer journeys) and most were A2 (incomplete teams working on customer journeys, not end-to-end). The majority of the dependencies on the brands have been resolved by moving product responsibilities of the brands to the feature teams in the Hubs. The brands now have teams that focus purely on work like marketing and campaigning, not banking product development. The separation between roles and responsibilities is clear: the R&D teams have the mandate and the brand teams are stakeholders to them. Most of the dependencies on IT have been resolved. Two of the R&D teams now all have the technical capabilities they need to work autonomously. The solution to remove the technical dependencies was achieved by adding developers to the teams. The POs determine what is most valuable, not stakeholders like the architecture group via the (PEGA) developers. The New Business Lending team's dependencies on the external vendor were not resolved. The vendor has added a "first contact" proxy team to better serve de Volksbank. The proxy team provides lo-code/no-code solutions, is a single point of contact, and handles coordination with the vendor's internal component teams. The bank and the vendor collaborate on further reducing lead times. The proxy team operates at the feature(set) level and is narrowly specialized in analysis (A1 Archetype). The teams inside a value area (Hub) coordinate using OBEYA . The same practice is used to align with teams in other hubs. The Business Banking Hub Lead says that the implementation of the dVM model was very successful in creating strong autonomous teams. Alignment between all teams inside the hub using OBEYA has proven to be pretty successful too, but there are challenges in resolving cross-hub initiatives. Higher management has a tendency to fall back to old patterns to manage cross-hub problems (instead of trusting the Hubs to self-organize). On one hand, this is due to a lack of experience using OBEYA for that purpose. On the other hand, the Hubs suffer from local thinking. The Hub leadership teams should be more aware of the recurring dependencies between Hubs (and teams) as an indication that the org design can be improved. Conclusion Did the new org design make Business Banking more customer-centric and get better, faster, and more effective at delivering value to customers? It definitely did. Further improvements will be achieved by eliminating remaining dependencies, re-evaluating the current org design and improving the OBEYA for better cross-Hub collaboration. We are happy that the Business Banking Hub POs perform experiments with cross-team collaboration (applying practices from the higher B-level). The dVM design was intended to be an evolutionary model. The OT Scans (TM) can serve as a guide to monitor the progress of the bank's journey to further improve its organizational design. We recommend each department (Hub) plots a current and future state map. This will increase our understanding of why things currently work or do not work, and will enable us to find the root causes and best possible solutions for improving the management of cross-hub problems, resolving remaining impediments, fixing staffing problems, etc. Acknowledgments We want to thank the following people for investing their time in creating this case study with us: D. Karacan (PO New Business Lending) J. Verhey (Hub Lead Business Banking) (C) 2022, Alexey Krivitsky and Roland Flemm. Org Topologies™. 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.

Exploring Org Topologies at Loglass This article is also available in Japanese . I have recently become interested in Org Topologies - a framework designed to enhance organizational design through thoughtful structuring, fostering higher adaptability, and ensuring a transparent change process. Org Topologies revolves around two key axes: the "Scope of Capabilities" and the "Scope of Work." Together, these axes form 16 archetypes that represent different organizational patterns or types. These archetypes help in identifying, assessing, and designing organizations to optimize their adaptability and performance. The Scope of Capabilities measures the level of cross-functionality and the ability of a unit to deliver value independently. High capability consolidation means fewer technical dependencies and greater autonomy. The Scope of Work evaluates the breadth of the work a unit can handle, from narrow task-specific work to broad value definitions that encompass entire customer needs. This framework allows for simple visualization and classification into the 16 different Archetypes on a two-axis map. By understanding these archetypes, organizations can craft a thoughtful design, fostering higher adaptability and resilience in the face of changing business needs. In January 2024, I introduced Org Topologies to Loglass - a Japanese company providing a cloud-based management system aimed at improving the productivity of budget and performance management. I have recently been supporting. The company divides its product into multiple functional areas, with each area being developed by independent Scrum teams. Each Scrum team is highly capable as a stand-alone unit, but there is not much collaboration between the teams. I gave a brief introduction of Org Topologies in a short 30-minute session. The participants showed a strong interest and immediately held a one-hour workshop the next day with all employees in the development organization, where they plotted the current status of each team on a map. Although it was only a self-assessment in a short workshop, most teams plotted themselves onto A1 - A2, as I expected. To clarify, the A1 and A2 archetypes represent specific types of organizational structures: A1 (Siloed functional group with feature focus) : Teams within this archetype are specialized in specific functions and work on particular features. They tend to work in silos, with limited interaction with other teams. A2 (Incomplete multi-skill teams with feature focus) : These teams have a mix of skills but are not fully cross-functional. They also focus on specific features, similar to A1 teams, but with slightly more collaboration among team members. There were internal discussions, mainly about moving up from the A-level to the B-level. The B-level archetypes are more collaborative and aligned with business goals, promoting greater agility and responsiveness to market needs. For instance: B2 (Incomplete multi-skill teams with business area focus) : Teams that are not fully cross-functional but work more collaboratively across different business areas, fostering better alignment with business goals. B3 (End-to-end fast-flow teams with business area focus) : Highly cross-functional teams that manage entire business areas, promoting faster delivery and greater adaptability. During my observation, I noted a few things: Some people's perspectives were focused on their own team rather than the whole organization. For example, several stated that their teams wanted to advance to the B-level, but they did not seem to realize that this would require strong agreement and collaboration with the other teams. Most participants acknowledged the benefits of B-level teams but couldn't imagine what B-level or "a team of teams" would be like. Some people felt that staying at the A-level was also a viable option. They admitted that the teams were "optimized" and each individual team was quite productive. They mentioned that moving to the B-level would be costly. They and I had long discussions about what their organization's challenges were and what their goals should be. It took several months before they finally decided to "go up". 5 months later, in June 2024, there was the "Developer Productivity Conference", a Japanese domestic tech conference, where Hiroshi Ito (VPoE of Loglass), gave a talk. He introduced Org Topologies and their mapping activity from the beginning of 2024, where their teams were currently at A1-A2, and they decided to move to B2-B3. He went on to talk about scaling their agility and for the moment, they would be trying it based on the adoption of FAST Agile. FAST Agile is an approach that blends ideas from Kanban, Open Space Technology (OST), and Agile to create a lightweight, scalable framework. It emphasizes forming collectives, setting up the organizational foundation in a one-time setup, and continuously improving through a cycle called the Value Cycle. This cycle promotes self-organization, synchronized activities, and regular meetings to keep everything aligned. It might be a big challenge for Loglass, but I believe that the experience they gain from it would be a valuable asset. I also intend to actively support them going forward. 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.

photo by unsplash Background to the use case At the beginning of March 2024, I was lucky enough to join the very first OrgTopologies™ training course in France with the two co-creators Alexey Krivitsky and Roland Flemm. OrgTopologies™ map As is often the case, ideas evaporate after training courses. However, I had the opportunity to use this beautiful tool just three weeks later, during a workshop with a group working on a banking domain's information system. The scope of this domain was account management and the management of different payment methods (SEPA; IP; Virement Gros Montants...). The people working in this area bring together a range of fairly traditional skills, such as Business Analysis, programming in different languages, and Ops. These areas of expertise are sometimes in the same team, and sometimes in separate teams. Setting the scene Before the workshop, the sponsors requested to identify ways of "being more agile". I shared with them that gaining fluidity and the ability to change priorities was a way of qualifying and quantifying "being more agile". I began the workshop by telling the story of a startup I know in the C3 archetype. This startup was launched in 2013 by its two founders, who did everything for their first customers. As it grew, the startup changed its structure and ended up with several specialized teams, losing the global vision of the product and the initial fluidity. To illustrate the Y0 archetype, I evoked the caricature of the security expert who forbids everything to everyone. Next, I suggested that participants map out their current teams, working in groups to share their views on the place of different teams. To do this, I briefly explained the map using a 2x2 version of the map (showing only no team/team and outputs/outcomes) and then went into a finer level of detail with the map of the 16 archetypes in a 4x4 matrix. Blank OrgTopologies™ map The only people present were managers. Developers were not present. So we clarified the objective, which was to generate ideas for improvement. As many people were absent, I didn't want participants to commit to action plans involving those who were not present. Sub-group mapping The sub-groups raised subtle questions about the granularity of the definition of "Products". On the one hand, talking about "Products" that are too small (SEPA Transfer; IP Transfer; Large Amounts Transfer...) leads to very local optimization; makes us lose sight of the global vision; leads to the accumulation of work lists, queues, the need for a layer of coordination and priority arbitration... On the other hand, talking about "Products" that are too big (the Bank) becomes too abstract and makes employees lose touch with reality. I let them determine their approach to read the map, to encourage their involvement in the workshop, rather than adopting a "trainer" posture, which was not on the agenda. As a result, several tickets were placed at level B (team of teams or meta-teams, multi-functional and multi-technology) when it would probably have been wiser to place them at level A (group of teams more or less focused on distinct functionalities and areas). Other debates arose around the boundaries between columns 1 and 2 or even 3, which I have steered towards the "lower" archetypes to keep improvement options more visible. Current mapping The groups placed their tickets on the shared board and discussed to align their points of view. I launched a few discussions around certain teams identified as A1 or A2; B2 or C2, but decided not to waste our time on unimportant details for this first workshop. The participants appreciated this graphic representation, even if they didn't make any major discoveries, as the map was already partly in their heads. Next, we drew lines to clarify the interactions between the different teams, which will be invaluable for the idea generation that follows. Links between teams Based on these tickets and links, participants then discussed their options for improving and restructuring the teams in order to progress towards the higher-level archetypes, towards the right upper corner of the map. We can see here the grouping of three teams together (Business Analysts + Programmers + Ops), three times, as well as splitting an Ops team to quickly share its expertise. Ultimately, this should lead to the creation of multi-functional, multi-technology teams with broader scopes of responsibility and autonomy than initially envisaged. Final Org Topologies Map I didn't reveal my magic trick until the end of the workshop, only then mentioning that I had used the Org Topologies map. To conclude the workshop, I proposed a few questions for reflection, with a round-table discussion so that everyone could comfortably express themselves: what did the workshop reveal to me? What did I learn? Knowing that many people are absent, what could MY next action be (tell them about the card; repeat a similar workshop in a few months' time)? How do I feel now (confident; curious...)? Conclusion With this material produced, Roland Flemm subsequently helped me to clarify several points related to the map that emerged from the workshop, enabling me to better understand the map and improve future workshops. We've started a movement with a fairly simple workshop thanks to the map. We now need to maintain this momentum and support our teams in moving towards these higher-level archetypes. And you, in what context could you use this map?