ORG TOPOLOGIES 

While developing the Org Topologies change method and writing the  #10XORG book , we have come up with the concept of Elevating Katas . The term kata comes from martial arts, where it describes a practiced sequence used to build skill and judgment through repetition. In Org Topologies, Elevating Katas serve the same purpose: they provide a practical way to evolve an organization deliberately, without relying on one-off transformations or wholesale reorganizations. The 10X Org principles set direction. They clarify what matters and what trade-offs are being made. The Katas make that direction actionable. Rather than prescribing best practices, Katas create safe, repeatable ways to reshape structure, mandates, roles, processes, and incentives—while learning from real work. This catalog of katas is now tightly integrated with the upcoming book chapters. Learn more about Elevating Katas, see the full and growing catalog, and see them being applied in case studies.

I recently co-authored a case study about our journey at Strobbo over the past few years: ‘Strobbo Adopts Professional Scrum to Accelerate Go-to-Market’ . Alongside my colleague Bert Neels , our agile coach Steven Deneir , and the fantastic team at Scrum.org , we delve into the challenges we faced and how we overcame them over 12 to 18 months. And believe me, it wasn’t always smooth sailing! Even after contributing to the document and recording a podcast about it, I still feel like there is more to share about our story. In this document, I aim to explore our journey through the lens of organizational design using Org Topologies. This approach provides a structured map to navigating the complexities of teamwork and organizational structure. How did we reconfigure our team  dynamics? What organizational structures helped us thrive? It’s like assembling a detailed jigsaw puzzle where every piece is crucial.  Background on Strobbo Strobbo is an HR platform that automates the administration of flexible workers. It offers an all-in-one solution for managing availability, staff scheduling, time tracking, Dimonas (social security declarations in Belgium), contracts, and monthly payments across various sectors, including hospitality, retail, and the funeral industry. Strobbo integrates with existing tools like cash register systems, enabling quick analysis of turnover and staff costs through its reporting module. The platform also connects with reservation systems and weather forecasts to optimize staff scheduling and links with payroll systems for seamless payroll processing. Founded as "Onlinewerkrooster" in 2016 in Lommel, Belgium, by Nick and Bert, who identified a need for flexible staff scheduling in the hospitality sector, Strobbo addressed issues related to the white cash register system aimed at preventing tax evasion. By 2018, it had a team of 9, serving 500 businesses, and was acquired by Protime, a European workforce management specialist, to accelerate international growth. Rebranded as Strobbo in 2020, the company expanded internationally, supported by a growing team. Today, over 2,000 businesses in Belgium and beyond rely on Strobbo for automating personnel administration. Introduction to Org Topologies Since we will be using Org Topologies to analyze our organizational design, I will first introduce some of the basics. What follows below is just the bare minimum to understand the rest of this chapter. For a more detailed introduction, I can recommend reading the Org Topologies Primer . The Org Topologies map contains a set of recognizable archetypes, each with their own characteristics. In earlier versions these were labeled with letters and numbers; in the current version, the emphasis is on understanding mandates  and the kind of organizational intelligence  the design enables. The Horizontal Axis The horizontal axis of the Org Topologies map represents the Scope of Skills Mandate  of a unit in your organization. The more an organizational unit moves to the right, the broader the range of skills it is mandated to apply, and the faster it can deliver value with less dependency on asynchronous hand-offs. We distinguish 5 different types of org units:  Functional units contain people with similar skills who typically perform the same function. This is often not yet a team as everyone is working on their own tasks. Multi-skill unit(s) or cross-functional team(s) that can tackle more complex work. There are still dependencies on other organizational units to complete their work. End-to-end unit(s) that can deliver end-to-end value without being held back by asynchronous dependencies. Expanding units can continue to learn to remain end-to-end capable over time when new technology emerges. Unbouned contains org units that are free to learn without limitation. The Vertical Axis The vertical axis indicates the Scope of Work Mandate  in which the organizational units collaborate and share work. The higher you move up the axis, the closer the unit is to the customer and the more it will be able to deliver customer solutions: Task focus : the unit receives tasks to work on. Capabilities focus : the unit receives work as capabilities that need to be built. Partial solution focus : units focus on a partial solution area and might work for goals within that partial solution scope (for example a sub-product, a business area, or a bounded segment of the customer domain). Whole solution focus : units can work on customer and business problems throughout the entire customer domain and are not tied to any partial solution or sub-product. Unbounded : units operate beyond fixed solution boundaries, dynamically shaping work based on learning and strategic needs. Below you find the full 4x4 map used in detailed org design work. It would take me too far to go into detail of each archetype now, but I will explain those in context of the teams later. However, it is worth mentioning here the position on the map where units are both complete in skills mandate and broad in work mandate (whole solution focus, and in some cases even unbounded). As an example, the authors of Org Topologies refer to startups being in that space, as in this case, the founders are typically very close to the customer and either have the necessary skills or are forced to learn them (mostly because there is no money to hire someone to do the job). As a business grows, you will get lower archetypes, and it requires more and more effort to get back to that state (if it is even possible). Scaling Issues and Mechanical Scrum Our story starts somewhere roughly two years ago. As Strobbo's team had expanded over time we had already restructured into multiple smaller teams to maintain agility and efficiency. This restructuring involved creating three development teams with a multi-skill mandate  and a capabilities-focused work mandate , and a second-line support team with a task-focused work mandate . The second-line support team would handle more complex support issues and maintenance for our older technology stack, thus allowing the new development teams to concentrate on the newer technology stack and developing new features. Despite these efforts, we faced significant challenges, including frequent bugs, performance issues, and a lack of maturity within the team. We brought in external experts operating with a very narrow, TASKS-1 mandate  to help improve code structure, implement solutions for better quality and performance, and provide training for the existing teams. However, several key issues persisted: Mechanical Scrum : Teams were going through the motions without fully understanding Scrum principles. Overplanning and Lack of Autonomy : Heavy reliance on the Product Owner led to disengagement. Lack of Trust and Fear of Speaking Up : Trust issues and fear of speaking up resulted in low motivation and commitment. Poor Communication : Meetings were passive and disengaged, leading to individualistic work. Tactical vs. Goal-Oriented : High pressure from management and pessimism undermined efforts. Lack of Transparency : Poor transparency and communication led to a lack of shared understanding. The issues faced by Strobbo indicated that while the teams were designed to operate as cross-functional teams, they were still struggling to embody the characteristics of effective teams with those mandates. Lacking a visual depiction of Org Topologies, we missed the crucial insight that Strobbo's teams were in a transitional stage—aiming to operate as cross-functional teams—but facing significant hurdles that kept them closer to task-focused and functionally siloed behavior. Some specific examples of behaviors inside the teams that kept us back were: A large focus on ‘resource’ efficiency , with team members being very focused on keeping busy individually.  Breaking down work to fit the skills of one team member , resulting in frequent hand-offs between single-skilled individuals. Inside the teams people were falling back to task-focused behavior and were not working as a team but also overly focused on tasks. Some team members compensated by keeping the overall picture and breaking down the work. Mapping of the dynamics inside the team. On the other hand there were also still several dependencies between the teams and the product owner and the teams and the external experts that were holding them back: Relying on testing and acceptance by the Product Owner , which caused frequent delays. Contract thinking at task level when feedback was given. e.g. there were frequent discussions about something being in the acceptance criteria (or not) and no focus on the overall goal. Teams did not trust their own skills to make architectural changes and relied heavily on external experts to do the work, causing more hand-offs and delays. Dependency on the second-line support team to release features dependent on our legacy software. While some of these dependencies were to be expected (e.g., dependencies on the legacy software) for the foreseeable future, reliance on both the Product Owner and the external experts was something we actually wanted to avoid. The teams were, however, lacking in certain skills to be able to avoid this. These challenges, combined with legacy issues in both the old and new tech stacks, further complicated their transition to stronger cross-functional and more independent behavior. A visual Org Topologies map would have highlighted these discrepancies, allowing us to address them more effectively and guide the teams toward the desired position on the map. Implementing Lean Improvement Kata Recognizing these challenges, we initiated a coaching track with Steven Deneir , utilizing a Lean Improvement Kata  on a weekly basis to enhance our work processes. This approach aimed to systematically address our issues and guide us towards more effective team dynamics. We set forth these goals for ourselves: Make the team independent - stop them from looking to Bert (co-owner of the company) and Michael (Product Owner) for the smallest decisions, clarifications, etc. Make sure the team understands that everything can be discussed and changed. Make sure the team is proud of their work and boost morale. Make Strobbo a showcase within our parent company Protime as a good example of what it means to be a team and what they delivered. Prepare the team for further growth (uplift the technical skill level). No longer practice Scrum mechanically and half-heartedly. Looking at these goals through the lens of Org Topologies, we aimed to enhance the team's technical skills, moving their position to the right on the map. Simultaneously, making the teams less dependent on the product owner required them to move up on the map. Speaking in terms of mandates, we knew that we wanted to expand beyond a capability focus toward a partial solution focus  with our teams, and focus on achieving business agility. Achieving full adoption of the CAPS-2 Archetype But as we saw in the previous section our teams were still struggling to fully adopt the intended position on the map. Our Lean Improvement Kata resulted in a bunch of positive improvements, which really helped elevate the teams to more stable cross-functional, capability-focused behavior and further. With the coaching we received, step by step we were able to make progress. Many of these are also proposed as Elevating Katas™  within Org Topologies. Sprint Goals and Transparency : Sprint Goals : Introduced clear Sprint Goals to guide the team's efforts, ensuring alignment and focus on delivering value. Stakeholder Involvement : Invited stakeholders to Sprint Reviews, transforming them into collaborative sessions that provided valuable feedback and boosted team morale. On-Site Reviews : Moved from online to on-site Sprint Reviews, which significantly improved interactions and engagement with stakeholders, including senior management. Product Backlog Refinement : Involved team members in refinement sessions using Impact Mapping, Event Storming, and User Story Mapping. Team Cross-Functionality, Self-Management, and Definition of Done (DoD) : Encouraged collaboration between front-end and back-end developers. Implemented Mob development and pair programming for knowledge sharing and tackling complex issues. Focused on End-to-End Testing, balancing technical and functional responsibilities. Ran a defect matrix workshop to aid in self-management and decision-making. Conducted workshops to define and clarify the DoD . Made UnDone work transparent , creating a clear path to getting items into production. These structures and practices collectively enhanced team autonomy, transparency, and alignment, driving significant improvements in Strobbo’s agile adoption. Transitioning from Capabilities to Partial Solution Focus But as we said our vision was to enhance our team's capabilities and autonomy. Initially operating with a capabilities-focused work mandate, we sought to transition toward a partial solution-focused work mandate within the Org Topologies framework. Our vision went further than simply improving processes; it entailed a fundamental shift towards greater business agility and independence. After fully realizing the CAPS-level position, the teams were working effectively, but there was still a significant amount of coordination required from the Product Owner. Additionally, we wanted to close the gap with the customer to ensure better alignment and responsiveness to their needs. This is also the point that we learned about Org Topologies and understood that we needed to spend more time with the team to help them better understand the direction that Bert and I were moving the teams toward. In a team exercise, we started with showing the video  ‘How Misconceptions About the Product Owner Role Harm Your Organization and What To Do About It’  to not only better explain the role of the product owner but also to make the point that they can take ownership themselves. We then let the team put themselves on the map , and had a group discussion about what we are currently lacking. To further elevate the teams at this point, we invested heavily in the following Elevating Katas, building on our previous efforts: Product Roadmap and Ownership : Goal-Oriented Backlog : Transitioned from a feature backlog to a goal-oriented backlog, focusing on metrics such as the number of pilot customers live, feature usage, or deals sold. The emphasis shifted from merely completing features to ensuring their adoption and impact on the company. Roadmap Workshops : Organized workshops with internal stakeholders and developers to align on the product vision and co-create the roadmap. Enhanced Collaboration : Fostered collaboration to reduce reliance on the Product Owner for day-to-day operations. Product Backlog Refinement : User Story Mapping : Utilized techniques like User Story Mapping to create valuable increments towards achieving goals, ensuring value delivery each sprint. Flexible Scope : Instead of detailed estimates, we set goals and placed bets on achieving them within a certain number of sprints. This approach acknowledges uncertainty and allows flexibility in adjusting the scope based on the situation, focusing on the impact rather than features. Sprint Planning : Limited WIP : Leveraged our goal-oriented backlog by limiting work in progress (WIP) and, in some cases, having teams focus on a single goal at a time. Sprint Goals : Centered sprint goals around the next best step for the current goals. A significant consequence of these changes was the evolution of the Product Owner role to be more outward-facing, focusing on stakeholder and customer engagement. This shift also created greater transparency on the roadmap and backlog for both development and business. At this point on the map you can also notice a big difference in the interaction between the teams. Task-focused and capabilities-focused units require external coordination at the team level. With a partial solution-focused work mandate we see the dynamics change to a ‘Team of Teams’ where teams will organize themselves. Instead of coordinating at the team level you now coordinate the ‘Team of Teams’. This also changes a lot of the dynamics regarding ownership as capabilities-focused teams will be more likely to focus hard on their own parts and use it as ‘cover’, whereas a partial solution-focused ‘Team of teams’ will start self-organizing based on the work they receive. There can still be ownership, but it is no longer a problem of the external managers to figure this out for the teams. Part of expanding toward partial solution focus involved less reliance on external expertise, which is why the ‘external experts’ are gone from the map. Collaborating with Protime Strobbo (formerly Onlinewerkrooster) was acquired by Protime in 2018. The timeline discussed previously occurs after this acquisition. While Strobbo remains a distinct brand and product within Protime, alongside their other workforce management solutions, we operate mostly autonomously as a product group. This autonomy allows us to make decisions regarding our product and technology independently. However, we don't operate in isolation. Over time, we've made significant progress in integrating the Protime and Strobbo product groups, fostering closer collaboration. This integration highlights the importance of addressing how we fit within the larger company and how it influences our position on the organizational map. Portfolio management Until now, I have limited the scope to our product development part of Protime. However, the recent creation of a Portfolio Manager role has shifted the position of the Product Owner. From this larger perspective, it becomes clear that the product owner now lacks a ‘whole solution focus’ and is concentrating only on a specific part. This change adds an extra layer of coordination and alignment that was previously not there. The impact on the teams is limited, but as the Product Owner might not have the whole picture anymore (depending on how transparent the Portfolio Manager is), we risk them making wrong decisions or losing time on additional alignment. We should realize that when work moves from portfolio to product and then to development, it is not a sequential flow. As we learn more, work might move back from development to portfolio. If this requires a lot of coordination, it can slow us down in terms of delivery and innovation. Planning Domain Following the acquisition, the Strobbo team gradually became responsible for the entire planning domain within Protime. Strobbo continues to exist as a standalone product, but two additional teams have been added to integrate Strobbo and another recent acquisition ( Sheepblue ) into myProtime, Protime's main product. This integration effort aims to streamline functionalities and enhance the overall user experience within the Protime ecosystem.  This integration necessitates adapting our organizational map to fit the larger context. In Protime, the Product Owner (PO) role is different, responsible for assisting multiple teams with feature development but not acting as a true Product Owner. Instead, product ownership is handled by the Product Manager. This shift demonstrates the clear benefit of using an Org Topologies map over a framework-based organizational design. Even though the titles change, the position on the map remains consistent. The newly added teams comprise developers from both the Strobbo and Protime development teams. The Planning domain fully encompasses Strobbo as a product, with all its features, and includes Planning as a feature of myProtime. For the teams working on myProtime planning, the scope of work is therefore narrower than for those working on Strobbo. This narrower scope limits the ability of the myProtime planning teams to cross the chasm as the Strobbo teams did. Work beyond their scope must be picked up by other teams, requiring coordination at the 'product' level between the PART-level archetypes. Conclusion Reflecting on Strobbo's journey, it is evident that our path to agile excellence was marked by both significant challenges and transformative successes. Initially, moving from a single-team scrum setup to multiple, more specialized teams did not immediately resolve our deep-seated issues related to agility, autonomy, and cross-functionality. However, over time, through persistent effort and continuous improvement, we were able to achieve these outcomes. Key to this transformation was the introduction of clear Sprint Goals, stakeholder involvement, and regular on-site reviews, all of which enhanced transparency and team morale. Although we did not initially use Org Topologies, in hindsight, it would have provided a critical framework for understanding and addressing the complexities of our organizational structure. This approach could have highlighted the foundational issues sooner, guiding us more effectively through our transitions. Our integration into Protime further underscored the importance of aligning our product and technology strategies with broader organizational goals. By adopting a goal-oriented backlog, fostering collaboration, and maintaining a flexible scope, we ensured that our teams remained focused on delivering impactful solutions. As we continue to evolve, the lessons learned from our agile practices will guide us toward sustained growth and innovation within the larger Protime ecosystem. 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 Michael provides great examples of what we now call Elevating Katas . Elevating Katas are introduced as repeatable, structured patterns or routines introduced into an organization’s ways of working that help teams and leaders build new capabilities, improve system-level performance, and “elevate” their overall approach to value delivery. Elevating Katas Identified in the Strobbo's Case Study: Unifying Product Ownership Moving from individual team-based product owners to a more unified product ownership structure. This elevates product strategy and ensures that the product vision is collectively understood, prioritized, and managed. Instead of each team interpreting the product direction in isolation, a unified product ownership model helps maintain strategic coherence and alignment across the entire product landscape. Merging Product Backlogs Instead of multiple, disconnected backlogs, the organization merges them into a single, shared backlog. This structure forces transparency, reduces competing priorities, and keeps all teams focused on the same highest-value opportunities. Similar to the “Merge Product Backlogs” kata, this elevates the entire organization’s workflow by ensuring that work items are consistently prioritized at a product (rather than team) level. Holding Multi-Team Product Backlog Refinement Establishing regular, multi-team product backlog refinement events. During these sessions, all involved teams align their understanding of upcoming work, dependencies, and priorities. This structure ensures that each increment of work is clearly understood and synchronized, preventing silos and misalignments before development starts. Using Obeya for Org Topology Evolution While not explicitly called “Obeya,” the case study implies the use of dedicated forums or physical/virtual spaces where stakeholders (including product owners, coaches, and team representatives) gather to review strategic metrics, progress indicators, and customer feedback. This structure leads to better-informed decisions and quicker action. Over time, these regular strategic gatherings elevate governance and leadership practices. Designing Tailwind Career Paths Encouraging roles to evolve beyond traditional job titles or hierarchical tracks into more fluid, capability-driven pathways. Instead of fixed roles defined by narrow functions, individuals grow in breadth and depth of skill areas aligned with organizational goals. This provides a structure that consistently nudges people towards multi-skilled growth and adaptability. More on Elevating Katas here .

An Org Topologies™ MADE Report 1. Introduction & Engagement Context This paper applies the Org Topologies™ MADE method to analyze and elevate the organizational design of a past engagement in which I served as Scrum Master. The organization, anonymized for confidentiality, is a prominent entity within the automotive sector that created a decentralized data marketplace enabling secure data exchange and data monetization across ecosystem partners. The organization consisted of approximately 20 people, a size well suited for focused, systemic assessment and for exploring alternative org design options without the complexity of large-scale systems. One of the reasons I selected this case is that the organization operated with a high degree of autonomy: leadership empowered the team to propose and experiment with organizational changes. This makes it an excellent context to reflect on org design through the lens of Org Topologies™, even though the engagement occurred before I learned the method. Org Topologies™ is applied retroactively in this paper to map the current (past) ecosystem. assess the structural challenges, design a fit-for-purpose target state, and propose Elevating Katas™ that would guide the organization toward higher adaptability and improved value flow. 2. Business Landscape The organization operates in the automotive sector but is positioned within an emerging digital ecosystem centered around data exchange. Its core business model is built on providing a decentralized data marketplace that enables security, privacy-preserving, and compliant data transactions. Leveraging blockchain technology, the platform ensures transparency, traceability, and trust among participating organizations. 2.1 Strategic Objectives • Establish itself as a premier platform for secure and compliant data exchange. • Drive innovation by enabling access to diverse, high-value datasets. • Scale through a SaaS model to increase adoption and reach. • Support businesses in effectively monetizing their data assets. 2.2 Maturity Stage At the time of the engagement, the platform was in a growth stage, expanding capabilities, user base, and technological robustness. 3. Current Ecosystem (MAP) initial state This section describes the ecosystem during the engagement, following Org Topologies™ mapping practices. 3.1 Existing Organizational Design Functional groups included: General Manager, Marketing, Business Development, Customer Success, Product Management, Engineering Team, Infrastructure Team and Design Team. 3.2 Value Flow (Concept to Cash) Work flowed sequentially across units: Customer Success + Business + Product → Design → Engineering → Infra → Release → Customer Success. 3.3 Lists, Backlogs, and Queues • Product Backlog (including Bugs and Spike) • Sprint Backlog • Design Kanban • Infra Kanban • Release Notes • Marketing Requests 3.4 Org Topologies™ Mapping The mapping showed heavy clustering in CAPS-1 and CAPS-2 archetypes, with PART- 1/PART-2 for leadership and Product. No TASKS-3/TASKS-4 or WHOLE-level archetypes existed. 3.5 Key Observations • High dependency network. • Fragmented Work Mandate. • Centralized decisions around Product. • No end-to-end ownership. 4. Assessment (ASSESS) 4.1 Market for data sharing conditions The market for data sharing and data marketplaces is experiencing significant growth and is shaped by several critical factors: •  Escalating Privacy and Compliance Concerns : Legitimate and widespread privacy concerns, coupled with constantly evolving regulatory requirements (e.g., GDPR, CCPA), make secure and compliant data sharing a complex endeavor. •  Growth of Data Marketplace Platforms : The global data marketplace platform market is projected to grow significantly, from an estimated USD 1.49 billion in 2024 to USD 5.73 billion by 2030, with a CAGR of 25.2%. 4.2 Business Strategy •  Promoting Secure and Compliant Data Sharing : To overcome common data challenges like privacy and security by offering a Web3-powered solution with cutting-edge data security and privacy features. •  Simplifying Enterprise Collaboration : To streamline organization-wide data transactions and foster collaboration across diverse industries and ecosystems. •  Enabling Data Monetization : To facilitate the buying, selling, and monetization of data over the blockchain in a transparent and secure manner, creating new revenue streams for data providers. •  Ensuring Data Sovereignty and Governance : To decentralize data transactions, implement robust role-based governance, and enhance overall data efficiency while ensuring data owners retain control. 4.3 Compared to general competitors •  Traditional Centralized Data Marketplaces (e.g., Snowflake, AWS Data Exchange, Oracle Marketplace): These platforms typically operate with a centralized model, often requiring data to be moved to a single location, which can present privacy and control challenges. This decentralized data marketplace solution's decentralized nature and privacy-preserving computations offer a distinct alternative. •  Other Decentralized Data Marketplaces/Protocols : While this solution is built on existing open source protocol, it stands out as an enterprise-specific, white-label solution with significant corporate backing, differentiating it from more general- purpose decentralized data protocols or smaller projects in the space. 4.5 Summary of Structural Constraints Overall, the ecosystem expressed a classic Resource Topology , this topology does not fit the organization goal because: • The organization operates in a growth-stage digital platform context that requires fast learning cycles and rapid adaptation, while a Resource Topology optimizes for resource efficiency rather than learning and flow. • Narrow Skills Mandate and Work Mandate prevent teams from delivering outcomes end-to-end, increasing dependency chains and slowing value delivery. • Strong functional silos introduce excessive handoffs, coordination overhead, and information loss. • Central coordination around a single Product Owner creates a systemic bottleneck, limiting scalability and decision speed. • Fragmented queues and multiple backlogs delay customer feedback from reaching delivery teams, reducing responsiveness. • Slow Onboarding of New Customers, Fragmented ownership increased onboarding delays, especially if customers need a customize features. 5. Organizational Goal & Fit-for-Purpose Logic (BUSINESS OBJECTIVES) he organization aimed to: - Shorten customer onboarding time, Shorten time-to-market and Reduce the Product Owner bottleneck. The organization selected a fit-for-purpose goal of enabling at least one PART-3 value- stream team to own customer onboarding end-to-end within the next 3–6 months. The other two of the prioritize goals are: • Shorten time-to-market. • Reduce the Product Owner bottleneck. 5.1 Fit-for-Purpose Logic Achieving these goals requires: • End-to-end ownership. • Fewer handoffs. • Broader Skills and Work Mandates. • Distributed refinement. • Cross-functional collaboration. Target ecosystem moves toward PART-2 / PART-3 archetypes with value-stream ownership, representing a shift from a Resource Topology toward an Adaptive Topology . The MAP revealed a narrow Scope of Skills Mandate and Scope of Work Mandate, which kept the organization in CAPS behavior, making the move toward PART-3 essential. 6. Target Org (DESIGN) The following section describes a retrospective target design. It explains how the MADE method and Org Topologies™ could have been applied during the engagement to design a more fit-for-purpose organization. The design represents a plausible outcome of applying MADE, not a historical implementation. 6.1 Target Design Summary Based on the outcomes of the workshop, the organization agreed to reorganize around feature-based team-of-teams , structured by customer value rather than functional specialization. The primary feature streams identified were: • Onboarding Experience • Buying Experience • Selling Experience Each team-of-teams includes: • 1 Product Manager • 1 Product Owner • 1 Designer These teams are supported by shared roles: • Scrum Master • Solution Architect • Business • Customer Success • Infrastructure This target design represents a deliberate movement away from CAPS-1 / CAPS-2 functional clusters toward PART-3 behavior, forming the foundation of an Adaptive Topology by expanding both Scope of Skills Mandate and Scope of Work Mandate. anticipated future state The design intentionally organizes around features and customer journeys rather than functions. The assessment revealed that functional silos, central coordination, and fragmented queues were the primary causes of slow delivery, product bottlenecks, and delayed customer feedback. Key design rationales include: •  Value is delivered through features, not functions . Structuring teams around onboarding, buying, and selling aligns organizational structure with how customers experience value. •  Reduction of Product Owner bottlenecks by embedding Product, Design, and delivery capabilities within each feature team-of-teams. •  Absorbing growth-stage complexity locally , allowing teams to respond to increasing demand, regulatory input, and customer diversity without escalating coordination overhead. •  Scalable design through replication , enabling growth by adding new feature teams rather than increasing central coordination. 6.2 Why This Design Is More Adaptive This target design enables adaptive behavior by changing how decisions are made, how learning occurs, and how work flows through the organization: •  Shorter feedback loops by reducing handoffs between discovery, delivery, and customer interaction. •  Broader local decision-making through PART-3 Work Mandate, allowing teams to prioritize and adapt without centralized approval. •  Lower coordination cost , as most alignment happens within the team-of-teams instead of across functional units. •  Increased learning capacity through direct customer interaction by engineers and designers. •  Fit-for-uncertainty , allowing teams to evolve solutions incrementally in response to market and customer change. In Org Topologies™ terms, the organization shifts optimization from resource utilization to flow, learning, and outcomes, which defines an Adaptive Topology. 6.3 What Is Required to Move Toward End-to-End (Partial) Ownership The target state deliberately aims for end-to-end partial ownership (PART-3) rather than immediate WHOLE ownership. This represents a realistic and sustainable evolution path. Product Manager / Product Owner • Shift from centralized control to shared ownership • Focus on outcome framing and strategic alignment • Enable collaborative prioritization and refinement Engineering • Expand Skills Mandate to include customer understanding • Participate in discovery and refinement Design • Move from a service role to an embedded team member • Collaborate continuously with Product and Engineering • Own user experience outcomes end-to-end Customer Success • Transition from reactive support to proactive co-ownership of customer journeys • Work directly with feature teams to close feedback loops Business • Provide strategic input rather than detailed prescriptions Infrastructure • Serve feature teams rather than operating as a downstream queue • Enable autonomy through platform and tooling Scrum Master / Solution Architect • Focus on flow, alignment, and systemic impediments • Facilitate collaboration across team-of-teams with customer • Support learning 7. Elevation Path (ELEVATE) A set of Elevating Katas™ to move toward the target ecosystem. 7.1 Create Feature-Based Team-of-Teams Establish PART-3 behavior with end-to-end ownership. 7.2 Simplify Lists & Flow Transparency A common shared backlog could be introduced across each feature-based team-of- team. Instead of separate backlogs for Product, Design, Engineering, and Infrastructure, each value stream will work from one unified backlog that contains discovery work, design work, refinement work, delivery work, and release-related tasks. This shared backlog becomes the single source of truth for: •  Prioritization , guided by customer outcomes, onboarding friction, and feature impact. All units could jointly assess value and urgency, which will help to reduce Product Owner bottleneck. Decisions can be made more efficiently, resulting in improved alignment. •  Refinement , Instead of being solely the Product Owner’s responsibility, this could become a cross-functional activity. Teams would build a shared understanding, beyond just creating documentation in JIRA, which leads to better-quality backlog items and a more seamless delivery process. •  Dependencies , It is recommended to make dependencies explicit and visible within the shared backlog, rather than keeping them hidden across functional queues. For example, teams should consider implementing buying-related features before developing sales-related functionalities like a sales dashboard, since the dashboard’s completion relies on the availability of corresponding sales data. •  Customer feedback could be treated as first-hand backlog, not as input filtered through multiple layers. •  Customer Onboarding improvements , It is recommended that onboarding work be elevated from a side initiative to a central component of feature delivery. By prioritizing aspects such as self-deployment, organization setup, and configuration alongside new features, teams could begin to view onboarding as an integral part of their end-to-end responsibilities. This shift would help ensure smoother onboarding experiences and reinforce holistic ownership of the product lifecycle. By consolidating work into one backlog per team-of-team, the organization reduces fragmentation, removes queue-based delays, and strengthens PART-3 end-to-end ownership. Consolidate into single backlog per value stream. 7.3 Expand Work Mandate to End-to-End Move teams from CAPS toward PART-level outcomes. 7.4 Customer-Facing Discovery for Engineers & Designers Faster feedback loops, reduced PO bottleneck. 7.5 Shared Refinement & Distributed Product Thinking Cross-functional refinement increases alignment and quality. 7.6 Empower Teams to Deliver Self-Onboarding Feature A strategic, end-to-end initiative as the first major ownership slice. 7.7 Enable Scalable Growth Scale by role replication within value streams, not functional silos. 8. Conclusion & Practitioner Reflection Applying Org Topologies™ revealed structural issues invisible through Scrum alone. 8.1 Key Learnings • The MAP exposed dependencies, especially the Product Owner bottleneck that Scrum ceremonies do not reveal. • The MAP highlighted slow time-to-market caused by multi-step feedback loops. • It created shared awareness of bottlenecks and aligned teams on next goals. • It revealed that most units were not delivering end-to-end, prompting new conversations on autonomy and empowerment. 8.2 Final Reflection The MADE approach shifted the organization’s perspective from local optimizations to system-level understanding. It demonstrated how structural constraints, not individual performance, were limiting flow, adaptability, and customer outcomes. Org Topologies™ provided the language, visuals, and pathways needed to evolve the organization toward a more scalable, collaborative, and outcome-driven ecosystem.

A story of how a Ukrainian PropTech company redesigned its structure, embraced LeSS principles and built adaptability and resilience amid the challenges of full-scale war. About the Company DIM.RIA is one of the leading Ukrainian PropTech platforms and part of the RIA.com Group, one of the country’s largest digital ecosystems. The product is a real estate marketplace that connects buyers, sellers and agents across both residential and commercial segments. The company’s core value is trust through verified information – its mission is to provide users with only verified, reliable listings, ensuring transparency and confidence in every transaction. Beyond listings, DIM.RIA offers verified property data, valuation tools and digital services that help users make informed decisions. Over the years, it has become one of the most trusted and widely used sources for property search and transactions in Ukraine. At the beginning of 2022, when Russia launched a full-scale invasion of Ukraine, the real estate market faced turbulence. Demand and construction volumes dropped sharply, with many projects suspended or lost due to hostilities. Companies in the sector had to adapt quickly, rethink their business models and stabilize operations amid constant uncertainty and shifting market dynamics. Our organizational transformation took place entirely remotely – online. Because of safety concerns, blackouts and the realities of war, our people were spread across Ukraine and even beyond its borders. Yet, despite the distance and challenges, the teams managed to stay connected, collaborate effectively and drive deep structural change together. This transformation became a living example of how people can unite and overcome extraordinary challenges, even when dispersed across different parts of the world and successfully carry out something as complex as an organizational transformation. Acknowledgements I want to express my deep gratitude to the entire team for believing in this change. You are amazing! Special thanks to Roman Marchenko (Chief Product Officer, Board Member) and Oleksandr Lishchynskyy (Chief Technical Officer, Board Member) for the trust and engagement.   Introduction In the summer of 2024, I joined the team DIM.RIA. At the time, the company employed over 100 people, with approximately 50 working within the product organization. The product team was actively searching for organizational solutions. The main question was: How should we organize our work to achieve better results? The organizational structure had been adjusted multiple times, often in response to shifting definitions of the product. In earlier periods, management had attempted to implement selected elements of the Scrum framework, hoping this would improve team efficiency. As I later heard from team members, they had experienced so many transformations that they joked they could survive one more. But I felt the teams’ fatigue after these words. Because these changes lacked clear direction, addressed only short-term problems and focused on local optimization. Studying the Organization I began exploring the organization by asking management a simple but fundamental question:   “Why does your structure look like this?” The team was divided into three main areas: Sellers, Buyers and Core functionality. ●      The Buyers stream focused on users and product features aimed at people searching for real estate. ●      The Sellers stream, in turn, worked on tools and features for those listing properties. ●      The Core team developed functionality for internal users, such as moderators and internal departments, and was responsible for building shared services, databases and other foundational components. Within each stream, there were managers responsible for specific parts of the product. As a result, each manager had their own list of tasks, prioritized independently. In addition to Product Managers, there were also Project Managers who coordinated team events such as sprint planning, daily scrum and retrospectives. They were responsible for writing task descriptions, documenting requirements and tracking the status of work within each sprint. Each stream also included roles such as a Data Analyst, Designer and Team Lead. Development Teams As for the development teams, they were divided according to clear specializations. Full-stack developers worked on both backend logic and the frontend logic of the web application. Mobile app developers focused exclusively on the mobile application and were not involved in backend development. QA specialists formed a separate team and were primarily responsible for manual testing of anything assigned to them. There was also a dedicated frontend markup specialist who handled web layout tasks. In this setup, specialists were focused strictly on their specific areas of work. However, they often lacked broader context about what was happening in their part of the business. Within each stream, individual specialists worked only on the specific functionality assigned to them. That made it easier to control changes in their part of the product, but limited visibility. Only the Team Leads of each stream had a wider understanding of the overall picture. Design and analytics competencies existed within two of the streams. However, they operated separately from the development teams. Instead of working as part of cross-functional squads, designers and analysts received tasks directly from product managers.   Sprint flow The teams did not have clear sprint goals. Their main focus was simply completing their individual lists of tasks. Before sprint planning, some tasks might have been discussed between individual specialists and a product manager to clarify certain implementation details. But in practice, it was the product/project manager who wrote the requirements and assigned tasks to different specialists for execution. On planning day, each product manager would gather tasks from their own backlog that they wanted to include in the sprint. The stream team would then come together and each manager would take turns assigning work to the developers they were in regular contact with. At the end of the sprint, a presentation was held where managers shared what they had planned for the current and previous sprints, what had been released to users and what was still in progress. Developers did not participate in these presentations at all. This is an example below of how a large feature, intended for all platforms, could end up being developed over multiple sprints due to functional separation and a long chain of handoffs. Not every feature took as long as five sprints to complete, but the same working pattern remained. For instance, the mobile app team couldn’t start their part until the backend work was finished – which often meant waiting until the next sprint to even begin. And in reality, these handoffs rarely went smoothly. Mobile developers would go to the Team Lead or product manager and say that the backend was delivering incorrect data. The managers would then step in to resolve the issues. The organizational design through the Org Topologies These observations gave me a clear understanding of the organization’s setup. Viewed through the Org Topologies the organization clearly matched the Resource Topology archetype. The development teams were positioned at levels TASKS-1 and TASKS-2. So the delivery was fragmented and coordination-heavy because of a lot of hand-offs. At the same time, Product Managers and Team Leads operated at levels PART-1 and PART-2, reflecting their partial ownership of business areas and decision-making responsibilities. A big part of their job was coordination across multiple teams. Teams were not empowered to deliver independently across the full value stream. They were workloaded due to their individual capacity. That’s why the whole delivery flow was based on handoffs. Managers or Team Leads obtained the role of coordinators in this process. This organizational design shows that the structure was built around utilization, driven by a resource-management approach and the splitting of product areas and codebases across different teams or specialists. In practice, the organization was optimized for utilization and coordination, rather than for flexibility and flow. Assessing the organization With this understanding I finally got an answer to my question: “Why does your structure look like this?” and here’s what I concluded: ●      It was a linear decision made as the team started to grow. ●      The structure made it easier to manage developer workloads and assignments. ●      When each developer works only on what they already know, they naturally maintain control over changes in the codebase, and it’s always clear who to talk to if something breaks. This belief reflects a mental model of local ownership and specialization – one that shaped the structure of teams, roles and workflows across the product organization. And it shows how an initial need and a mental model can lead to growing organizational complexity. In our case, streams meant new product functionality. So when the team realized they needed to build something new (for example, a new search or filtering capability), it was treated as a new project. And the belief was that each project needed its own manager to lead it. As a result, adding new streams naturally increased the number of managers and developers, which led to overall team growth. R1: Growth Trap Loop As the team grows, communication becomes more complex, leading to coordination problems and inefficiencies. These problems create pressure on Product Owner, who respond by hiring additional managers to improve control and oversight. But this only increases the size and complexity of the system – feeding back into more communication overhead and more problems. This loop is self-reinforcing and hard to break from within. It feels like you're solving problems by hiring additional managers, but in reality, you're fueling them. R2: Backlog Multiplication Loop As the team scales, more managers are added. Each manager tends to manage their own backlog (due to the mental model of individual responsibility), increasing the number of disconnected lists of work. This increases cognitive load, misalignment and pressure on Product Owners who must now coordinate across more fragmented areas. In response, the organization again hires more managers and the loop continues. Together, these two reinforcing loops created a self-sustaining trap. The more the organization scaled, the more structural and coordination complexity it introduced. Attempts to regain control, by adding more managers and splitting ownership, only deepened the system's inefficiencies. Over time, this created organizational fatigue, misaligned delivery and mounting internal friction, despite the good intentions behind every decision.   Diagnosis Summary The current structure is characterized by handoffs, fragmented ownership and manager-driven coordination. It is optimized for resource allocation and control, rather than for efficiency and value delivery. This design emerged not as a deliberate target, but as a result of well-intentioned decisions aligned with a mental model of individual specialization and responsibility. This structure became self-reinforcing: developers executed assigned tasks, while problem-solving and coordination were handled through managers. The organization, while growing, unintentionally optimized for control – not adaptability or learning. Designing the future organization I presented my observations and conclusions to top management. While the overall reaction was positive, some points were difficult to accept. The biggest insight came when I explained that the goal of the current structure wasn’t efficiency,  it was utilization and resource management. This highlighted that utilization and resource management should not be the primary goal of an organization. Because it didn’t bring benefits anymore. The management realized that simply adding more people wouldn’t lead to greater efficiency or better performance. In fact, it could make things worse. After all those conversations and reflections we back to the familiar question which I mentioned at the beginning: “How should we organize our work to achieve better results?” This is the key question that determines the state of the future organizational design. From the earlier findings and research, I began forming certain hypotheses about the future organizational design. But the answer wasn’t straightforward. So, I wanted to validate my vision. I decided to clarify the organization’s needs. Because understanding those needs shapes how the organization must operate in order to achieve its product goals. My next step was to review the Product Strategy, Product goals and initiate a round of additional conversations with management to clarify the organization’s real needs. As the result of this research, the main organization’s needs were: Focus on what matters most and prioritize according to the overall strategy. Make product decisions based on data and real user needs. Ensure consistent functionality for all users across all platforms. And it was aligned with the LeSS principles: ●      Whole product focus ●      Customer centric ●      Empirical Process Control Comparing the current state and the organization’s needs, the conclusion was obvious: the existing organizational design couldn’t meet those needs. As I mentioned in the first part of this case, the structure was effectively optimized for utilization and control of work and not for adaptability, learning or delivering product value. It was close to my previous hypotheses. But to be honest, I still didn't believe in the idea of LeSS Transformation. Because it looked like  a difficult and complex journey – elevating an organization from component teams to end-to-end feature teams. I wasn’t sure the organization was ready to take on such a huge challenge. As I mentioned earlier, the organization had already gone through many different phases of change and transformation. Because of that, the motivation to make the new round of changes, even if it is more structured, was very low. "Once again, we’ll start changing something, but in the end, it won’t affect anything, and we’ll just go back to how it was," – one of the Team Leads told me. Such a fundamental change should always be about organizational structure. Especially, when the organization's needs are intertwined with LeSS principles. LeSS adoption always required structure changes.   Three Adoption Principles LeSS defines three adoption principles that describe the necessary conditions for organizational change. The first principle "Deep and Narrow over broad and shallow" suggests starting change within clear product boundaries rather than attempting to transform everything at once for reducing risks. The second principle, “Top-down and bottom-up,” states that transformation cannot be driven from only one direction. Leadership must actively support the change and explain its business intent, while teams need to be involved and understand the purpose behind it. This alignment between management intent and team-level ownership requires shifts across the entire operational layer, including how the organization thinks about product development. The last principle, “Use Volunteering,” emphasizes that transformation depends on people who are willing to step forward as change drivers, leading by example and encouraging others to engage. Applying the Three Adoption Principles to our context, the first principle was straightforward. As part of the organizational changes, we needed to focus on a specific area of product development involving about 50 people. According to the second principle, my intention was to work across all levels of the organization, not to create yet another local optimization at the team level. However, the third principle raised some questions. I had strong support from the C-level executives – they were active and deeply engaged in the process. But the teams were still uncertain. They didn’t fully understand what was going to happen or, if changes did occur, where those changes would actually lead. Absorbing all these thoughts, I shared with the management that we should begin with a LeSS Organizational Design training. This training had several goals: Involve people in understanding the current problems we were facing; Educate everyone because it is an important part to help everyone understand why behind the needed change; Check the mood of the team and how LeSS concept would met; Identify volunteers who were motivated to support and lead the change   LeSS Organizational Design training Educating everyone is a difficult challenge especially when we're talking about 50 people. So the decision was to start with the first training group which included: C-level representatives, Head of Product, all Product Managers, Project Managers and Team Leads from development, analytics and design. This group included the key authority figures within the product development organization – those whose understanding and support would be critical for any future change. I started preparing for the training. And then I created a chat in a common workspace to announce this event for this group with all details and agenda. The LeSS training programme: Day 1: Complex domain, Scrum basic, System Thinking, Optimizing Goal, One Product Backlog. Day 2: Scaling, LeSS principles, Team design and capabilities in LeSS setup, Cross-Team Refinement, LeSS Adoption steps. After the full two-day training, we achieved great results. Aligned with the training’s goals, we were able to highlight current organizational problems and explain the dynamics behind the existing structure. Participants gained a deep dive into system modeling, which helped them better understand the underlying patterns and causes within the system. The key insights that were: ●      The existing organizational design optimized for utilization and control of work. ●      We need to define a clear optimization goal. ●      We should move toward a single Product Backlog. ●      We must align around one shared Definition of Done (DoD). ●      We need to rethink team structures and roles. ●      And we must place greater focus on user needs. I was surprised by the level of engagement. People were energized by being involved in discussing challenges across the organization. And they were part of the organizational designing and decision making process. For the first time, they didn’t feel like they were simply receiving instructions from above, they felt like they were co-creating the future of the organization, not just following top-down directives. Almost all 20 persons became drivers of future changes in the company.   And based on training’s insights we created a Transformational Backlog together as a team. The Items in Our Transformational Backlog: ●      Create the Optimization Goal ●      Create a single Product Backlog for the Whole Product ●      Accept the decision about the team structure changes ●      Conduct LeSS training for the engineers ●      Team Design Workshop ●      Accept the DoD for Whole Product ●      Preparing tools for the teams’ online work ●      Conduct Initial PBR (new format) But there were still open questions about Product Backlog, Teams’ Flow. While the training topics were clear and well-received, fully accepting them required a significant mindset shift. It’s important to highlight that this training was not just about introducing the LeSS framework. Honestly, we didn’t focus on terms like “LeSS” or “LeSS Transformation.” Instead, we approached it as a process of organizational design, using systems thinking and LeSS principles to shape the possible future state. But the training wasn’t the end of that process. Over the following 4 months, we prepared for the flip toward a more adaptive organizational structure. During this time, we did a lot of work: discussing, debating and aligning around key topics like the Product Backlog and Team Flow. We were able to carry out comprehensive work on identifying the organization’s needs and conduct high-quality training. This training helped the team gain knowledge in system modeling, new approaches to product development and product management, as well as a deeper understanding of LeSS principles and practices.   Creating the Optimizational Goal This was a particularly difficult step. We were misaligned in our visions and priorities. Despite the training and shared insights, the old mindset was still holding us back from moving forward. I pushed for a focus on adaptability, because it was clearly rooted in our previously defined organizational needs. However, part of the transformation team remained focused on financial goals above all else. In the first iterations, the proposed optimization goal sounded like: "Maximizing company profit through the execution of the product strategy." – with a small note underneath: "One Product Backlog, Cross-Functional Teams." . And nothing about organizational structure. I didn’t like it at all. Over the next few sessions, we focused on creating the Optimization Goal. We returned to the organization’s core needs as the primary source of our direction. I reminded the team of the key insights from the training and the LeSS principles – all of which pointed toward adaptability as our central challenge and aspiration. I reminded them that the current structure was not designed for adaptability. It was built for control, coordination and utilization. That’s why the Optimization Goal had to reflect the real purpose behind the change, not just surface-level improvements. We needed a goal that would unify the organization and guide future design decisions. It defines what the entire system is intended to achieve. Without it the common understanding of changes could be lost. And looking ahead, I can say that the Optimization Goal truly helped us make the right decisions about the future organizational structure. After several sessions of discussing and repeating all that we learned from the training we reached a shared agreement on our Optimization Goal and we all agreed that this is a vision that will help us to elevate our adaptability: To build an organizational structure that enables self-managing development teams to focus on delivering the most valuable functionality for users.   Q&A sessions At this stage, only the volunteer group knew about the upcoming organizational design change. Even after we had completed the training, created the transformation backlog and defined the optimization goal, people still had doubts about the future design. And I understood them, when you start to realize that you’ll have to break a familiar way of working, along with all your established processes and connections, it’s natural to want to take a step back. Although the training helped them see the situation from a different perspective and even inspired them, there was still fear and a feeling that everything might break and get worse. So before moving forward and announcing the change to the entire team, we needed to align among ourselves to present one clear, unified message. The main doubts were about: the Product Backlog, the role of Product Managers, E2E feature teams, Definition of Done and sprint dynamics in the new setup. So we ran a few Q&A sessions discussing these topics. We started with Product Backlog. All work items were stored in Jira, but spread across different projects. Each team: iOS, Android, Web and QA, had its own Jira space with different workflows, statuses and definitions of done. In addition, every manager created their own items in separate projects, maintaining personal lists of work. I reminded them that the Product Backlog should be: ●      A single source of work for all teams ●      Ordered to maximize progress toward the Product Goal. ●      Prioritized by the Product Owner I explained to them what a Product Backlog Item (PBI) is and introduced the concept of vertical slicing. That’s when they realized we would need to create the Product Backlog from scratch. This was disappointing for them, as they already had a large number of requirements in Jira. Now, all of that would have to be merged into a single list and, even more challenging, the specialized tasks could no longer exist. At this point, I felt some resistance which was natural. I refocused them on the Organizational Needs we had discovered together. These needs aligned with Whole Product Focus, Customer, High Value Items Delivery, Customer Feedback. This alignment helped us make the final decision to create a single Product Backlog. Regarding the role of Product Managers, I explained that they were not going anywhere – instead, they would become more involved with the Product Owner’s team. The only condition was that they would no longer have their own separate backlogs to manage. Instead, they would contribute to the single Product Backlog and the overall product work, without being tied to specific teams. The possible New Organizational Design The most interesting discussion was about teams’ flow and teams’ design. They began to challenge the idea of feature teams. Everyone understood the need for change and the reasons behind it, but the transformation team started asking questions and reflecting on possible designs. It was difficult for them to imagine a format where they were no longer tied to specific product areas. Their proposal reflected this concern: keep the separation between Buyers and Sellers, but remove the Core team and distribute its competencies across the two streams. From their perspective, this made sense for two reasons. First, such a design was more familiar to them – they could keep their existing competencies and since the product had both Buyers and Sellers on the platform, developing in these two directions seemed logical. Second, it required less effort, meaning the change could happen faster while globally keeping the structure they were used to. But this was a very fragile moment. I remembered the phrase: “When the structure changes, the behavior changes as well.”  In their proposal, the structure essentially remained the same setup, just with slightly reconfigured teams. I asked them directly: “Why do we need to keep these two directions at all?” For them, the answer was simply that it was familiar. What they couldn’t yet see was how to combine both directions into one Product Backlog and ensure meaningful collaboration between the Product Managers and the teams. I started filtering their vision through the lens of the organization’s needs and pointed out where their proposal didn’t match. Second, I reminded them of what we had agreed during the training: that our product is not about separate streams. By removing those streams, we could increase our adaptability, not by creating work for specific directions, but by exploring user and product problems and solving them with a faster response than we have today. The proposed design still reflected old thinking – distributing work by competencies. This would have required creating new teams whenever new skills or product directions emerged, adding unnecessary complexity to the system. When speed of change was raised as an argument, I challenged it by asking how previous “quick” transformations had truly improved the system. Through these questions, I helped the group shift their perspective from local optimization and short-term fixes toward systemic needs and whole-system functioning. Finally, we agreed that the quick and simpler solution did not meet our needs or align with our optimization goal. Keeping the two product streams would only preserve the system’s existing problems. We chose to make a complete structural shift creating an adaptive and value-driven organization. Involving volunteers, especially team leaders, made it possible to address much of the initial resistance and doubt right from the start. It also allowed us to finalize, together, the shared vision of the future organizational design.   Communication to the whole team After we reached a shared understanding with the volunteer team, we began preparing for a meeting with the entire team to involve them in the current challenges and explain the need for changes. We prepared a presentation in which we talked about: ●      the functions and goals of the current way of working ●      the organization’s needs ●      the main insights from the training ●      the optimization goal ●      our next steps Since the key leaders were already engaged, answering questions and facilitating discussion became much easier. The explanations were coming from people who had been working alongside the team for years and not only from me. The team especially liked the plan. We explained that the preparation phase would last several months and wouldn’t start the day after the meeting. As part of this preparation, we would go through training together and address questions as they arose. This approach gave them the opportunity to feel involved in the process.   Learning Organizational Designing and LeSS Framework with rest of team I remember that a few times the management suggested that maybe we shouldn’t conduct training for the team and instead speed up the implementation of changes. But this is a principle that cannot be violated and it was my main condition – to train everyone. So, I reviewed the structure of the previous training and made some adjustments, adding more emphasis on the principles of working with a single backlog, feature teams and the main events in LeSS. During the training the most discussed topic was E2E team design. It took time to explain to them why the organization needed such kinds of teams. I prepared the frame with types of team design: narrow focused specialists (BE, FE, etc.), multi-functional teams responsible for some functionality, cross-component and cross-functional teams. And asked them to generate pros and cons for every type. We discussed and then I asked, what type is aligned with organizational needs and our CLD. Only a few people said that third type. We stepped back to the Single Product backlog and asked them to explain how the 1st or 2nd type could match. Gradually, they began to see that only the third type could truly support adaptability and whole-product focus. It wasn’t easy for them to shift their thinking, but eventually they agreed. We finished the training with a batch of insights. The team realized their accountability and influence on the product was much greater than they had assumed. They gained an overview of LeSS and system modeling. I especially remember one developer saying afterwards: “Nothing like this has ever happened before, that we are involved in shaping the changes, that our opinions are asked and that problems are discussed so deeply.”   Before team design workshop The LeSS guide recommends running a Team Self-Design Workshop. After our training, we met with the Team Leads to discuss the next steps. When I presented the workshop agenda, they were not comfortable with the idea of letting people select their own teams. Their main argument was that before working with me, they had already gone through several reorganizations that year. By this time, they were only just beginning to settle, build trust and establish working relationships. The idea of reshuffling everyone again felt too disruptive and they were not ready for it. They were ready to agree with some changes to balance all teams with all necessary competencies. I decided to make a compromise and step away from the LeSS recommendation. Looking back, I wouldn’t call it a critical mistake, but it did slow down the pace of knowledge sharing and reduced the initial willingness of teams to take on unfamiliar PBIs. The lesson I learned here: trust the system, not the fear. Because the fear blocks any useful changes. However, it only slowed us down and it didn’t stop us. With every Sprint, teams became increasingly confident in picking up new items outside their comfort zones. The fear of mistakes gradually disappeared, as the new structure encouraged exploration and learning.   Team design workshop We held this workshop online. Ideally, such a session works best when everyone can gather in the same physical space, but due to the war and blackouts in Ukraine, we didn’t have that opportunity. The plan on the workshop were: -       Introducing the team design and setup -       Building the competencies map -       Creating perfection vision -       Define DoD Introducing the team design and setup The team listened to the arguments about the teams’ setup decision. They agreed with the purpose of feature teams and the proposed team composition. Still, there was some nervousness, as it was a completely new experience for them – working together in one team with web, iOS, Android and QA specialists. The next was creating the competencies map. All new teams went to the virtual rooms to discuss their experience, knowledge and skills. When they came back, they were more energized and motivated. This part turned out to be very valuable, they learned a lot about each other and even more importantly, they saw what their teammates wanted to improve and agreed to support each other through knowledge sharing.   Perfection vision On that positive wave we went forward and worked on Perfection Vision. I asked them to imagine the ideal state of engineering practices, product, organization. They wrote down many different ideas of what they wanted to see in their product. These included improving stability, boosting business metrics, increasing technical expertise, enhancing teamwork and much more. I remember them saying that they had never discussed these things together before. Now, they could see just how many great ideas emerged from such a conversation. They also noted how engaged everyone was and how interesting it was to listen to each other. It brought them closer together as a team. Definition of Done At this stage, we spent time discussing the current Definition of Done (DoD). We quickly noticed differences – each team had its own conditions for what counted as completed functionality. We gathered these together and created a shared baseline list called “DoD NOW,” which became our starting point. Then, I asked the teams to think about what they wanted their DoD to look like in the future. I reminded them of the perfection vision and gave them time to work in groups. Afterwards, we shared the results and voted on which items were both realistic and important. This became our improvement list “DoD 2.0” and we agreed it would be our collective focus for next improvement.     The end of the workshop We did a great job that day. The teams left with a stronger sense of ownership and mutual trust. For many it was the first time they had open discussion about vision, product, their impact and how they could support each other across roles and platforms. This created energy, motivation and a shared belief that change was not only possible, but also within their influence. We closed the session with clarity that we would build a structure capable of delivering end-to-end product value. But I made a huge mistake that affected us later. At the time, I didn’t realize how critical it would be. I overlooked key competencies such as design and analytics, which should have been embedded within the teams. I will describe this in more detail later.   Product Backlog Creation After the Q&A sessions about the Product Backlog I mentioned earlier, the PO and Product Managers organized themselves into a working group. Their main task was to create a transparent list of high-value items that weren’t sliced into narrow technical tasks. From there, we began prioritizing the Product Backlog in alignment with the Product Goals. By the end, we could finally see what really mattered most and this clarity allowed us to identify the highest-value PBIs to bring into the Initial PBR.   Initial PBR The LeSS guide recommends that the Initial PBR last for two full days. In our case, we spent three days refining PBIs. We worked through a large scope, refining everything in the backlog several sprints ahead. Looking back, I can say this wasn’t necessary. Refining just two sprints ahead would have been enough. At the time, we did it because we had the false feeling that it would make things easier, and because we didn’t yet understand our delivery rhythm and actual capabilities. We started with the product strategy and the main product goals. The PO emphasized what was most important for the product, how the product needed to evolve, what steps we had to take and which metrics we would focus on. This stage helped broaden the teams’ understanding of expectations and impact. Previously, teams, and even individuals, were used to working only within their own parts of the product. Now it became clear that the boundaries were wider. Teams began asking questions about the product and its goals. This was something completely new compared to what I had seen during planning meetings in the old structure. Then we moved on to presenting the PBIs, where the PO together with the PMs briefly explained the context of each item. The teams paid close attention, asking the PMs clarifying questions such as which platforms a particular feature should be implemented on. It was fascinating to watch, because in the past teams would receive tasks already split by platform. Now the teams themselves were seeking clarification. After walking through the backlog, I asked the teams to split into small groups to refine backlog items. We ran several rounds of multi-team PBR. After each round, I suggested giving short feedback. After the first round, it was clear that people were not yet generating solutions as much as they were learning with the parts of the product functionality. For many, this was entirely new knowledge. Within the groups, more experienced specialists in specific areas explained to others how the systems worked. Round by round, we kept moving forward, building up more and more shared knowledge. I remembered the doubts teams had voiced during the LeSS training, when they questioned the point of feature teams: “How will I work with the backend and discuss tasks if I don’t know the backend?” And then I watched them in practice – a backend developer sitting with iOS and Android developers, figuring out the API logic together. In another group, developers explained to a PM how the current search logic on the website worked and suggested possible implementation options. Other group members were present, listening, asking questions and learning new functionality themselves. The next day we continued our work. Together, we defined the greatest value we needed to deliver in the upcoming Sprint and identified the most high-priority PBIs. Then I asked the teams to meet separately, review those PBIs and decide which work they could take on. After that, we ran team-level PBRs so they could prepare more deeply for the Sprint. At the end of the day, we gathered again to summarize the results of our work over the past days. The teams felt a strong sense of responsibility and didn’t want to make mistakes. They were eager to understand the PBIs thoroughly, so they asked to dedicate one more day to learning and refining them. From my experience, I knew they would not be able to break everything down to the smallest details or prepare perfectly for the Sprint, but I decided to support their initiative. For me, it was a positive signal that they were engaged and making decisions within the process. Sprint Planning After all 3 days of Initial PBR we gathered on the Sprint Planning. As the teams had already chosen their PBIs, we started with Sprint Goals. The PO stated the main focus and then we reviewed the PBIs once more to ensure they aligned with the goal. Next we clarified dependencies among the PBIs and lack of knowledge among the teams. And there teams agreed about coordination and consulting each other during the sprint. And then we took time that teams go and planned their work, define their sprint goals and observe their scopes of sprint to finalize all. After that, we all gathered to finalize the Sprint goals and the work for the Sprint.   Sprint Goal This was our first experience in defining a Sprint Goal. Even with all the available recommendations, it doesn’t mean you can immediately do it well. But it is important to start, and to improve gradually. To define a Sprint Goal, you need to answer the question: What exactly do we want to invest this sprint in? Or What specifically should change in our product after this Sprint and why? These questions point the way toward creating the right kind of goal. Around them, the team can start practicing setting goals, even if at first they are not very clear or perfect. It is a practice that helps build product thinking within the team. However, it is important to avoid goals that are too abstract or technical, such as: “complete all tasks”  or “deliver tasks to testing.”   Closing Sprint Planning When we finished planning, the teams still felt nervous. For them, this was a completely new way of working. They didn’t yet know their real capabilities, how the new setup would function, what problems might arise or how to solve them along the way. So I reminded them that for some time we would simply be adapting and experimenting with this new format. I emphasized the importance of sharing feedback, because that would help us move through this phase faster. Despite their concerns, they wanted to try. Compared to all the previous transformations they had experienced, this time felt different.   We did it online The main challenge in our journey was that we were doing all of this during the full-scale war in Ukraine. We had no possibility to gather together physically, as the team was spread across Ukraine and around the world. So everything had to be done remotely, using online tools. Despite all recommendations to work on such changes in one physical space, for us it simply wasn’t possible. Even under these conditions, we managed to carry out comprehensive preparation work entirely online, following LeSS guides and principles, and it worked. We: ●      educated everyone ●      involved the volunteers ●      created a single Product Backlog ●      created 3 feature teams capable of taking on any PBI from the Product Backlog ●      did the initial pbr ●      planned the sprint Through this experience, I can say that the real strength lies in the team. When people truly care about their product, are willing to make it better, act as ambassadors of change and open to experimentation, then even being far apart, in the difficult conditions of today, teams are capable of making big transformations. From an organizational dynamics perspective, the challenge was even greater: questioning an entire way of working that had been built over years, and then shifting to a completely new structure within just 4 months. It was, in fact, a stress test for the entire organization. And I am deeply proud of the people I worked with to make this possible. I believe I was fortunate to have this team. LeSS Organizational design Making the flip is a major event for any organization. It represents the moment when it dares to challenge its familiar way of working and rethink itself. However, at this stage, it is very difficult to evaluate whether these changes will actually lead to the expected results. The teams move forward mostly on belief and adrenaline, as the familiar structure they were used to no longer exists. I can say that when an organization makes the flip, that’s when everything actually begins. The entire preparation process took us about four months. However, I believe that if an organizational change has the highest priority and strong management involvement, this preparation phase can be completed in a shorter time. Still, speed should not be the key criterion in a transformation process. It’s better to invest more time in preparation, discussions and involving people, so that the organization truly understands the necessity and embraces the idea of change. That’s why it’s important not to rush – just to be faster. Here is how the new structure looked compared to the previous one. It clearly illustrates the reduction of complexity and the descaling effect that emerged after the transformation. Multiple fragmented backlogs and component-based teams were replaced by a single Product Backlog and three cross-functional feature teams capable of working across the whole product. Teams dynamic at the beginning The first two Sprints were not very representative in terms of evaluating the results of the new way of working. During that time, there were several staffing changes unrelated to the transformation itself and it also coincided with the vacation period. Therefore, we can say that the beginning of 2025 became the point when we could truly start assessing the impact of the changes. However, even in the first Sprints, the teams began to notice significant changes in their work dynamics. The full responsibility for managing and organizing their work had now shifted to them. The teams started independently organizing their Daily Scrums, resolving development issues and coordinating their work. Managers, who previously facilitated meetings or made technical decisions instead of engineers, were no longer involved in these processes. This happened due to several factors: ●      Team design.  Each team consisted of 8-9 engineers, which significantly simplified communication and interaction – both during team meetings and in day-to-day work. ●      Sprint Goals.  The teams now set their own Sprint Goals and were fully responsible for achieving them. Consequently, they also took ownership of resolving all questions and challenges related to reaching those goals. This simplified interaction and helped the teams become more autonomous and they liked it much more than in the previous structure. Now, within their own teams, they discussed progress directly, shared information openly and highlighted where support was needed. The teams also started communicating directly with other teams whenever necessary, which significantly accelerated problem-solving. They no longer had to wait for a manager to find time to gather everyone and lead the discussion. It was a small, but meaningful victory that built confidence and trust that the changes were truly making things better.   Product Backlog A single Product Backlog for the entire product was something completely new for the organization. It started to create a shared understanding of what was truly important for the product. In practice, it became the single source of work for all teams – the place that answered the question: “Where is the product heading?”.  Over time, this shared understanding continued to improve. We created an end-to-end backlog that included PBIs from various product initiatives. The Product Managers, acting as subject matter experts (SMEs), met regularly with the PO to keep it up to date and to define priorities together. Structurally, it looked like this: But there were several problems. The first issue we began to notice was decomposition or rather, the lack of it. In the first Sprints, neither the managers nor the teams had yet developed an understanding of iterative development. As a result, the PBIs brought to PBR sessions were mostly clarified and discussed from an implementation point of view, but not broken down further. The teams then took several of these large PBIs into the Sprint and were unable to turn them into a ready Increment by the end of it. The teams were finishing their work on these items by the end of the Sprint, usually at the testing stage, at best. For several consecutive Sprints, the situation didn’t improve. Working through this together with the teams, we identified that this was a clear violation of our Definition of Done. If we look at this moment in terms of metrics, the Sprint Task Completion Rate was around 45–55%, while the Sprint Goal Completion Rate was about 40%. To address the issue, we agreed on the following steps: ●      During PBR, teams should decompose any PBI that is too large to complete within one Sprint. ●      Reduce the number of PBIs brought for discussion during PBR.Gradually decrease the number of PBIs planned per team for each Sprint. ●      Ensure that everyone understands and adheres to the DoD so that each Increment meets it fully. At the next PBR, I began by explaining what decomposition and iterative development mean. I suggested we try decomposing a PBI using a real example, so everyone could understand both the process and the expected outcome. This small workshop helped everyone understand how decomposition really works. It also helped us manage expectations within Sprints more effectively. Managers and teams began to see the concept of “customer value” differently. They realized that value can be increased iteratively step by step by gathering feedback from users along the way. This was very different from the way they used to work before.   Product Backlog Refinement PBR has become an integral part of the teams’ work and learning. It is thanks to multi-team PBR that we maintain knowledge sharing across teams, which greatly improves understanding of both the product development context and the engineering context. This is especially important considering that, in the past, developers worked only on separate parts of the product. In my opinion, this is one of the most essential elements for increasing adaptability, as the teams are no longer limited by knowledge of a single functional area – instead, they explore PBIs together and develop higher-quality solutions. Multi-team PBR also helped us anticipate potential blockers and dependencies before the work even started. This made it possible to plan actions that would help resolve these issues ahead of time or manage them more effectively during development. In practice, it improved overall team coordination.   Multi-team PBR facilitation Under the conditions of the full-scale war in Ukraine, all teams work primarily online. Tools such as Miro, Mural and Confluence whiteboards help us create a shared virtual workspace for team collaboration. A day before each PBR, we meet with the PO and PMs to review and update the backlog, and we prepare the virtual board for the upcoming session. We start each PBR with the PO presenting the upcoming priorities,  explaining why they are important and which of them are most likely to enter the next Sprint. We briefly go through the PBIs to provide the teams with context. After that, the teams organize themselves into mixed groups and move to virtual breakout rooms to discuss the proposed PBIs. Usually, we divide into three groups. During the session, each group completes three rounds, rotating between rooms so that everyone has a chance to work with all PBIs. At the end of the session, we finalize the results of the PBR and determine which PBIs are ready for planning and which still require additional work. For those not yet ready, the teams agree to refine them individually, either because they are interested in taking them into the next Sprint or because they want to explore them further and later share their findings with everyone. The teams quickly began to see the value of PBR. At first, this format seemed complex to them, but now they want to understand as much of the broader product context as possible. It’s also important to note that PBR has shifted the focus from simply analyzing tasks assigned by managers to enabling teams to propose their own solutions to product problems. It is expanding organizational agility and domain knowledge among engineers. Sprint Planning We start with a short alignment session where the Product Owner, together with Product Managers, reviews the Product Backlog one more time to finalize expectations for the upcoming Sprint. At the same time, teams meet in their virtual rooms to synchronize and update their context. They review their boards, check if there’s any remaining work from the previous Sprint that could influence the next one and briefly revisit outcomes from the last retrospective to incorporate improvements into the new Sprint. Next, we all come together for a joint session. Each team gives a short update on whether they still have unfinished work or if there’s anything that needs to be added to the planning scope. Then, the PO shares overall expectations for the Sprint and walks everyone through the backlog. After that, teams split again to analyze the expectations and backlog items and to decide which work they want to take on. They mark potential items directly in the backlog. Once all teams have done this, we review the selections together to identify overlaps, for example, when two teams have marked the same item and agree on ownership. Each team then holds its own Sprint Planning session, where they define their Sprint Goal, create a plan and identify dependencies and interactions with other teams. At the end, we come together again for a short Sprint summary, where we align on Sprint Goals, team scopes, open questions and then officially start the Sprint.   Story Points experiment Over time, we decided to run an experiment with estimation. Previously, teams estimated work in hours. This approach caused a lot of frustration and it didn’t provide any real guarantee that tasks would be completed on time and it was almost impossible to predict how many productive hours each engineer would actually have during the Sprint. Most importantly, it reinforced an old pattern of individual estimation and task assignment, where work was distributed per person rather than owned by the team. Following old patterns also affected Sprint results. In the first few Sprints, teams still had unfinished work and often failed to achieve the Sprint Goal. I believed this was happening because the teams were not yet acting as a single unit and each person still held their own context and estimates around tasks and maintained an individual focus rather than a shared one. I suggested trying Story Points instead. I know there’s a lot of criticism around this approach, but in our case, the reasoning was very specific. The goal wasn’t to measure velocity – it was to break the pattern of individual focus and to encourage shared team understanding of the work. The hypothesis was simple: if teams start estimating together, they will communicate more, share knowledge and better understand how to achieve the Sprint Goal collectively. And that’s exactly what happened. Through Planning Poker, teams began to discuss implementation details, ask clarifying questions and uncover hidden assumptions. I believe this is the true purpose of Story Points is not to measure precision, but to help teams talk, think and plan together to find the best possible solution. If you face a similar situation or believe this approach could be useful in your context, be ready to sell the experiment to the team. My proposal was not just about changing the estimation technique, it was about solving a specific problem. I started by clearly explaining the goal of the experiment, the problem we wanted to address and my proposed decision – to try Story Points. Then I described what Story Points actually are, how they work and how we would implement them together. This framing was important. When teams understand why a change is happening and what problem it solves, they are much more likely to engage, experiment and make the approach their own. As a result, this experiment became one of the elements that helped us improve delivery stability. It wasn’t the Story Points themselves that made the difference, but the shared understanding, communication and team alignment they encouraged. At the same time, I wouldn’t recommend using Story Points just because “Agile teams are supposed to estimate this way”. They are not a universal solution – their value depends on why and how you use them. In our case, Story Points worked because they solved a specific problem and helped the teams grow together, not because they were part of some agile rulebook.   Sprint Review A major change for the organization was the introduction of the Sprint Review. Before the structural transformation, there was already something similar, it was called a Sprint Results Demonstration. The mechanics were quite simple: managers prepared slides showing what they had planned for their teams, what had been released during the Sprint (which could include functionality started in earlier Sprints), and then, during the meeting, they presented this information slide by slide. When I asked the questions, “Why aren’t the teams doing this?” and “What is the value of this meeting?” I received the following answers: ●      “Should the teams really be doing this? It’s the managers who manage the tasks.” ●      “To share progress on these tasks.” There were no conclusions, feedback or discussions during this meeting. In fact, the manager simply reported on “their” tasks. When it came time to prepare for the Sprint Review, the teams began asking why they needed to do it themselves. The main concerns among the teams were about preparation and presentation. It was clear that they were reluctant to invest their time and effort into it. They perceived it as additional work, something they hadn’t been responsible for before. For them, it felt like extra effort and new responsibility, because in their minds, this had always been the managerʼs job. So, I decided to remind them once again of the purpose of the Sprint Review and to explain what the teams’ responsibility truly means. The purpose of the Sprint Review is to inspect the Sprint results and gather feedback on the created Increment in order to define further changes to the product. This event creates a shared context among all interested roles. The teams are the owners of the Increment because they are the ones who built it during the Sprint. Therefore, they should be the ones explaining and demonstrating it. Preparing for the Review also builds a sense of responsibility and self-organization – helping teams realize that they are not just executors but the true owners of the result. According to this, the teams agreed with this experiment and took the responsibility for preparing the increment. We also agreed that the teams would prepare for it by themselves, deciding how they wanted to present and inspect the developed Increment and would be active participants in the discussions. Also, we aligned on the structure for the Sprint Review: ●      The Sprint Review begins with the PO giving an opening message, highlighting the main focus areas. ●      Next, the PO briefly reviews the key product metrics and provides short comments on their dynamics. ●      After that, the teams take the stage one by one. Each team talks about its Sprint goal and demonstrates how the new Increment works. At the end of each demonstration, the team leaves time for questions, feedback and discussion. It might seem like nothing particularly significant had happened — the teams simply started taking an active part in the Sprint Review. But here are a few of my observations on how this change actually influenced the teams. This change had a strong impact on setting clearer expectations. Now it was not the manager showing some results, it was the team that created the Increment within the Sprint and was responsible for it. This, in turn, influenced how teams began to perceive and relate to the Sprint outcome. There was now a clear Sprint Goal and clear expectations. This significantly increased the level of ownership and accountability. As a result, the teams started approaching PBR, Sprint Planning and the upcoming Increment much more consciously. PO team dynamic As I mentioned at previous parts, the system before changes had been built around the idea that Product Managers divided the product into separate areas and directions. Each PM was responsible for their own part and was expected to deliver results and report on progress. Consequently, they had their own individual goals that they wanted to achieve. In practice, this prevented the product from evolving in a unified direction, as each PM was focused on pushing forward their own initiatives. Each manager was mainly interested in ensuring that their tasks were taken into development. As a result, planning meetings brought together component teams and managers. Each manager would present their tasks and, together with the Team Lead, decide which developer would take on which task and how many. In the end, every developer had a list of tasks for the next two weeks, and the manager coordinated their execution. From the very beginning, during our training on organizational modeling, we explored the roles of the PO and PM, and how collaboration between the PO, PMs and Teams should work. The key idea that managers needed to accept was that they no longer had to push their own tasks into development or compete for resources. Their role remained important – they continued to support the PO in developing the product, but they were no longer responsible for coordinating teams or managing events. Most importantly, all future work now flowed through a single Product Backlog. This created some difficulties at the beginning. Each manager still remained an expert in their specific part of the product and continued working within that area, preparing corresponding PBIs. Naturally, each of them wanted their items to be taken into development –  otherwise, they felt they were losing their sense of importance and contribution. The PO was the one who made the final decision on where to invest the next Sprint’s effort. Not everyone liked this change, but we followed the principle of “job safety over role safety.” It was also important for them to understand that situations where a manager explored a direction and their findings were not immediately taken into discussion or included in the next Sprint were completely normal. We focused on what was important for the product, not on how many tasks a manager could prepare or plan for the team. However, not all managers fully accepted this new reality and over time, some decided to leave the company. For those who stayed, there was a period when they felt somewhat disconnected from the teams. They were no longer facilitating team meetings, solving development issues, or coordinating daily work. However, this was the right direction for them – it allowed them to focus more on product research and development. The teams themselves began to approach the managers whenever they needed support or expertise.   Expanding engineering competencies One of the most rewarding observations was how deeply engineers embraced the idea of sharing product knowledge and developing new competencies. A great example of this was the initiative to spread app testing expertise across teams. Due to several staffing changes, the number of dedicated testers was significantly reduced, which made this skill set critical. Our Engineering Manager, together with internal experts from the teams, designed a practical training course on testing. They developed a learning plan and, over several Sprints, conducted sessions to teach and mentor developers and other testers on the testing practices used within the company. This initiative greatly helped to spread testing knowledge, reduce bottlenecks and strengthen the teams’ autonomy. And helped to support the quality of the product on the level. Now there is no fear or resistance to testing work – it’s no longer seen as “someone else’s responsibility”. Teams understand that quality is a shared responsibility and that mindset has become part of our culture. This was a beautiful example of mature self-organization showing how a culture of shared responsibility and learning can spread organically across teams, without being enforced from outside. Definition of Done When it comes to the Definition of Done (DoD), we initially gave it little attention. We defined a basic version at the start, but over time teams began to follow it only partially. Such an attitude can easily lead to a gradual decline in quality, especially as the organization scales. A Sprint Increment must always meet the Definition of Done. If the DoD is unclear, incomplete, or inconsistently applied, it creates invisible debt: unfinished work, untested code and technical uncertainty that accumulates over time. Without a shared and enforced DoD, the meaning of “Done” becomes subjective and predictability and quality quickly erode. Over time, we returned to review our DoD again. The engineers agreed that we needed to adhere to it consistently and improve it together. This led to new, clearer items that became mandatory for all teams. We are now working to ensure that every team has the capability to meet these standards so that each Sprint delivers a true, high-quality Increment. As a result of this reflection, we created a plan that includes developing new skills within the teams. This clearly demonstrates how the Definition of Done directly drives development of engineers capabilities and continuous improvement. I highly recommend establishing a clear Definition of Done. Define what activities it includes, how DoD can be measured and how the organization will support it Sprint by Sprint.   Results and Organizational Impact In conclusion, I’d like to share some concrete results. Many people in the industry often ask – why are such organizational changes even necessary and what do they actually bring to the business? There’s a fair amount of skepticism in the market about these kinds of transformations. And I didn’t want to answer with something abstract like: “It’s a complex systemic process with many influencing factors, but overall it’s a better way of working because it aligns the organization around a single source of work and puts the customer at the center.”Those words are true, but they still don’t answer the real question: did it actually make a difference? I chose a few tools to evaluate the success of the changes: key metrics and the Org Topologies mapping. The main metrics I tracked were Cycle Time, Throughput and Sprint Goal Completion Rate. These are simple indicators that help observe how the system is changing. ●      Cycle Time showed how quickly we could turn started work into usable outcomes. ●      Throughput helped us see the stability and predictability of delivery. ●      Sprint Goal Completion Rate reflected how well the teams understood priorities, planned their work and delivered on what they committed to. These metrics were easy for everyone to understand and discuss, which made them a great entry point for learning and reflection. They also served as signals of whether our changes were really improving the system or just shifting the symptoms. After seven months of operating in the new LeSS structure, the impact on key flow metrics was striking. Cycle Time across all three teams decreased by around 80%, meaning Sprint Backlog items were completed roughly five times faster than before. This reflected the removal of systemic delays and smoother collaboration across the teams. Throughput remained stable, even though Work in Progress was reduced by approximately 60%. Previously, teams tended to start more work than they could complete, which led to interruptions, dependencies and items getting stuck in progress. With the new structure, teams focused sharply on their Sprint Goals and committed only to the amount of work they could realistically complete to achieve those goals. This resulted in a much more stable and predictable flow of work. As a result, Sprint Goal achievement rose from around 40% to over 90%, demonstrating stronger alignment between planning, execution, and outcomes – a clear indicator of improved system coherence and team maturity. These outcomes were not merely the result of improved metrics. By simplifying the structure, reducing handovers and fostering true cross-team collaboration, the organization created conditions for faster learning and more consistent delivery of value. This systemic improvement also translated into financial impact. In this case the organizational changes did not have a negative impact on financial performance, as is often feared.   Observing New Org Design The second important insight emerged when I looked at the new structure through the lens of Org Topologies. As described earlier in the Designing the Future Organization section, the LeSS structure was meant to help the organization become more adaptive. From an Org Topologies perspective, such a structure ideally sits in the top-right quadrant. That was our target state. So what did we actually achieve? We ended up with three cross-functional, cross-component feature teams capable of taking any item from the Product Backlog and delivering it to “Done.” In principle, this meant that each team could work across the whole product. Product Managers acted as subject-matter experts, supporting the Product Owner in shaping the product strategy and aligning the backlog with business goals. Structurally, this seemed like a good step toward adaptiveness. However, I made a significant mistake during the team design phase. While focusing on building end-to-end feature teams, I concentrated mostly on engineering capabilities: backend, frontend, mobile, QA, and didn’t fully consider non-engineering but critical competencies, such as design and analytics. Design and analytics were essential to our product development process, yet they remained outside the teams – organized as separate functional departments, each with their own leads and allocation model. These departments provided their services to teams but were not part of them. At first, this seemed acceptable: teams could pick any backlog item and deliver it end-to-end as long as the design and analytics work had already been done. But this dependency became more visible over time. From the Org Topologies perspective, this revealed a clear misalignment between intent and reality. The teams had indeed moved up the vertical axis – their scope of work expanded to cover the whole product. But horizontally, their scope of skills was still incomplete. They were multi-skilled, but not truly end-to-end. Missing design and analytics capabilities meant that teams couldn’t independently close the full loop of problem discovery, solution definition and delivery. As a result, the organization unintentionally remained in a Resource Topology. Despite having feature teams, the flow of value was still dependent on centralized design and analytics functions. The teams’ behavior reflected this dependency: instead of continuously discovering and solving product problems, they focused on delivering the highest-priority items that already had design and analytical input. When that input wasn’t ready, teams couldn’t start the work – which in turn affected flow and planning. The Org Topologies assessment made this visible. It showed that even with substantial effort and structural redesign, we had reached only partial adaptiveness. This realization was eye-opening and valuable. It showed that organizational adaptiveness is not achieved merely by forming cross-functional engineer competencies. It requires integrating all critical skills into the system of value delivery. Engineering alone cannot ensure adaptiveness if discovery, design and analytics remain external. Org Topologies helped visualize this gap and turn it into a clear direction for the next evolution step: expanding team capabilities to cover the full product cycle, from insight to impact. Reflection In this part, I share some reflections and key lessons from this transformation experience. Engagement of top management shapes how the entire system perceives change. Executives must be present, participate in discussions, attend training sessions and clearly explain, from a business perspective, why the transformation matters and which problems it aims to solve. Their active involvement sends a strong signal across the organization: this is not another local optimization, but a strategic shift in how the company operates and creates value. Leadership participation builds trust, aligns intent with action, and helps the organization see the change as meaningful and long-term. So, top management has to be in the center of these changes. You must have a mandate for change Any transformation requires a clear and legitimate mandate for change. Without it, even well-intentioned efforts quickly meet resistance, as existing structures and incentives naturally protect the status quo. A strong mandate creates the necessary space for experimentation, enables decision-making without constant escalation and provides the psychological safety for people to challenge established ways of working.   Organizational Design Is More Than Delivery According to the Galbraith Star Model, organizational design is built around the alignment of five elements: strategy, structure, processes, people and rewards. Strategy is a core input for shaping the organization. Reflecting on this experience, I realized that structure and processes cannot evolve in isolation. Even with adaptive teams, stable delivery and growing revenue, success is not guaranteed if the product strategy and decision-making practices remain weak. It is important to keep it consistent. Product strategy and feedback loop are the most important parts of product development. It’s crucial to avoid a situation where any initiative can slip into the backlog simply because someone wants it. There has to be a clear filter that evaluates how each initiative aligns with the strategy and contributes to the product goals. That’s why the product dimension of the organization must evolve as well, including how we define and work with product strategy, make data-driven decisions, validate hypotheses and strengthen the overall product mindset. The focus should be on the whole system, not only on the delivery part. Before starting organizational design changes, it’s worth running several sessions to align on the product strategy, analyze how decisions are made and how hypotheses are validated. Such discussions can expand awareness, improve preparation for the “flip” and help identify missing capabilities in product research and validation practices. This reflection led me to an important realization: preparing for transformation means not only getting engineers and teams ready, but also developing the product side of the organization, helping product managers and leaders learn how to explore, test and make product decisions in new ways, and enabling engineering teams to contribute to this process as equal partners.   Track Product Metrics Organizational design should ultimately help the company achieve its product goals, not only improve internal efficiency. That’s why it’s important to track how structural and process changes affect the key product indicators. Connecting organizational changes to product metrics helps ensure that transformation delivers not just better delivery, but real business impact.   Be Confident One of the most important lessons I learned is to stay confident. When facilitating a transformation of this scale, the whole system will often push back, especially at the beginning. Not everyone shares the same understanding of why change is needed; some people will resist it and a few may even try to actively sabotage it. If you start doubting yourself, compromising on principles or skipping essential parts of the LeSS preparation process, it’s unlikely you’ll be able to bring real value to the organization. Such compromises often lead to mistakes that will have to be fixed later. If you keep old roles, processes or structures “just for now,” be sure that you’re also scaling old problems into the new organization. Confidence in principles and clarity of intent are what allow the transformation to stay meaningful and effective.   Design the System, Then Follow It Follow the conditions of the system you create. When transitioning to LeSS or any other adaptive model, elements of the old structure will remain. These remnants of the previous system can silently undermine new principles if allowed to dictate the rules. It is therefore crucial to continuously identify and eliminate contradictions, aligning the organization with the principles of the new design. LeSS is not just Scrum at scale; it is an organizational transformation that demands systems thinking and ongoing adaptation. Only when all elements – strategy, structure, people, processes and culture operate in harmony with the new model does the system truly come to life and begin delivering real value.

Company Context The company is a mid-market regulated services provider. Distribution is primarily direct-to-consumer via digital marketing and contact centres, supported by partnerships. The operating environment combines strict conduct and data-privacy obligations (incl. GDPR) with high-volume, compliance-sensitive sales and servicing. Technology spans a core account-administration platform, third-party vendor systems, and growing public-cloud analytics and marketing tooling. The workforce numbers in the mid-hundreds, spread across product, engineering, operations, marketing, compliance, and customer support. The company states publicly that it competes on trust, service quality, and speed of change while maintaining rigorous controls. The reality at the start of our engagement was quite different. An extremely complicated project management approach, combined with a fragmented and divisive organizational structure, generates significant overhead, high defect rates, and rework, impacting business operations, revenue, brand reputation, and team morale. Insufficient focus on system health, lack of integration with modern tools and technologies, and gaps in best practices have led to escalating technical debt, increased security risks, and the diversion of engineering resources from innovation and value-driven work to maintenance tasks. On the bright side, team members experience strong support from both peers and leadership. Despite extremely high levels of technical debt, aggressive fixed-date/fixed-scope deliveries are consistently achieved, albeit at great cost to the health of both the technology and people within the organisation. Deadlines are committed to without a full understanding of the scope. Initial Technology Context There are three technology departments within the broader organisation: The primary focus is “TL,” a ~90-person product & development org split into two value streams—Customer Acquisition & Sales and Policy Servicing & Payments—supported by shared platform/cloud (DevOps, DBA, InfoSec), data/QA, and follow-the-sun tech-services/app support, distributed across the UK, North America, and APAC. TL’s CTO is a seasoned product-and-technology executive with multiple exits who scales mid-market companies and builds high-performing global teams. The CTO was one of the first Certified Scrum Coaches in the world (prior to the CTC/CEC split), but is totally framework agnostic. He has a very strong distaste for “cargo-cult Scrum/Agile” and has no desire to blindly apply any framework, terminology, tools, or processes without a deep, first-principles understanding. We are jointly focused on also making the requisite People, Reward, Structure, and Strategy changes. I have known the CTO personally for over 17 years, and deeply respect, admire, and trust their leadership. I was hired by the CTO two months after they joined the company having followed them for a 2nd time from a prior engagement. TL works regularly with two other departments on fixed-date, fixed-scope projects: ●      TB: A marketing- and content-centric technology organisation. Approximately 50 people, of which several are either front-end developers or testers. Geographically distributed across English-speaking countries in Europe and North America. ●      DW: A several-person cross-functional Data & Analytics group—spanning data engineering, data science, and Power BI development—led by a Head of Data and supporting finance/actuarial and business reporting. Geographically distributed across English-speaking countries in Europe and APAC. The CTO’s primary goal is to accelerate business growth by reaching the elite performance levels of the top 10% of organisations. The evidence that we rely on indicate that elite teams are twice as likely to exceed profitability, market share and productivity goals and capture 50% higher market cap growth over 3 years when compared to less mature organizations. Initial “TL” Context through the Org Topologies / Star Model Lens Strategy ●      The dominant strategy, despite an external “speed of change” focus, was to optimise for Resource Utilisation, Cost Efficiency, Output Predictability (in that scope was expanding but dates could not change), Compliance, Confidentiality, and—in a sense—Specialist Expertise either due to a perceived “waste” of multi-learning and/or lack of time to cross-train. Structure The organisation structure strongly indicated a Resource Topology: ●      There were three large development “teams.” Although the teams were initially described as multi-skilled (TASKS-2) teams, they behaved more like pools of individuals operating as TASKS-1 (Y0/Y1). ●      A DBA acting as in a TASKS-1 viewed as operating on a “conveyor belt,” with minimal integration with dev workflows. Further, infrastructure tasks were often handled separately, lacking dedicated sprint capacity for improvements. Database changes were often bottlenecked by a single-person dependency (TASKS-1 Y0). ●      System ownership was described as “so fragmented that no one truly owns any part, hindering the development of expertise, quick issue resolution, and the implementation of robust solutions,” again reinforcing a TASKS-1 Y0/Y1 archetype selection. ●      There was considerable role overlap and confusion: ○      Inexperienced and untrained Scrum Masters acting as weak facilitators organising status updates as pseudo-Project Managers at best. ○      Technical Product Owners were unclear in purpose, and it was uncertain what they contributed. ○      Some managers had part-time availability or uncertain responsibilities. ●      The effective structure was so fragmented that some teams mentioned not knowing who was on which team or how the organization was structured. This suggested a very poor understanding of the TL PART of the business let alone the broader company’s structure. ●      Groups were distributed across multiple, broad time zones struggled with limited overlapping hours, further compounding communication challenges. People ●      Nobody in the organisation had any  significant Agile training of any kind, including the “Scrum Masters” who were simply re-badged PMI-like Project Managers. ●      “Technical Product Owners” lacked relevant skills and it was unclear what value they brought to the organisation. ●      Business Analysts had no effective product authority: they were given ambiguous/increasing scope and forced to make it work against hard deadlines. Rewards The Reward structures strongly indicated a Resource Topology: ●      Career ladders, when present, were poorly designed and reflected the progression of single-skill specialities, not broad multi-learning. Domain knowledge was not rewarded. ●      Some noted they feel supported, while others felt overworked and/or uncertain about constantly changing priorities. ●      Repeated “crunch mode,” weekend work, and genuinely unyielding deadlines caused stress and burnout. ●      Some employees expressed frustration at being stuck in reactive tasks with minimal chance to apply creative solutions. ●      Some employees mentioned wanting more opportunities to innovate, experiment with new tech, or participate in hackathons. ●      Despite this, people often described a friendly, collaborative culture with “minimal egos or friction,” which I’ve found to be true; the senior leadership is both deeply intelligent and humble enough to recognise novel ideas if they are well-supported by data and evidence. Process Given the organisation's Strategy, Structure, People, and Rewards, it was no wonder that the Process reflected a “Agile in name only” environment: ●      Large projects were planned in detail by CAPS-1 ( possibly  PART-1) Project Managers in consultation with other CAPS-1 individuals in other departments, sometimes other companies (such as service providers). Waterfall-like practices dominated large projects, with extensive upfront requirements and big release bundles, necessary given the Resource Topology and many cross-team, department, and company dependencies. These were managed with 500+ line Microsoft Project plans. Mid-project scope changes inevitably occured without the possibility of adjusting timelines, forcing teams into last-minute rushes that compromised quality and team member well-being. ●      Work was frequently assigned (“push”) to individuals with often siloed knowledge of technical systems, rather than self-organized or pulled by whole teams, reinforcing TASK-1 patterns. As a result, Sprint Planning was all about filling Sprints with tasks rather than focusing on outcomes or user value, reinforcing a TASKS- level Scope of Work selection. ●      Daily stand-ups often had 30+ invitees, often turning into monologues or large status calls rather than collaborative problem-solving. There was minimal interactive discussion. ●      There was not a consistent pattern of well-facilitated Retrospectives, reinforcing a Resource Topology diagnosis; individual “doers” were not expected to contribute meaningfully to continuous improvement. ●      Due to requirements being handled—at best—by isolated CAPS-1 (possibly PART-1) individuals and groups within the department (more often outside of the department and even outside of the company), the delivery of requirements was completely unmoored from the development process. This resulted in requirements arriving well into the time-bound development window, frequently too late for effective QC and integration planning. QC individuals and groups complained of unclear and shifting requirements, resulting minimal time available to develop comprehensive coverage. ●      Velocity was sometimes recorded but frequently overshadowed by urgent KTLO/BAU tasks, defects, and other mid-Sprint additions, making the data effectively useless for planning. Tooling (Process sub-set) ●      The department used Jira but it was poorly tended to. Issues in Jira were generally not correctly statused, resulting in virtually zero situational awareness as to the broader systemic picture. Jira issues often detailed granular tasks (“create a stored procedure”) without context of larger goals. Jira tickets had priorities (e.g., “Highest”) without a documented prioritization framework; teams often react to “fires,” hotfixes, or immediate tasks. Worse, much work was also tracked in Excel and Word documents being emailed around, creating even more fragmented tracking and version contention. ○      As a result of the above, it was not understood just how understaffed the department was (service rate) relative to the demand (arrival rate). Terminology (Process sub-set) ●      Owing likely to prior shallow “Agile transformations,” inconsistent usage of “agile language” (stand-ups, sprints) led to cynicism about developing real agility. This is entirely consistent and to be expected given the entrenched, poorly-trained Scrum Masters with PMI-only backgrounds and the like applying only the terminology from Scrum (e.g., Larman’s 2nd Law). ○      This is to say nothing of senior leadership, who—while extremely intelligent, well- trained, well-meaning, and competent in their operations—were naïve to adaptive org design principles within a technology context. Thus, they were unable to recognise the limitations of—let alone change—any of the organisation design beyond terminology and team-specific processes. Technical Health ●      Environments were confusing, with separate pipelines for UI, services, and DB further suggesting a siloed, top-down, resource topology. ●      Strong architecture diagrams and environment details were not understood or rewarded, and thus were inconsistently documented. ●      Industry-standard DORA metrics were not being collected, though the organization clearly operated at a low maturity level. A proprietary assessment developed by the CTO and I also revealed a low-moderate maturity level at best. ●      Quality-related metrics (e.g., defect escape rate) existed but were not consistently acted upon. A high volume of production issues and urgent tasks consistently disrupted planned Sprint work, which still continues until today. ○      Personally, I have seen more P0/P1 level incidents at this company than virtually the entire balance of my career combined . The CTO’s Immediate Interventions The CTO joined the company a couple of months before I could follow him. I was able to provide ad-hoc coaching in the meantime, including introducing him to Org Topologies. I had not previously been successful introducing LeSS due to his rightful distaste of any “Agile framework,” but Org Topologies spoke to him quite clearly. He remarked “I wish I had my name on this.” In the interim, based on our prior work together and their existing knowledge of adaptive software development, the CTO quickly: ●      Divided the three large TASKS-1 (Y1) teams into several CAPS-2 teams organised under two value streams. ●      Created clear “enabling groups” for IT (Cloud & Infrastructure, follow-the-sun Application Support, and similar services) and Platform (e.g., web/service/DB upgrades, logging/monitoring, test automation, etc), largely TASKS-1 and TASKS-2 teams. ●      Terminated the Technical Product Owner roles. ●      Terminated the Scrum Master roles in consultation with me (otherwise they would have reported to me). ●      Brought me on as the company’s Enterprise Performance Coach. ●      Implemented the first version of the “Minimum Viable Bureaucracy" (hereafter MVB) I wrote over our prior two engagements together. My Immediate Interventions When I joined, I assisted the CTO by: ●      Significantly updating the MVB, with the following mandate: “a razor-sharp, adaptive system that tames complexity, fuels global collaboration, and unleashes rapid innovation. The result? Hyper-growth, high-impact execution, and unstoppable team … embracing complexity science [Cynefin], a focus on adaptiveness over short-term efficiency [Larman], designing the organisational structure to influence culture [Lean/Larman], and minimise “wasteful” overhead that doesn’t bring value to end users [Lean].” I also wove in Org Topologies concepts throughout the document. ○      This was a major rewrite from prior versions that did not fully embrace LeSS-like approaches. ○      Given that it was a large document and growing, I borrowed a “fractal” writing technique from architect Christopher Alexander’s book “ The Timeless Way of Building ” that allowed for three depths of reading: descriptive headings, short summaries, and detailed information. ○      I invested heavily in both teaching and mentoring teams and leaders alike on this MVB, starting with first principles. ●      Began mentoring his direct reports for 30 minutes each week and providing fortnightly 50-minute developmental coaching sessions. ●      Sunsetted the use of Jira within the TL department and replaced it with Shortcut, a simpler tool with many fewer anti-patterns and fewer degrees of potentially self-destructive freedom. We started clean in Shortcut and did not automate any data migration from Jira. ○      From day 1, I aggressively maintained data quality in Shortcut through spot mentoring and reporting. ●      Interviewed new Product and UX leaders. ●      Customised and implemented a Bug Prioritisation and Resolution Framework that followed these principles: ○      A good process will have different people with the same information get to the same decisions most of the time. ○      High importance Bugs are quickly handled. ○      Low importance Bugs don’t derail high-value initiatives. ●      Customised and implemented a P0/P1 incident management and after action review process based on my experience developing an incident management process at PagerDuty. ●      We considered the idea of a parallel organisation following Larman’s advice, but given the size of our department and the broader organisational context, we found it to be a non-starter. First Topology Iteration Strategy Make initial moves away from Resource Topology to a Delivery Topology in the context of a high-pressure (demand ~3.7x capacity), high-stakes environment at the organisation’s maximum sustainable state of change. Structure ●      We eliminated the TPO and Scrum Master roles entirely. ●      We hired a particularly skilful Product Manager and UX Researcher to join our team. ●      We renamed existing BAs as SPMs (“Software Product Managers”) to help indicate a shift in role expectations. ●      We chose two “Value Stream Owners” to act as LeSS-like APOs, with the CTO and CMO jointly acting as the Overall Product Owner. ●      We began to create cross-functional teams through a vendor in APAC. ●      The CTO is represented as a multi-skill individual at PART-2, along with myself as the coach. Rewards Our career ladders have been considerably improved: ●      Much more articulation of the expectations for an individual to be at any given level, resulting in more fairness and predictability. ●      Reduction of various specialised developer roles to a single Engineering role supported by (for now) a separate Cloud&DevOps track. ●      Analysis replaced with Product Management expectations. ●      Considerations for how these roles would leverage generative AI. Process ●      The “Minimum Viable Bureaucracy” process is mostly being followed, with the exception of regularly-scheduled department-wide retrospectives and Iteration Reviews. ○      High manager demand coupled with time-zone difficulty makes department-wide retrospectives challenging, but we do use after action reviews at major milestones. ○      Our process is still a fairly deterministic project approach on largely well-understood work (replications of product launches), so there is less demand and capacity for iterative software development. As our People and Structure evolve, we expect to use Reviews each iteration. Limitations We acknowledge that there are still many significant limitations with this topology: ●      Value streams and “enabling groups.” While we understand the long-term risks of creating single-product value streams that run the risk of delivering marginal-value features (e.g., the “Google cat paw” Easter egg), this shift from TASKS-1/-2 (Y0-Y1) archetypes to CAPS-2 was a bold “next adjacent possible,” especially with the limited time budget available to implement broader multi-learning patterns. ●      DevOps as a separate function.  I recognise from my time at PagerDuty that “DevOps” doesn’t mean an external team doing operations, because that’s basically the exact opposite of the portmanteau “ dev elopers doing op eration s .” We do not presently have either the time to support DevOps skill development with our current development team due to extreme fixed-date, unknown-but-increasing scope pressures. We do not have the budget to augment all teams with skillful DevOps mentors, however we did hire a very skilful VP that both the CTO and I have known for many years who will assist us in upskilling our teams. ●      Platform and Cloud & Infrastructure teams   as a separate function.  Here too, we do not have either the time to support multi-learning nor the budget to add additional subject matter experts to our teams at the moment, but we have been surprised to discover a lower-than-expected volume of dependencies on these capabilities. Our primary delivery teams are arguably CAPS-2+, not fully end-to-end on all work but capable of doing most  value delivery on their own. ●      We have too many BAs acting as extremely junior “Software Product Managers” (“SPMs”) and our Value Stream Owners have neither the authority nor the expertise to fully succeed in their roles.  As a result, our CMO and CTO are managing most higher-order prioritisation, with VSOs and SPMs filling in some of the gaps. As the SPMs spent the majority of their careers as order takers from “the business” and do not have strategic product development experience, they’ve needed a substantial degree of hand-holding. We have, however, avoided the trap of creating “team output owners,” with SPMs acting as SMEs for projects (a BA-type function) rather than allow them to locally priortise individual team backlogs as their primary objective. The SPMs also spend a non-trivial amount of time providing unrelated operational support to other departments. Second Topology Iteration (current work) We are now aggressively expanding with the support of an outsourcing company in APAC with whom the CTO has a long relationship. We treat them as staff augmentation and require them to follow our organisational design. Structure The next gesture will be to continue developing skills within the Value Streams by: ●      Hiring enough people with high-value skills (e.g., DBA) to join the Value Streams and travel/enable within the Value Stream. For instance, we now have one skilful DBA supporting all work across the Department. We are planning on hiring one DBA per Value Stream to travel to Feature Teams within the Value Stream when necessary to support their work hands-on in the short-term and build DBA skills within the team in the long-term. This is represented by the shift of the team-of-teams from CAPS-2 to CAPS-3 and the dissolution of the separate DBA-specific backlog. ●      Hiring and developing Software Product Managers to be more multi-skill, especially when it comes to AI-assisted prototyping. This is represented by the shift of the SPM pool from CAPS-1 to CAPS-2. Arguably this would be the first expression of a Delivery Topology: Backlogs We are also promoting the use of “one backlog” across the entire organisation, not just within TL. This is manifested through custom reporting that I’ve developed on top of our story management software. In truth there are dozens of backlogs, all in the following hierarchy: Department → Value Stream / Enabling Group → Capability → Team These are represented in the backlog names: Across these backlogs, we are aiming for the following blend of backlog items (called “Stories” by our tooling). Across these backlogs, we are aiming for the following blend of backlog items (called “Stories” by our tooling). We track this in our reporting tooling today: This is presently a far cry from our ideal case: most of the requirements live on team-level backlogs, suggesting that our expression remains closer to a Resource or Delivery Topology rather than a Driving one. Third Topology Iteration (Planned) As we continue to grow our department and help our people develop software more quickly and iteratively, we anticipate that stakeholders outside of our department will take an increased interest in collaborative software development. We anticipate an evolution from a Delivery Topology to a Driving Topology. Some outstanding questions: ●      At what level will detailed, synchronous planning occur? ●      Will we be able to federate this by independent Value Streams (fewer teams needing to coordinate planning at once reduces time zone pain), or will we need to continue department-wide planning? ●      How do we address the fact that we have developers in the Americas, EU, and APAC? Sophisticated Reporting Informs Action The above demonstrates a reasonable understanding of Org Topologies and application in practice, especially given the 2-month window provided for complimentary certification following the courses. However, I believe my proprietary work suggests a deep understanding of the principles and provides evidence to support the value of multi-learning. Thanks to high data quality within Shortcut, we are track detailed metrics for each level in the hierarchy, including: ●      Pts/iter (adj) : Adjusted story points completed per iteration (each iteration is a two-week/fortnight sprint, aligned across the department). This metric reflects net delivery capacity after subtracting unplanned work. Points represent relative complexity, uncertainty, and effort rather than time. ●      CV % (Coefficient of Variation) : Measures plannable delivery consistency across iterations using the weighted velocity model. Lower values indicate predictability. A CV above 20% indicates volatile delivery and reduces confidence in ETAs. ●      Unplan % : Percentage of completed work that was not planned in the iteration commitment. Higher values reduce available capacity for strategic, roadmap-aligned work and increase delivery risk. ●      WIP/Builder : Average number of stories in progress per builder. Because each builder has finite focus, higher WIP increases context switching, lowers flow efficiency, and leads to slower delivery. ●      Unest % : Percentage of backlog stories without point estimates. This directly reduces forecast accuracy, as points are the unit of capacity planning and flow measurement. ●      Queue Length : Estimated time to clear the backlog at current velocity. The value shown depends on forecast mode: ○      Operational Mode (P70–P95) – realistic range (practically P50–P90 today), ○      Aspirational (P50–P85) – optimistic (practically P25–P75 once we get more mature), ○      Raw mathematical P50 – median only (but empirically closer to P10 today in reality due to right-skewed delivery). ●      Avg. Story Size:  Average story points per item, indicating team slicing discipline. Large averages can signal overly complex work items or estimation drift. ●      Stories:  Total number of incomplete backlog items, representing work inventory that has not yet been delivered. ●      Points:  Total estimated story points remaining in the backlog. This is the aggregate volume of work still to be completed, expressed in the same relative complexity units used to measure capacity. ●      Pts/wk:  Adjusted velocity converted into story points per week, normalizing for the two-week iteration length so teams can be compared and long-range forecasts can be made on a weekly basis. ●      Pts/yr:  Projected delivery volume over a full year at the current velocity, using the decayed weighted average model. This informs portfolio capacity planning and budgeting. ●      Pts/iter (raw):  Gross story points completed per iteration before subtracting unplanned work. Shows total throughput, but overstates capacity available for strategic work. ●      Included Iterations:  The number (or range) of past completed iterations used to calculate velocity and CV. Velocity uses a 13-iteration window (approximately six months) with exponential decay (0.9 weighting), meaning more recent iterations have greater influence. Because we track these metrics at all levels of our hierarchy, we can leverage them to illustrate the benefit of improving our org design to be less TASK- and CAP-centric, and more PART- and even WHOLE-centric. How? Consider the following table of data for selected Teams , Capabilities , Value Stream , Department , and the Whole . Here, we’ll focus on the Pts/iter(adj), CV %, and Queue Length in particular. Examine the team TL:PL:Policy Management:1 , which has been operating since week 17, 2025. Their raw points/iteration is 25.3 points/iteration, but 25% of their completed work was not “planned” for at the beginning of the iteration or pulled in with extra capacity, so their adjusted points/iteration is 18.8. They’ve got 1960 points in their backlog, so we would expect that to be done in just over 4 years (1960 / 18.8 = 104 iterations, or just over 4 years assuming 25 iterations/year). However, the high CV of 59% places the P70 queue length at 9 years, and nearly 20 years at P95. This is clearly indicative of a problem. TL:PL:Policy Management:2  joined from APAC in week 29, 2025. Although they have less Unplanned work (only 17%), they’re still ramping up as evidenced by the high CV of 72%. Here, the 30 points in the backlog should take 4 iterations at 7.5 plannable points per iteration, but the high CV% pushes out that queue length to 3-4 months at P70-P95. At the moment, TL:PL:Policy Management:2   is on the cusp of being able to work on everything that TL:PL:Policy Management:1 does. Once that materialises, we would move almost all of the work from the TL:PL:Policy Management:1   and   TL:PL:Policy Management:2   Team  backlogs to a newly created TL:PL:Policy Management  Capability backlog (only implied as a level today as evidenced by the parentheticals around “TL:PL:Policy Management”). We’d still maintain the Team-level backlogs: work moves here at Sprint Planning 1 (to use the LeSS term) and a small amount of team-specific work (such as team-specific Retrospective action items) could live here as well. This is how we can maintain our team-specific metrics (for now). Note, however, that we don’t have to move the work yet to start to see the potential benefits; this report provides a projection. Nobody would be surprised by the increased plannable velocity for the capability of 26.3: just the sum of the two team’s plannable velocities of 18.8 and 7.5. The real surprise on this metrics table comes from the CV% and queue length. Notice that with the addition of the second team, the P70-P95 queue length drops to 5.7–11.7 years. Still not ideal by any stretch, but a considerable improvement over 9–19.7! Note that this isn’t improved only due to the better velocity, but also due to the lower CV% . This shows the adaptiveness benefits that occur from moving from a TASKS-/CAPS- borderline level towards a CAPS-/PART- borderline level. We have four levels of hierarchy within our department so there is not an exact mapping to Org Topologies, but the overall concept is still consistent. What happens if multi-learning continues? We’d go from the Capability  level to the Value Stream  level. Here again the entire Value Stream’s queue length goes down not only due to the increased plannable velocity, but also due to the reduced CV! What might have taken 9-19.7 years for the TL:PL:Policy Management:1  Team on their own can be done in 3.4–6 years with the entire TL:PL  Value Stream participating, which also includes everything else (~30% more scope) the Value Stream plans to do! ( We could argue that the Value Stream planning level sits somewhere between CAP- and PART- in Org Topologies terminology.) Of course, this can be further expanded to the TL Department. I’ve not shown other Value Streams , Capabilities , or Teams within TL , but note here how the CV improves even further, which drops the Queue Lengths even further, despite including the scope from the other hidden backlogs within this department. This spills into other reporting, too. We’re familiar with LeSS’s illustration of multiple vs single backlog value as follows: I am experimenting with a version of my reporting that can capture per-Story cost-of-delay and uses that to show differences in value delivery based on the organisational design. However, it is possible to simplify this a bit conceptually: Notice how items are ranked 1-10, with 1 being most valuable. The left illustrates a Team-level backlog, with most items on the left team and items 2, 4, and 10 on the right team. In this case, item 10 will be done in Iteration 3, before higher-ranked items 6-9. It is done 2 iterations earlier in the Team case than the Capability case. More generally, whenever the Team ETA is before the Capability ETA (or the Capability ETA is before the Value Stream ETA  and so on ), this means that lower-value work is being prioritised before higher-value work. We can now combine the impact of these metrics into detailed forecasts! Please note this row in another table. Here’s what we can ascertain: ●      This is Rank 171 in the global backlog view. ●      There are 170 undone stories in front of this one, including 3 that are ≥13 points. ●      This story belongs to TL:PL:Policy Management:1 and their P70|P95 Team ETAs  are 17-22 November . There is a ⚠️ icon here and the tool tip warns: “⚠️ Local optimisation—value loss likely. Ships earlier if taken by this Team, but a shared Capability backlog would deliver more total value first.” ●      Notice that the Cap. ETAs are 30 Nov – 10 Dec  and the VS ETA  is 8–18 December . Here too, there is a warning on the Cap. ETA . Here are the tool tips for each of the ETAs for the same Story illustrating the reporting’s “intelligence” and usefulness as a teacher: Going back the other way, here’s a Story on an Epic: Note that with the current Team ETA, we’re looking at late Jan to mid-March 2026. If TL:CSO:Workflows:1 completes multi-learning and they can collaborate on a single TL:CSO:Workflows Capability backlog with the TL:CSO:Workflows:2 team, we should expect this to be delivered 1–2 months sooner. If there were complete multi-learning across the entire Value Stream, we’d see this Story completed 2–3-½ sooner. This report allows anyone to filter for any Label, Backlog/Team, Epic, IDs, or requester, allowing everyone in the org to get an approximate ETA with the data known to us today without needing to understand velocity, etc. Put another way, I’ve designed tooling that coaches teams and leaders on the impact of their organisational design on delivery. I’ve done this for large requirements, too. Here’s a report for an “Epic,” which Shortcut casts similarly to other tools like Jira (large requirement, not sortable on the same backlog as Stories, mostly a project metaphor). Notice that I can give P50-P95 estimates based on whether or not we have multi-learning: Team (no multi-learning), Capability (~CAPability-specific multi-learning), or Value Stream (~PART-wide multi-learning). I can illustrate—mathematically, adjusted with classical statistics—how value would be delivered weeks earlier. Suppose my cost of delay for this Epic is $500K/week. Assuming we are going from no-multi-learning (Team ETA) to capability-specific multi-learning (Cap. ETA) and we are using the P85 dates, I can show an approximate $1.25M value in obtaining capability-specific multi-learning for this project alone  as it is forecast to deliver about 2-1/2 weeks earlier with that structure! Epic: [Redacted] Progress:  115/150 Stories, 355/470.8 Points (75%) across 10 Teams Completion Forecasts by Organizational Level Completion dates show the maximum ETA across all epic/label stories at each organizational level. VS ETA reflects the longest-pole story among all Value Stream teams, Cap. ETA among Capability teams, and Team ETA among individual teams. Shows opportunity cost of team boundaries. Backlog Distribution Written By Chris Gangé

A story about a company called VUCA-Energy that is trying to survive in the VUCA-World. Introduction Imagine regionally regulated, fast-paced markets in an environment to be conquered. driven by bleeding-edge technologies and lots of financial potential. One of those fields is the energy market. While the economy has to keep running, the climate catastrophe has to be stopped. Hence, a shift towards renewable energy is unavoidable. The ability To support the green shift and obtain profits from it is key to success. This is the field where VUCA-Energy (VUCA-E), a ~250-employee company, is trying to leave a mark and to be a leader in energy trading, stationary battery storage, and vehicle-to-grid (V2G) integration (VGI). Striving and surviving are highly dependent on the ability to seamlessly Change direction while having a crystal-clear vision reinforced by a guiding strategy. The The following image is a high-level view. Now that we know the surroundings of VUCA-E, let’s have a look at the initial situation roughly ~3 years ago, with a focus on the VGI area. To do so, we want to apply the Org Topologies language and map the Product & Tech business areas of VUCA-E. We want to see how VUCA-E has evolved over the last years. For each relevant state, we map and analyze the business before we finally elevate towards a fully adaptive organization—a reasonable match for the VUCA world. Initial Situation The company is not a fresh start-up. The company's organizational structure has undergone several changes. We start our reflection and analysis of VUCA-E's environment from the phase when its Relevance and competencies have been proven to their investors. By that time, multiple functional departments staffed with domain experts grew and siloed away from one another: The VGI area started as a small research team that built a prototype to prove if the idea of combining VGI with energy trading is technically feasible. That was the case, and the euphoria from investors' support imposed fast decision-making and ignorance of modern concepts in org design, setting focus on the enhancement of expertise. The “classical Scaling, in terms of specialist teams, was applied (based on bad mental models). This way, multiple component-based tech teams have been set up. In addition, outsourced web and app development is shielded away from the rest of the organization to cover missing competencies within VUCA-E (2023). The Product Management and Technology Areas within VGI appeared to coexist as separate departments. Was it working well? The headcount rose and reached 350 employees. A common vision and mission have been defined, but they were too vague and did not provide a unifying effect to the employees. Teams were not practicing alignment with each other because they did not feel a need. An organization based on a narrow consideration of business parts and “Natural growth” emerged, which represents the classical directing archetype; see Image 2. Image 2: Mess of the initial setup: too many roles, dependencies and bottlenecks, burning investor’s money Spinning VUCA world The VUCA world did what it does best—it took some unexpected turns, and in essence The market did not grow as expected. Since the company was very much divided on the structural and goals level, it struggled to generate valuable outcomes and the financial Numbers dropped while the headcount reached its peak. That was when the investors decided to hold back yet another round of investment until the numbers improved. We could call this “the Big Bang,” which should have been a wakeup call, only that we are not there yet. The management did what managers do in crisis: they hired an external consultancy and raised the need for clear responsibilities of each component and task, and defined single wringable necks. External consultants promoted the management’s ideas and introduced a matrix organization with a clear hierarchy. In the tech area, they created multiple siloed sales channels with strictly attached tech teams. The business Development and product managers continued to function as a separate body, mostly passing tasks to the tech area. Ah, and as the numbers needed to get better, one-third of the employees had to be let go. Intermediate Situation VUCA-E ended up in an intermediate state where those external consultants created an organizational design supposedly optimized to convince investors, yet insufficient to handle the challenges ahead. You could call it fit for investors, yet not fit for purpose. In a nutshell, VUCA-E evolved into the following setup (mapped on Image 3): Business development separated away from product, separated away from tech. Each department with its own management team ~7 sales channels driven by people with individual interests (Project Managers— PMs) 3 “agile” Scrum teams in tech strictly assigned to 3 sales channels Exclusive team of architects to elaborate and drive a target architecture The infrastructure team to establish an infrastructure layer The security team is making sure the company complies with security standards Domain/component owners responsible for the functionality and cleanliness of their components, who were members of the Scrum teams. The component Owners mainly defined the type of tasks a dev team would pick up (CAPS-3). The Scrum Masters warned the management that this organizational design is not sustainable in a VUCA world and predicted what would happen, but they have been ignored. (Self-) Education in the field of org design seemed to be unnecessary for the management because all problems come from bad workers and a tough business environment, where VUCA-E has chosen to operate. Image 3: Teams are aligned with sales channels, so the scope of work is limited to capabilities, yet the first signs of cross-functionality and end-to-end skills emerged! Dotted lines illustrate reporting lines, while solid lines illustrate working collaboration. Challenges and problems in the intermediate situation ... created by the “solution” the external consultants came up with. The five elements of The Galbraith star model was not aligned in this org design. Besides that, the following issues arose: Lack of unified goals Misaligned goals for each sales stream (sales KPI) Deadline-driven project work No companywide strategy Siloization & knowledge drain Separation of Tech & BD & Product Experienced colleagues leaving or being let go Lack of adaptiveness and difficulty shifting priorities Bad mood & poor motivation Colleagues were laid off Management decisions were questioned Uncertainty within the organization Management & investors & people-pleasing Team Leads Top-down decisions Old-fashioned management style Bottlenecks—generated through the following specialist teams: Architects Infrastructure team Security team Owners With the specialist teams, a lot of dependencies with massive alignment needs have been created. To make it worse, the tasks and responsibilities of these teams were described as fuzzy. As a result, for some topics, it was unclear who was responsible, and the ping-pong between teams began. Single wringable necks could not solve the problem, because Setting individual responsibility per topic does not enable the creation of complete solutions. It only causes communication overhead, delays, and a potential conflict of interest. Management and external consultants could not take a holistic and analytical approach to really solve the problems VUCA-E was facing. The result of the re-Org was ... yet Another reorganization after 3 months because the VUCA world did what it does best—it took some unexpected turns. How did it impact the organization? The sales-streams with strictly assigned development teams could not serve VUCA-E's needs any longer because priorities shifted to other sales-streams that did not have any development resources at that point in time (still CAPS-3). Current Situation Bearing in mind that VUCA-E had a reorganization only 3 months ago, it would most likely be deadly to the employees’ morale if everything had to be fully reshaped again. Hence, the strict assignment of Developers to sales streams was lifted so that they can deliver end-to-end for whatever sales channel needs it the most: this org design is mapped on Image 4. The ability to deliver end-to-end for any sales channel included a steep learning curve, but with the right mindset, openness, and courage, this was possible in most situations. Yet the current situation is still insufficient when it comes to switching costs. Each Team has its own product person assigned to it with its own interests. A vision, mission, and clear goal setting could help to move in the same direction, but as each sales stream has its own goals, each stream tries to work on its goals first, instead of driving the overall company's mission. Consequently, the different sales channels must “fight for resources to get into implementation. Teams that have worked once with a sales channel are very likely to continue working there. In addition, specialist roles such as, e.g., architects further cemented the drift towards a delivery topology where teams act as feature factories implementing predefined and specified tasks. This leads to the following: problems: Limited learning—"masked" ownership of sales channels, once there, always there Local optimizations—teams deliver, yet what they deliver is not always globally relevant value Specialization—specialist roles have a high reward; generalists are not promoted Siloization—a sales channel becomes a silo Issues with ownership—no product ownership and fear of expanding ownership on tech side (collective ownership is not lived). High switching costs—a result of the sum of the above—and a new priority kicked in again and needs immediate support, imposing a reduction of scope and delayed delivery of other commitments. Given the fact that VUCA-E was forced to switch direction more than once and under tremendous switching costs, it is safe to say that an adaptive topology should be the target topology. The past has proven the In VUCA-E’s business, a delivery topology is not fit for purpose. Image 4: Organization around several business parts—elevating towards a delivery topology Future Vision VUCA-E must be ready to conquer the vehicle-grid-integration sector of the energy market as soon as the growth kicks in and the land-grabbing starts. Other companies have massive advantages when it comes to financial resources and manpower. A potential Technological advantage can be gone in the blink of an eye. Building a technological foundation organized in a delivery topology creates a false impression of doing the right thing. thing, because “hey, we deliver,” but as soon as the run starts, it will be too late to switch the organizational topology because the costs will be too high and the speed too slow. Hence, the VUCA_E’s future vision is optimized for adaptiveness with low switching costs, minimal transaction costs, and a clear vision that gives direction across all departments. Time to … … MADElevate towards the Future Vision Have a single empowered Product Owner (PO) who is accountable for the whole product, a vehicle-grid-integration platform. The PO will get all the support needed from the subject. matter experts (SME) and product managers (PM). Not only will they support the PO PO, but they will also align business development and partnerships while driving the vision of the VGI platform. The software engineers organize as teams that cover partial businesses or more (PART-3/PART-4). They do not only develop software, but they help form the product and have close contact with real customer problems that they solve. Goodbye to the times when they got handed over wannabe user stories every two weeks. Expert roles are no longer a bottleneck by design because they simply get integrated into the teams where they will be a huge benefit with little onboarding time. By that hand-offs are reduced, and a shared understanding of the platform is created. To develop the best product, the teams and SMEs and PO must work together closely; PO, see Image 4. In the long run the company could even elevate further and break the borders of the departments introduced in Image 1. This would mean that all departments, namely Trading, VGI, and Stationary have a shared vision and VUCA-E is organized with a holistic product view, where software engineers are real product developers working on the whole business (WHOLE-3/WHOLE-4). Image 5: PO as a senior role with decision power, cross-functional teams with integrated experts like architects, traders, data scientists A case study by Irina Muhkha, Joschka Rinke, and Manfred Slaucher

I am here to save jobs for our children. Here is the video of Craig Larman speaking at LeSS Conference 2025 with a full transcript below. "This is my new professional mission for perhaps the next 10 or 20 years. And you can, those of you who have been at the previous conferences with me understand my motivation for this and our grandchildren. I have grandchildren. So my thesis is I've shared each year in these keynotes since 2020. That within a few years, maybe by the, maybe by October, 2027, we'll see news of the first job category that's been meaningfully replaced by an AI. I think that could be possible within two years. I've got a sister and a daughter who work in the film industry and you should see what's happening there. Things that currently take 1000 - 2000 people to do a production it's just, dramatically dropping and on. Of course, these are very early days, so I understand that it sounds like I am crying wolf or describing a situation that isn't going to happen. But I think this could be a boiling frog dynamic over the next 10 years. And of course, these things are gonna be cheap as dirt. They work 24/7. They don't ask for vacation. They don't ask for time off. So the labor economics incentives to replace humans by AIs will be compelling, I suggest. And we humans won't compete. If the only thing that we can suggest is, please hire me, I'll make you 10% better. It's just not gonna cut it. I suggest, because these AIs are going to be so economically desirable. Cheap as dirt, good enough, no vacations, that if humans want to be attractive in the future labor market, I suggest that 10% isn't gonna do it anymore. Now, if you've read the Book of "Secrets of Consulting" by Gerry Weinberg, what do you know? One of Jerry's chapters is "never recommend more than a 10% improvement in business". And there's a whole bunch of interesting reasons for that. And I suggest that at this, what's going to be coming milestone or disruption in intelligence-as-a-service that we're going to have to suggest something more ambitious. And I call this "10X Org". So the idea is, as in LeSS, one of the guides is more outcomes, less outputs, the focus is on some business impact or some meaningful impact, not just on creating outputs. And so when we say "10X Org", what I'm trying to suggest is 10 times the amount of business impact, 10 times the market share, 10 times the revenue. Or whatever the business impact is. And I think that although before the age of AI, it would've been ludicrous to have these kinds of messages or suggestions, as a consultant. I think we're gonna be entering an age where aspirationally we need to make that pitch. And aspirationally, we humans will have to step up our game if we want to compete to actually achieve this goal. And so I think we're at a point in the industry where actually we can be bold and suggest a much deeper improvement than would've seen ludicrous before. And so with Roland and Alexey. Roland and Alexey! Over the last year, I've been starting to explore how to do this and the three of us are working on a book together, which we're gonna be releasing in not too long. And the basic idea, if you think of this from an Org Topologies point of view, this is Org Topologies as a 2x2, and quite simply where the scope of skills mandate is high and the scope of work mandate is high, that's the quadrant that is adaptive. And this has always of course been the message of LeSS. But what we're trying to do with Roland and Alexey with the "10X Org" message is expand this to a far broader audience to all the different markets that are gonna be affected by AI. And I suggest that in many of these, moving to this quadrant is the fighting chance for our children to have good jobs. The adaptive quadrant. And it's also, I would suggest the perfection vision of where LeSS gets to as well. Thank you."

TL;DR This article analyses the transformation of a major bank with org topologies. To understand this article, you first need to know about Org Topologies ™ . Summary of the transformation analysis: An organizational design can be implemented iteratively and incrementally. There is no need for "first time right". There is a need for an opportunity to learn the new design by experiencing it. Org topologies help implement organizational change in a structured and controlled manner. A shared transformation goal is necessary to achieve good results. Org Topologies helps to define a visionary overarching perfection goal, enabling everyone to understand the underlying principles. Employees need to be able to make autonomous decisions that will contribute to achieving the perfection goal. Org Topologies is an enabler that places the mandate for continuous improvement of organizational design in the hands of employees, at the lowest levels of the organization. If the org design perfection goal is too ambitious, it will jeopardize the transformation. "Too ambitious" happens when people reject the goal. Therefore, combine an unambiguous perfection goal with transformation sub-goals and use them as "Stepping stones" towards perfection. Mapping and naming intermediate sub-goals creates a clear picture of the maturity level, relative to the overarching perfection goal. This enables parts of the organization to focus on improvements that are most important for their specific context and provides an objective way to track progress . The success of each step in a transformation journey depends in large part on the extent to which employees (team members and management) can take ownership of the change. The unambiguous vocabulary and transparency provided by Org Topologies help achieve this. The transformation This transformation was rolled out bank-wide: About 3,000 people faced a change of work, a change of team, and/or a change of way of working in early 2022. Preparations for this took about a year and a half. The entire organization "flipped" to the new model in one go in March 2022. My role in this transformation was to "nudge" the organizational design with LeSS principles. The target model became a home-brewed mix of Team Topologies and LeSS. The main changes were: unified governance, continuous improvement, mandate low in the organization, and separation of the WHAT and the HOW. For the latter, the organization was split into a part for producing products and services (the WHAT) and for provisioning knowledge for it (HOW). In this paper, I focus only on the product development organization (the WHAT). Iterating on an initial design I observe in larger organizations that quite some time is spent on designing the future organizational blueprint. That's because changing the organizational structure is complex and risky. When the design phase is over, it is implemented with a big bang. The big bang approach creates clarity and reduces costs because no temporary structures need to be rigged to support a hybrid situation. A disadvantage is that it can create chaos because everything is suddenly different. Agile people like the clarity of the big bang. But we don't like a separate design phase. These two concepts can be combined by creating an initial organizational blueprint and releasing it on a flip date. We assume the initial blueprint is good enough, but not perfect and probably incomplete. After the initial release, we start iterating by applying smaller changes incrementally. This allows us to grow toward perfection guided by feedback loops. For such an approach to work, everyone needs to clearly understand that the implemented model is a starting point or a step of a journey. Also, everyone needs to be able to assess what are good and not-so-good adjustments to the model. Org Topologies™ is invaluable here because it visualizes the current position, the first step, and the perfection goal, allowing the continuous change to be kept "on track" by the employees themselves. Transformation goal: Uniformity The overarching perfection goal of the new organization was PART-3. In addition to that perfection goal, first steps towards that greater goal were proposed in the initial design. That first step was implemented bank-wide in early March and had a different design for each value area (called "Hub"). The design of the 15 new value areas on the flip date was not one single archetype but a mix of archetypes depending on the context within the value area. This meant that in all Hubs, the TASKS-1/TASKS-2 archetype was dissolved and replaced by: CAPS-2 archetypes (teams with their own Backlog and PO). One or more PART-2 types (1 PO, 1 PBL with two to six teams). Some PART-3 (fully end-to-end) value area. Achieving the more perfect archetypes has more and different challenges and implementation involves a higher degree of uncertainty. Somehow it made sense to migrate in a controlled way instead of creating the utmost chaos everywhere in the company. Despite each value area (Hub) having its own implementation of various archetypes, there is uniformity. In a transformation of this size, there is no "one size fits all" precisely because the starting positions are heterogeneous. Uniformity should not be sought in "everything is set up the same", but rather by: the unambiguous basic principles of the model, the formalized communication structures, the shared understanding and transparency about the journey. I believe we would have succeeded in this better and more easily if we'd had Org Topologies at our disposal. Language is important for ownership of the future model I visited many business units in the preparatory phase towards the flip date. One thing that struck me was that knowledge about the envisaged model and its underlying principles was insufficiently known by employees. And without understanding, no acceptance and hence no ownership of the new model is possible. The model did contain a new, common vocabulary, but we did not succeed very well in sharing it across the organization. Somewhere, something went wrong in the communication from the Transformation Office to the shop floor. The reason: Indirect communication from the heart of the transformation passed on via insufficiently informed management layers to the employees. This resulted in a range of differences in the interpretation of the content and operation of the new organizational model. Having a common vocabulary is an aspect that is offered by Org Topologies. Moreover, that vocabulary is not company-specific, which allows comparison between companies. Reporting on progress Progress reporting is always asked for and this bank was no exception. The transformation had been cut into phases and metrics were needed especially for the roll-out phase. Unfortunately, spreadsheets with tick lists were used. The agile coaches were instructed to get the lists ticked off on time. You will see this did not lead to understanding and ownership of the transformation but generated a lot of resistance. Moreover, it did not provide a transparent picture of our actual state. The Org topologies model offers a powerful and transparent solution. The model helps to describe the current situation and the change ambition per value area in archetypes to be implemented. The result is measurable by the decrease in the number of teams per PO/PBL (vertical axis) and the decrease in technical dependencies (horizontal axis). Some examples The overarching perfection goal for the future organization was PART-3. But planning and execution turned out to be two completely different things. I will use some examples to explain the movements of the organization at the bank. I will use the Org Topologies archetypes to show that things were less messy than they might seem at first glance. The bank was extremely heterogeneous before the transformation. It was a classic top-down driven organization, split into Business and IT. On the Business side, I mainly saw the TASKS-1 archetype: departments surrounded by a matrix structure for projects and initiatives and programs led by steering committees. A single department was of the CAPS-2 type (feature-focused interdependent teams, reasonably functioning SAFe). This was the bank's flagship department. In IT, it was mainly TASKS-2 archetypes: Component teams with task-level backlogs (poorly functioning SAFe). Example 1: The situation at HR, archetype TASKS-1 HR was not working agile yet, just like the vast majority of the organization. Although the department leads themselves thought otherwise. They translated being Agile into "working demand-driven". HR was of the TASKS-1 archetype. The department managers distributed the work in their Management Team meetings, called "MTs". I found that they often were in those MT meetings. The meetings lasted long, often a whole day. The managers discussed the various projects and priorities and split the work into tasks. These tasks were then assigned to the "usual suspects", which are the people who already have knowledge and experience of the required topic or technology. They also included available capacity in the allocation without involving the employees themselves. Then ad-hoc teams were set up to do the work. Those teams were tasked with carrying out the work and reporting on progress. Employees were usually in several teams at the same time and had to do "regular work" too. This way of managing product development is characterized by external coordination, external decomposition of the work, hand-offs, and extreme specialization. It leads to high workloads for both management and employees. The HR director asked me to help make their work process "more agile". My idea was to try to bring this TASKS-1 to a PART-3, i.e. 1 backlog for HR with the HR director as PO. However, the HR managers were not ready for this. They proposed CAPS-2: a separate backlog for each manager with responsibility for a particular journey (employee life cycle, recruitment, healthy and fit, ...). To get used to working in Sprints with fixed teams, I thought this was a good enough starting point. I foresaw that due to the dependencies between the journeys and the micro-management of the managers, this setup would lead to new problems for which the next step to PART-3 could become a realistic option. There was a danger in maintaining the existing management structure alongside the introduction of component-team Scrum. I foresaw that this would lead to dumping the Scrum experiment again. My approach was to dismantle the existing pattern in service of the org change. After all, the long MT meetings were a bottleneck that needed to be resolved. We started the movement towards CAPS-2 by removing activities from the MT meeting. We delegated them to the Scrum teams, except the Sprint Review. A joint Sprint Review was a logical start to grow towards PART-3, where the Sprint Review is a central event for the entire value area. Example 2: In the IT teams, TASKS-2 archetypes The IT department consisted of specialized component teams. There is a huge variety of tools, applications, products, and systems in use. And they had not yet succeeded in simplifying the architecture and infrastructure. The core banking systems, for example, are old and very specific. It makes no sense and the risk is high for all teams to learn these systems. For these environments, the choice was made to stay in TASKS-2. In Team topology terminology, these would be called "Complicated subsystem teams". Other IT teams with more common technology (such as Pega), were merged with business specialists into cross-functional teams. These were mostly CAPS-2 archetype teams. They could not deliver a full end-to-end product. In the preparatory phase, significant architectural changes were implemented to reduce dependencies between value areas and CI/CD, and provisioning (AWS) low-code/no-code solutions were devised to move the teams closer to the rightward columns of the Org Topologies map. Here and there, a single CAPS-3 or PART-3 area could be formed. Example 3: Mortgages and business banking, from TASKS-2 to CAPS-2 and PART-2/PART-3 The bank's flagship branch was Mortgages. They delivered faster and were better organized compared to the rest of the bank. This was because, as a forerunner, they had moved away from the standard TASKS-1 archetype. They had moved to the TASKS-2 archetype with the introduction of SAFe. The dynamics that prevailed here will seem familiar to you: Days of planning events focused on coordinating dependencies, low predictability of delivering customer value, lots of handoffs, frustration, and sense of powerlessness among the teams, and lack of learning by the group as a whole. This area did have a few exceptional teams doing "reasonable" SAFe. These CAPS-2 teams delivered specific front-ends with minimal dependencies on the back-end systems. The Mortgages value area implemented the SAFe framework because it provides clear guidance for scaling cross-team coordination. I remember the conversation I had with the Director of Mortgages about this. After seeing the PART-3 archetype (one consolidated backlog per area, end-to-end cross-functional teams) and the routes leading there, he realized that institutionalizing coordination is precisely the limitation of the SAFe model. He saw that SAFe does not focus on solving the root causes of the coordination need. Instead, SAFe keeps specialized component teams (horizontal axis of the Org Topologies map) with narrow domain knowledge (vertical axis) intact. His insight was reinforced by his experience with their very best teams; after all, they were already at CAPS-2 level in that they fully knew their domain and had virtually no technical dependencies with the rest of the organization. Some consultants might argue that the above result is not a successful transformation because of the presence of TASKS and CAPS-archetypes. I agree that migrating to an CAPS-type is in general not a good option because it offers too few advantages over the TASKS-types. I share the view that migrating to a PART-type archetype is better because the key de-scaling concept of multiple teams with one backlog adds substantial value. Some say CAPS-types should be avoided because the concept of a single backlog per team is difficult to roll back once implemented. I think we should not be afraid to allow CAPS-types in larger organizations if they are a step toward perfection. I consider CAPS-types bad when they are an end-state. In larger organizations we need to make a trade-off decision: Do we force PART-level as the minimum (consulting) or do we allow less adaptive archetypes and let the customer find their own meandering path (coaching)? In large transformations (hundreds of employees), I see the benefits of CAPS-types being set up alongside PART-archetypes as an intermediate step toward perfection. In smaller organizations (up to 50 people), CAPS-types are not a sensible option, implementing PART-2 is not the biggest success and a WHOLE-4 is the best achievable result. Using Org Topologies, we focus on a journey with a clear perfection goal and we have a good tool in hand to monitor and drive change towards an unambiguous perfection goal. Conclusions Org topologies™ provides support in a number of areas that can improve the journey of continuous organizational design adaptation: Structure of and control over the change process Meaningful progress monitoring (can be used as a maturity model) Transparency about the shared transformation goal Ownership of the transformation by the employees Controlled context-dependent variations of the organizational design Improved communication through unambiguous language (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.

Everyone is racing to adopt AI. Developers are coding faster with Copilot. Analysts are producing reports with GPT. Recruiters automate job descriptions, and marketers launch campaigns in minutes. But most of these initiatives only create local productivity boosts . Teams move faster in their own silos, while the big initiatives — the bold moves that actually matter to customers and strategy — remain stuck. Why? Because the wrong organizational design doesn’t just slow you down; it actively blocks progress . Layer AI on top of dysfunction, and the dysfunction only accelerates. Resource Topology: Faster Silos, Slower Outcomes In a Resource Topology , work is divided into specialized units (people, departments, teams). Analysts hand over specs, developers code, testers check, and an integration team stitches it all together at the end. This design optimizes for utilization, predictability, and centralized control. Add AI into the mix, and each unit becomes faster. Alaysts can deliver specs faster, leads can do more efficient planning and work prioritization. Developers produce more Android code per day, and testers can automate scripts in seconds. There is definitely progress. But when we look closer, we see that the overall speed of the system doesn’t improve . That is because adding AI does not change the way the system works. We still have handoffs between units, and they multiply the delays in the work. Decision-making remains unclear, creating noise in the system as work is bounced between units with limited mandates. Distributed decision rights, tied to risk and audit processes, restrict automation instead of enabling it. The performance gain is local, resulting in Faster queues, with slower outcomes . A classic law of systems thinking comes into play: “The performance of a system depends on how the parts fit together, not on how they perform taken separately. When you optimize the parts, you sub-optimize the whole.” (Russell Ackoff) The logical path of evolution is obvious. The narrow, repetitive roles in these silos are replaced by AI agents. That optimizes local productivity gains and cost savings. But it doesn’t make the organization as a whole more adaptable. In fact, it leaves the system as rigid as before, creating queues of work between AI agents. The plus (+) symbolizes an AI-equipped unit In a Resource Topology, AI typically delivers local wins. Assistants are deployed inside existing silos, which makes individual units faster but has little effect on end-to-end outcomes. The handoffs, approvals, and fragmented data flows remain unchanged, so queues continue to grow. Because decision rights are distributed across many groups, automation is limited and often slowed down further by risk and audit processes. The focus remains on optimizing local output, rather than improving the system's overall performance. Delivery Topology: Faster Streams, but Still Rigid Many organizations have evolved into Delivery Topologies. Cross-functional teams are restructured into value streams. Instead of analysts and developers working separately, they sit together and ship features from start to finish. In the best scenario, they have all the skills in the team needed to deliver end-to-end items of work. This is a genuine improvement. When we add AI to these teams, it will accelerate each value stream — features get delivered more quickly, backlogs shrink, and the teams feel empowered. The mortgage team, for instance, can now process applications end-to-end with remarkable speed. But there’s a hidden ceiling. Each stream is still a silo, locked into its own domain. The mortgages team won’t deliver insurance. The insurance team won’t deliver business loans. When a new customer need arises, the organization must spin up a new silo to serve that need. This design optimizes for speed at the team level and delivers what is already known . This system is fast at the value stream level, but not highly adaptive. Every strategic pivot requires reorganization. And although the value streams are fast, in the long run, they will stop producing value. That is due to the law of diminishing returns : once AI has extracted most of the speed gains from each stream, the cost of changes begins to outweigh the value, even when change is cheap. There is no more value for the customer in yet another change to the mortgage processing. Leaders will apply cost-saving measures — replacing people with AIs in routine parts of the value stream. Again, it creates local efficiency, but not systemic adaptability. In a Delivery Topology, AI produces mostly local improvements. AI assistants are deployed inside individual silos, which speeds up work but has only a limited effect at the value stream level. Innovation ultimately caps out because it is confined within these narrow value streams. The emphasis remains on optimizing local outputs, not on unlocking broader organizational performance. Adaptive Topology: Where 10X Becomes Possible True transformation comes with the Adaptive Topology . This design is not very common. It requires giving teams of teams the mandate to work on the whole business problem or customer need , not just a slice of it. And equipping them with all the skills and tools required to succeed. In an Adaptive Topology, people are multi-learners. They acquire knowledge across domains, enabling the team of teams to deliver outcomes autonomously. They refine work together, resolve dependencies directly, and coordinate face-to-face rather than through endless external handoffs. Here, AI shows its full potential. It is not trapped inside silos. It is applied to shared outcomes. Models are trained on customer data to spot shifts in demand. Generative AI accelerates prototyping and validation across the whole problem space. Moreover, cross-cutting concerns such as legal, security, and compliance are embedded, so everything produced complies to the standard requirements by design. In this environment, there is no need for disruptive reorganizations when strategy changes. Adaptation is built in. People and AIs collaborate holistically to learn, innovate, and deliver. And because people are multi-specialists — “M-shaped” instead of narrow — they are not candidates for replacement. They are indispensable. AI doesn’t reduce their relevance; it amplifies it. In an Adaptive Topology, AI is applied to shared business outcomes, which amplifies collective learning and impact. Because AI is integrated holistically, there is no overhead from fragmented, decentralized implementations. The system is holistic from the start, and AI strengthens that quality. First Design, then AI. The archetypes in each quadrant of the map will have specific benefits of an AI Adoption: Every organization has a design. Yet most leaders underestimate how profoundly the org design shapes the impact of AI. Without redesign, applying AI guarantees disappointment, because the expected gains are unrealistic. The contrast is clear: Resource Topology → AI delivers local efficiency, but the system remains stuck. Delivery Topology → AI makes teams faster, but the organization stays rigid. Adaptive Topology → AI amplifies adaptability, enabling the whole business to move in sync with strategy. AI does not fix design flaws. It amplifies them. To unlock its promise, leaders must first design organizations fit for change — and only then bring in AI. More on this AI and value streams in this video recording . More on Strategic AI . More on elevating to the Adaptive Topology .

Meet Alexey, creator of Org Topologies, to learn about rethinking the structures that almost likely keep your product development frozen in time, limiting the org's true potential. Most orgs get locked into rigid value-stream models—great for predictability but brittle in the face of change. This session shows how to 10X your organization’s adaptability and innovation by shifting from narrow value-streams to multi-learning, decentralized teams, and AI-enabled continuous learning. An online meetup recording: 13 Aug 2025

TL;DR In modern organizations, leadership style and organizational design are deeply interconnected. When we talk about Org Topologies  (Resource, Delivery, Adaptive), we usually think of structure. However, structure doesn’t shift without leadership shifting as well. The Leadership Circle gives us a useful lens here: Reactive leadership is fear-driven. It leans on control, compliance, and protecting one’s image. It stabilizes, but it stifles learning. Creative leadership is purpose-driven. It emphasizes vision, trust, collaboration, and systemic improvement. It unlocks adaptability and innovation. Org Topologies show us the organizational side: Resource Topology is siloed and efficiency-focused. Delivery Topology is cross-functional and output-focused. Adaptive Topology is versatile, outcome- and learning-focused. Now put them together: Resource Topology runs on Reactive leadership – command, compliance, and tight control. Delivery Topology needs a blend – Creative “achieving” combined with just enough Reactive discipline to keep flow predictable. Adaptive Topology thrives only under Creative leadership – visionary, empowering, learning-oriented. This article examines two frameworks – The Leadership Circle  (which differentiates leadership styles, notably Creative  vs Reactive  orientations) and the Org Topologies  model that describes different organizational design archetypes. We first summarize each framework’s core components, then map how various leadership styles align with each type of organizational topology. Finally, we discuss how leadership development needs to evolve as an organization shifts from one topology to another. The Leadership Circle Framework: Creative vs. Reactive Leadership The Leadership Circle framework (often delivered via a 360° Profile assessment) divides leadership behaviors into two primary categories: Creative Competencies  and Reactive Tendencies . The Leadership Circle is a model that maps leadership behaviors and mindsets into two overarching orientations – Reactive  and Creative  – each of which represents a distinct way of leading organizations and people. Like Org Topologies, it offers a map of different archetypal patterns. Each half contains specific dimensions that capture a leader’s internal assumptions and outward behaviors: Creative leadership  is characterized by effective, growth-oriented behaviors. Leaders high in Creative Competencies “achieve results, bring out the best in others, lead with vision, act with integrity and courage, and improve organizational systems” . For example, creative dimensions include Relating  (building teams, developing others) and Achieving  (setting vision and accomplishing strategic goals)  . These competencies stem from inner confidence and a focus on purpose rather than fear. Notably, leaders who score high on the creative scale tend to be far more effective. High Creative leadership correlates strongly with better leadership performance and business outcomes. Reactive leadership  is associated with self-limiting or fear-driven behaviors that can constrain effectiveness. The Reactive Tendencies reflect inner beliefs that limit a leader’s authentic expression and impact . Examples include Controlling  (a tendency to micromanage, push for perfection, and derive self-worth from being in charge or “on top”) and Complying  (a tendency to seek others’ approval and follow others’ expectations to feel secure). Such leaders often emphasize caution, control, or defending their image over innovation and engagement. In the Leadership Circle Profile, high reactive scores are inversely correlated  with leadership effectiveness (often coinciding with low creative scores). In short, a predominantly reactive “command and control” style may undermine a leader’s impact, whereas a creative, empowering style enhances it. In summary: Reactive leadership  optimizes for safety and control. Creative leadership  optimizes for trust, learning, and purpose. The Org Topologies Framework: Organizational Design Archetypes Org Topologies is a framework for strategic organizational design that maps out archetypal ways to structure an organization. It introduces a visual mapping technique  using two key dimensions of org design and defines multiple archetypal unit types. Sixteen base archetypes (team or department patterns) are categorized into four groups, and, importantly, these are distilled into three distinctive organizational “topologies”  – common overarching patterns of how work and authority are organized . Each topology represents a fundamentally different organizational ecosystem with particular characteristics and fit-for-purpose use cases . The three topologies are summarized below: Resource Topology:  A siloed, efficiency-oriented design with frozen functional roles and high specialization. Here, work is divided among specialized units (e.g., separate functional departments), and resources  are managed to be 100% utilized. Leadership in this topology relies on top-down coordination  – managers (or project management offices) plan work, allocate tasks, and monitor utilization across narrow skill silos. Because each group only performs a fragment of the process, extensive handoffs are needed for end-to-end delivery. Learning and innovation are limited; improvement tends to occur only within one’s specialization rather than through new discovery . Use case:  Resource Topology fits stable environments where maximizing resource efficiency and specialization is the primary goal (e.g., a project-based organization hiring specialists for defined tasks). Delivery Topology:  A fast-flow, output-focused design that upgrades to cross-functional teams  delivering value with fewer dependencies. Compared to Resource Topology, work in Delivery Topology is organized into independent delivery units  (e.g., feature teams) that can produce “completely done” increments with minimal handoffs. This is often likened to a “feature factory”  – teams churning out a steady stream of features for a product. There is a strong focus on outputs and local efficiency  (throughput of features), and teams are kept narrow in scope  so they can deliver quickly and predictably. High-level analysis or product decisions are still handled by “directing” roles or upstream units (product managers, analysts), meaning discovery  of what  to build remains somewhat separate from delivery  . This topology excels when the challenge is not figuring out what to build (the requirements are known and of proven value) but rather delivering it rapidly at scale. Use case:  Delivery Topology is well-suited for environments where predictable, speedy delivery  of features is critical and the market/problem is well-understood (for example, a software company rolling out frequent minor enhancements or a restaurant kitchen executing a set menu) . Adaptive Topology:  A highly adaptive and innovative  design that merges directing, doing, and delivering into unified, empowered teams. In Adaptive Topology, traditional functional boundaries are dissolved; instead of silos, the organization might form a “team-of-teams”  or network of multi-skilled teams that work in unison across the entire value stream   . The goal of this topology is to maximize  adaptiveness  – enabling easy, continuous change based on learning, and true customer-centric innovation . Teams (and individuals) in an adaptive org are expected to collectively discover  what customers need and deliver  solutions rapidly, adjusting course as necessary. This requires a culture of continuous learning, high autonomy, and synchronous collaboration (often supported by real-time data and AI tools to inform decisions). The design makes it “cheap and easy” to pivot strategy because teams are broadly skilled and tightly aligned with the overall purpose, not confined to narrow tasks. Use case:  Adaptive Topology is fit for dynamic, uncertain environments where innovation and agility  are paramount – for example, product R&D groups, startups, or market disruptors that must rapidly experiment, learn, and respond to change. It promotes long-term business resilience by enabling higher-impact outcomes and continuous adaptation. In summary , each topology serves a different strategic goal and entails a distinct organizational structure: Resource topology optimizes for resource utilization and specialization , Delivery topology for fast flow of outputs , and Adaptive topology for rapid learning and innovation (outcomes) . These differences in structure and goal create different demands on leadership style, as we explore next. Mapping Leadership Styles to Organizational Topologies The effectiveness of a leadership style is often context-dependent. A leadership approach that succeeds in a tightly controlled, efficiency-driven organization may falter in a fast-changing, innovative company, and vice versa. The Leadership Circle’s distinction between Reactive and Creative orientations provides a useful lens to map leadership styles onto the needs of each Org Topology. Broadly, as an organization’s design shifts from Resource  → Delivery  → Adaptive , the leadership culture must shift from predominantly Reactive  (command-and-control, cautious, task-focused) to increasingly Creative  (visionary, empowering, collaborative) to support the organization’s purpose. The table below summarizes this alignment: Organizational Topology Best-Suited Leadership Style (Leadership Circle) Organizational Needs & Rationale Resource Topology   Goal: maximize efficiency & specialization Predominantly Reactive  – directive, controlling style focused on stability and compliance. This topology’s siloed, plan-driven structure requires leaders who tightly coordinate and enforce standard processes . Reactive leadership tendencies (e.g., emphasizing control and risk-aversion) align with the need for predictability and utilization in a Resource topology, ensuring everyone follows the plan and stays “100% busy.” However, this can limit flexibility and innovation. Delivery Topology   Goal: fast, predictable delivery of outputs Balanced/Transitional  – leaning Creative (achievement-oriented) but with some Reactive discipline. Delivery topology introduces cross-functional teams and faster flow , so leaders must empower teams  to own delivery while still maintaining focus on output targets . A Creative  leadership approach that drives results and continuous improvement (high on the “Achieving”  competency) suits this environment. Leaders foster collaboration and adaptiveness within teams, yet may retain Reactive  elements like process control to ensure reliability and alignment with product requirements. Adaptive Topology   Goal: continuous adaptation & innovation Predominantly Creative  – visionary, empowering, and facilitative style. An adaptive organization needs leaders who inspire purpose, trust, and innovation . Creative leaders excel here by providing vision and strategy while empowering teams  to experiment, learn, and self-organize towards outcomes. In this high-change ecosystem, reactive, control-oriented management would be counterproductive  – as research notes, truly adaptive/agile cultures “require Creative Leadership” , and reactive leadership cannot easily usher in the needed innovation and engagement. Leaders must cultivate a culture of trust, agility, and learning, embodying competencies like Relating , Self-awareness , and Systems Thinking  to enable the organization to thrive in uncertainty. As the table illustrates, leadership style and organizational topology need to be in sync . A mismatch can create friction – for example, a purely reactive, micro-managing leader will likely stifle an Adaptive topology that demands empowerment and quick learning, while a purely visionary, hands-off leader may struggle in a Resource-focused bureaucracy that expects tight control. In practice, organizations often evolve through these topologies, and leadership mindsets must evolve in tandem. Evolving Leadership Development as Topologies Shift Shifting an organization’s topology (e.g., moving from a Resource model to a more Adaptive model) is not just a structural change – it is a cultural and leadership transformation. Leaders must develop new skills and mindsets  to support the new way of working. Below are some insights on how leadership development needs to evolve when an organization transitions from one topology to another: From Resource to Delivery Topology:  Leaders need to shift from micro-management to empowerment  as the organization moves toward cross-functional teams and faster delivery cycles. In a Resource topology, leaders were accustomed to detailed upfront planning, strict role boundaries, and ensuring compliance with plans. To succeed in a Delivery topology, they must unlearn  the overreliance on rigid plans and resource control. This means developing more Creative behaviors: trusting teams to self-organize within their scope, encouraging collaboration across functions, and focusing on outputs/outcomes rather than hours worked. Leaders should practice delegating decision-making to teams and fostering a culture of continuous improvement. In short, they transition from being task masters to being enablers  – providing clarity and removing obstacles, while allowing teams more autonomy. This can be challenging, as it requires overcoming reactive impulses (e.g., the need to control every detail), but it is crucial for faster flow. By “supporting testing of new approaches and learning from quick adjustments, instead of sticking strictly to preset plans,”  leaders create an environment of trust and motivation in the Delivery context. From Delivery to Adaptive Topology:  This shift demands an even deeper leadership transformation – from a results-oriented agile mindset to a truly innovative and learning-focused  mindset. In moving to an Adaptive topology, leaders must fully embrace Creative leadership. They need to cultivate qualities like visionary thinking, humility, curiosity, and systemic awareness . Practically, this involves encouraging experimentation and accepting the risks of failure as opportunities to learn. Leaders must focus on outcomes  and customer impact over output, which means guiding teams with a compelling vision and then giving them freedom to discover solutions. Developing a culture of empowerment and trust is paramount : agile/adaptive leaders “cultivate a culture of trust and empowerment, encouraging team members to take initiative and innovate,”  which fosters an environment where experimentation thrives. Many traditional management habits (e.g., top-down decision making, extensive upfront analysis) must be shed in favor of facilitative leadership, coaching, and adaptation. According to Anderson and Adams (creators of the Leadership Circle), the “innovative, agile, adaptive”  organizational cultures of the future require Creative leadership  – reactive, compliance-driven leadership cannot  generate the level of engagement and innovation these organizations need. Thus, leadership development efforts should focus on building creative competencies (such as relationship building, strategic foresight, and self-awareness) and transforming leaders’ mindsets from controlling to inspiring . This often involves personal development work, coaching, and hands-on experience in agile ways of working. As leaders grow into this new mindset, they enable their organizations to fully realize the benefits of an Adaptive topology. Conclusion Aligning leadership style with organizational topology isn’t optional — it’s decisive for performance. Shifting from Resource → Delivery → Adaptive  is never just about moving boxes on a chart. It also demands a parallel shift in leadership: Reactive → Creative . The two evolutions are inseparable. Organizations that chase adaptability without Creative leadership will stall. Leaders who try to operate creatively inside a rigid Resource structure will suffocate. Both maps — the Leadership Circle and Org Topologies — point to the same truth: you can’t elevate the system without elevating how you lead. The takeaway is clear: as companies push toward greater agility and innovation, they must invest in Creative, growth-oriented leadership at every level. Leaders who learn to act from purpose and vision, not fear and control , create the conditions for truly Adaptive organizations — ones capable of sustaining high performance in a world of constant change. Sources The Leadership Circle – Overview of Creative Competencies vs. Reactive Tendencies The Leadership Circle – Reactive and Creative Leadership Definitions Anderson & Adams – “Reactive to Creative Leadership” (Mastering Leadership excerpt)   (emphasizing need for creative leadership in adaptive cultures) Kestria Insights – “Adaptable leaders: Embracing agility and lifelong learning”    (on empowering leadership in agile transformations)

“Aligned Autonomy” is a concept that aims to strike a balance between autonomous decision-making and alignment with organizational goals and values. The concept suggests that employees should have the freedom to make decisions and take actions autonomously, while also being aligned with the overarching objectives and principles of the organization. "Aligned Autonomy" as a concept has been referred to in various sources, to name a few: “Drive: The Surprising Truth About What Motivates Us” by Daniel Pink “Turn the Ship Around!” by L. David Marquet “Empowerment and Organizational Development” by Bernard Bass and Bruce Avolio Another source is Henrik Kniberg , a famous Swedish agile coach and org consultant. Henrik coached at Spotify around 2012 , where he described their unique scaling model, initially  proposed by Joakim Sundén  and his colleagues. Henrik created  a cartoon series  that sparked worldwide interest and became known as the "Spotify Model." As a part of explaining how Spotify's ways of working were unique, Kniberg drew an image that describes the special relationships between the teams and management at Spotify: Aligned Autonomy. Image by Henrik Kniberg This image describes the relationship between team  alignment  and  autonomy  as a two-dimensional matrix. Team autonomy is on the horizontal axis, and team alignment is on the vertical axis. According to the matrix, autonomy marks the extent to which a team can make decisions about its work. Alignment symbolizes having a common purpose. Upon examining the image, it is evident that, according to the creator, management plays a crucial role in connecting the two. Key insights to derive from this matrix: Alignment and autonomy are not different extremes of the same continuum More alignment doesn't mean less autonomy We need both (alignment and autonomy) to achieve a high-performing organizational setup. In this article, we ask ourselves:   Which organizational design allows multiple teams to collaborate at scale with high autonomy and full alignment? Alignment (for Purpose) Alignment is having a shared purpose. When teams are aligned, they pursue the same goal (as exemplified by Kniberg's "crossing the river"). Alignment is about getting the noses in the same direction and working toward a shared purpose . Management sets the boundaries and decides on how much autonomy is given to the "workers". Also, they are responsible for laying the groundwork for alignment. In other words, managers must effectively convey the "why", with strategy and purpose. Alignment and autonomy are closely intertwined, with management playing a crucial role in connecting the two. Alignment can be structured by management in many ways (by assigning coordinators or organizing for self-regulation), and it needs to match the granted level of autonomy (people cannot self-organize when a manager is (micro)-managing them). Autonomy (for Agency) For Spotify and other great companies, autonomy is a degree of freedom that teams have to act within the aligned purpose. Management "gives" autonomy to teams. These days, a common term for this phenomenon is agency-degree of freedom. Intelligent agents are given the freedom to act independently for the benefit of a shared purpose. While developing organizational topologies, we have discovered new insights about Autonomy and Alignment that differ from the Aligned Autonomy model presented by Kniberg. Dimensions of Autonomy Trying to establish autonomy in a group, for example, by creating autonomous teams, has become commonplace in most organizations. The management discussion on controlling work and outputs has shifted toward granting mandates and determining the degree of self-organization. The question is no longer whether teams should be more autonomous or not. The question is where that boundary lies. Richard Hackman, Professor of Social and Organizational Psychology, provides a powerful illustration of the options: Levels of self-management by Richard Hackman https://en.wikipedia.org/wiki/Team By "autonomy of teams," most organizations mean the second column per Richard Hackman's model above: Teams must be granted the authority to "execute the task" and "monitor and manage work processes." This is the bare minimum of self-management. There is no self-organization when these two permissions are not granted to the teams. Some organizations have tried the next level of "self-designing teams," where the teams not only execute and monitor but also "design the team and its context." We have experienced these experiments in  LeSS-inspired adoptions  and can confirm that this significantly enhances teams' agency. Designing for Autonomy in a Multi-Team Environment Do you agree that an individual team's speed is an interesting indicator of organizational performance? Are we truly measuring organizational performance when we examine a single team? Consider that the Billing team can be extremely fast at implementing a new Billing rule, but delivering the overarching customer journey, which requires contributions from many other teams, may take months. For a fact: the fewer (blocking) dependencies a team has, the more autonomous it is, the faster it can deliver product backlog items end-to-end. On the Org Topologies map, making org units (such as individuals, teams, or AI agents) faster is a horizontal move. Units can be formed more quickly by acquiring skills, insourcing skills, removing dependencies, and reducing the need for certain skills through automation, among other methods. In a multi-team environment, such a change is not a single-team transition but a coherent transformation of the larger ecosystem. In the picture below, three teams have merged to create a more autonomous CAPS-2 team with reduced skill dependencies on other teams. Analysts, testers, and front-enders now work as a team in the same cadence. The new CAPS-2 team possesses a higher degree of autonomy. They can decide on solutions as a group and handle more complex work at the capabilities level without needing assistance from others. However, they remain dependent on the back-end team. Transition of an ecosystem Note that such a movement is an organizational design change, not simply a policy or process change. Designing for Alignment in a Multi-Team Environment Similarly, creating alignment in a multi-team environment is not a mere manager's blessing: "thou shalt now be all aligned." People need to be aligned to complete a shared challenge. The question is: how can we arrange this to happen? What kind of alignment can we think of? There's alignment through external coordination and alignment through collaboration. Imagine a big room planning event (similar to Product Increment Planning in SAFe, for instance). The teams are gathered for a few days. They are presented with a strategy. The product board is filled with cards of different sizes and values. Teams are facilitated to identify mutual dependencies. The dependency manager connects cards with strings, and a detailed three-month plan is crafted upfront. Managers, coordinators, and teams are now aligned and understand how to manage the plan's execution and track dependencies. The teams are now free to proceed to their desks and begin work. Are those teams aligned? Yes, they are aligned. There is a shared purpose and a common plan to achieve this goal. Cross-team meetings will be organized by the coordinators to compare the plan with the actual state and make necessary course corrections. As a result, the teams' work queues may change, reflecting the actual progress toward delivering value as a group. Is it good enough? Not really. Remember that we need alignment to deliver a shared challenge. The concept of a detailed plan, upfront identified dependencies, and external coordinators to manage individual teams will reduce the possibilities for cross-team collaboration. It increases the team's ability to work independently, but does not equip the teams to see the broader picture of the shared challenge. Setting up for alignment through collaboration. We believe that external coordination as a means to align is weaker than giving teams the mandate to align with each other through collaboration. The success of this approach will depend highly on the team composition. Designing cross-team collaboration requires thinking about autonomy and alignment. We want to be in the top-right corner of the Kniberg matrix, where teams are highly aligned and have high autonomy. Org Topologies offers a model for designing collaboration at scale. It identifies four distinctive levels of a team's focus: Four levels of focus These four levels are essential for designing effective collaboration. As the teams' scope of work expands from task focus and capabilities focus up to partial business and whole business focus, the teams' scopes of work start to overlap. This is traditionally seen as a problem we want to avoid. But we can also see this as an opportunity for teams to collaborate. Overlapping responsibilities are traditionally viewed as a problem to be avoided. However, teams now have a shared scope of work and can join forces to attack big common challenges: Shared scope of work Alignment through collaboration is a result that emerges from overlapping responsibilities and shared goals. Aligned Autonomy at Scale We have discussed the different forms and shapes of autonomy and alignment. To create an organization where teams have full autonomy (not isolation) and can remain perfectly aligned (through collaboration), we need an organizational design that provides wide mandates on both the scope of work and the skills required to perform that work. Design for collaboration It is the space where highly collaborative practices, such as  Multi-Team Product Backlog Refinement  and  Joint Sprint Reviews ,  become the norm. Refer to  Elevating Katas™  to learn more about designing collaboration at scale. Such an organizational design requires organizations to experiment with abandoning the idea of Independent, autonomous teams and instead creating cohesive, interdependent multi-team units: a team of teams. At Spotify they created a space for collaboration with many cross-team structures and meetings: High collaboration at Spotify Over time, through practice and tight collaboration, a team of teams will develop a broader understanding of the product. They will start to think holistically from the business and customer perspectives and realize that they need each other to make significant changes in the product. Autonomy at scale requires a broad scope of work and skills to facilitate alignment through collaboration. This might sound utopian, but don't worry. This is a "perfection vision" for your transformation. You can aspire to it and gradually move your organization in this direction. You can also grow gradually by trying out practices from the  Elevating Katas™ . At a super large scale (hundreds of teams), there can be multiple "teams of teams", each specializing in a business domain and a set of cohesive customer journeys. In the case of financial services, for instance, there can be a team of teams for Retail Banking and another team of teams for Business Banking. Management provides direction by setting strategy and priorities, along with product goals. The teams turn those goals into tangible products. Aligned autonomy at scale can be achieved through broad product knowledge (encompassing the scope of work, represented on the vertical axis) and a comprehensive skill set (encompassing the scope of skills, represented on the horizontal axis). Endnote: We do not claim that every individual needs to know everything and possess every skill. We claim that large groups of people can be mandated to multi-learn in both directions to acquire the capability of knowing everything and having every skill collectively as a group . © Roland Flemm and Alexey Krivitsky