‭Identifying shared skills to elevate a‬‭ complex product organization with Org Topologies‬

Introduction

‭ An organization with a physical product, including a lot of (embedded and connected)‬ software - internally developed and manufactured - desires to elevate their product‭ development towards a more end-to-end approach, moving away from technology-focused‬‭ teams towards teams of teams with an end-to-end focus. Their journey identifying the‬‭ optimization goal of more end-to-end focus with better options to change direction started‬‭ with systems thinking by‬‭ system modeling‬‭ their current‬‭ situation and identifying their‬‭ optimization goal. Additionally, the system modeling revealed the root causes limiting them‬‭ from reaching their true potential.‬

‭One of the important aspects in their journey is to redesign teams, while having certain skills‬‭ in multiple teams to be able to develop and maintain shared technologies or components in multiple teams. Org Topologies was used to analyze (and reconsider) the elevation that was‬‭ already designed based on the systems thinking, and resulted in the discovery of which shared‬‭ skills and technologies should be included in multiple teams. This case study will focus on‬‭ the discovery of the shared skills and technologies, and not on the full MADE of the product‬‭ organization.‬

‭ Context and Challenges‬

‭The organization has a rich history of developing and manufacturing physical products, and has grown‬‭ over time by merging several organizations across countries. In the last decades the aspect‬‭ of software became bigger, and now the physical products not only contain software, they‬‭ are also connected and need to work in an ecosystem with user interfaces (such as an app).‬‭ Common challenges of larger organizations are present, like developing and maintaining‬‭ multiple products, consistency across different production sites and countries, as well as‬‭ keeping up with new developments in technology. Historically, the use of software in their‬‭ products grew and at some point was brought centrally, having to deal with balancing the‬‭ commercial needs as well as the ability to maintain and stay adaptive to change. The focus‬‭ of the case study is on the department that creates all software for the physical products as‬‭ well as part of the hardware related to the software (e.g. print cards). The department has a‬‭ common organizational design - the first topology - with teams focusing on part of the‬‭ technology (software and/or hardware), while the physical product contains these parts‬‭ working together. The main challenge is to be able to deliver in a decent time as well as to‬‭ be able to change the products to stay competitive.‬

‭Map & Assess‬

‭A simplified Map & Assess visualization (some teams are combined, some teams are left out‬ because they are less relevant for the core message of this case study) for context shows‬ ‭that there is quite a lot of alignment (in PART-1 & PART-2) needed before desired features or new product variants would move to mainly functional and multi-skill teams (in CAPS-1 &‬‭ CAPS-2), leaving these teams with a lot of dependencies and unclarities about actual‬ ‭higher-level priorities. The yellow PART-2 teams are business teams that capture the‬ ‭physical product and are the main stakeholders for the software of the physical product for‬ ‭the department. The map shows the following:‬

map and assess with Org Topologies

This organizational design was optimized for local lead times, and a result of bringing‬ ‭technical skills that were more individually focused together in functional or sometimes‬‭ CAPS-2 and TASKS-2 multi-skilled teams. This led to improved knowledge sharing, reduced‬ ‭dependencies and reduced redundant components. This was a big improvement at the time,‬ ‭but when their environment got more complex (technology and dynamics of the market),‬ ‭more demands from customers & markets came forward, the limits of this organizational‬ ‭design became transparent. Some teams included more skills in their team design and could‬ ‭deliver some less complex features themselves, but most teams were attached to specific‬

‭parts of the technology.‬

‭Additionally, the vision & products of the department were not in sync with the markets and‬ how the rest of the organization is organized. The connections between the other‬‭departments, the inside department product managers, and the teams showed many‬ ‭dependencies and lack of end-to-end focus. This made it hard to align with the‬ ‭organization’s broader objectives. The teams have a ‘Product Owner’, who was mainly busy‬ ‭with aligning and making sure requirements were understood by the team.‬

‭The connections of certain teams became very transparent with the Map & Assess exercise.‬ ‭With the already intended move - based on the root causes and optimization goal of the‬ ‭systems thinking - the learning was to have certain shared skills and technologies in multiple‬ ‭teams (or team of teams). The mapping shows very clearly teams 5 & 6 having to connect to‬ multiple other teams. Mapping the main connections for teams and the needs and‬ ‭dependencies for skills and technologies of other teams proved valuable for identifying the‬ ‭shared skills and technologies as input for the new design.‬‭

‭

Within several of the teams there were skills that in the new situation will be used by multiple‬ ‭teams, though not as important as the skills and technology from these teams for the overall‬ ‭optimizing goal. Therefore, those details are left out of the visual representation.‬

‭

Design‬

‭The post-mortem Design showed an approach to optimize for end-to-end capability, moving‬ ‭away from technology-focused teams towards elevated teams of teams with an end-to-end‬ ‭focus (CAPS-3). Additionally, the prioritization and alignment will be optimized in 2 ways:‬ ‭simplifying the authority on priorities to 2 Product Owners (PART-2) and connecting the‬ ‭Product Owners both to the markets that are strategically identified to focus on, which is also‬ ‭where the rest of the organization is organized towards (PART-2 teams from other‬ ‭departments). The - simplified - desired organizational design is visually represented below.‬‭

design with Org Topologies

Good to note that the elevated team of teams still has 1 or a few Product Owners additional‬ ‭to the Product Owner in the visual representation, which they call an ‘area’ Product Owner.‬ ‭The Product Owner of the map prioritizes on higher level, while the area Product Owners‬ ‭take the higher-level prioritization one step further towards the more detailed priority for an‬ area (usually 2 or 3 teams per area). There are much less Product Owners compared to the‬ ‭initial situation, and in many cases multiple teams per Product Owner representing an‬ ‭(close-to) end-to-end area of work. The team of teams are mapped as an end-to-end‬ ‭archetype, because the scope of skills mandate is within the market and area they are in.‬ ‭Over time, they want to move more to the expanding archetype, integrating technologies and‬ ‭moving to a real team of teams with fewer Product Owners, ideally 1 Product Owner per‬ ‭distinguished strategic market orientation.

Simplifying authority on priority‬

‭In the current situation, the decision-making and stakeholder involvement is not consistent‬ ‭with the strategic focus of 2 markets, and this leads to many dependencies and a lack of‬ ‭end-to-end focus. The inside-department Product Managers are still there (one of them will‬ ‭become one of the two visualized Product Owners), however the interaction and authority of‬ ‭their role changes. They will be focused on understanding the market and customers, but‬ ‭have no decision-making on priority. Second, the Product Owners have an (increased)‬ ‭end-to-end focus and are matching the market orientation and organizational design of the‬ ‭rest of the organization. Therefore, it will be easier for them to create a vision together and‬ ‭decide on priorities.‬

‭

Team of teams with end-to-end focus

‬

‭The new Design consists of two elevated teams of teams with an end-to-end on the‬ ‭strategically identified markets (CAPS-3). Both teams of teams should include all relevant‬ ‭skills and technologies needed for those markets, though some of these will stay in one of‬‭ the teams of teams initially (due to technological constraints or limited amount of knowledge‬ ‭available). Additionally, the platform teams are re-oriented to work closer together, though‬ ‭not changing structurally yet. The strategic direction there is to have a future-proof platform‬ that will help deal with many dependencies and long-term sustainability. This is a‬ ‭technological elevation to improve the product quality.‬

‭It’s good to reflect whether the teams of teams have a capability scope of work mandate,‬ and not a partial business scope of work mandate. The teams of teams are both still‬ ‭attached to a certain capability, though more end-to-end. They are not expected to learn or‬ ‭grow broader towards a partial business, as the Product Owner and business stakeholders‬ are expected to provide this overview. This makes them still attached to a certain capability.‬

‭The other reflection is whether teams are end-to-end or multi-skilled. It depends on the reality‬ ‭after moving in this direction. The purpose is end-to-end, but quite some elevations need‬ ‭to happen to ensure this will be a reality, like technical excellence and including end-to-end‬ ‭testing in the team of teams and more.‬

‭

The teams of teams will have a broader scope of skills mandate, working from a single‬ ‭Product Backlog for the end-to-end capability. This incentivizes improving the end-to-end‬ ‭capability, to improve the feedback loops, end-to-end testing, support, collaboration on work‬ ‭, and more. One important part of this change is to have teams, stakeholders and other roles‬ ‭work together earlier in Product Backlog Refinement, enabling expertise knowledge in an‬ ‭earlier stage, shorter feedback loops and better whole capability understanding for the‬ ‭teams, which should lead to solving the customer problems better ultimately.‬

‭

Shared skills & technologies‬

‭In the new Design certain skills and technologies are in all teams of teams and in some‬ ‭cases in multiple teams all together. The visual representation shows the merge of the‬ ‭separate display software and connectivity teams into the teams of teams. Part of the‬ ‭technology related to connectivity moved to the platform team. Additionally, some smaller‬‭ shared components and technologies are the responsibility of both teams of teams, while‬ ‭re-using these shared parts for both markets. This leads to a broader focus of the teams,‬ ‭less dependencies and new incentives to optimize for the broader products or capabilities.‬

‭

Elevation‬

‭There are several elevating kata’s applied to move towards the desired Design, amongst‬ them:‬

●‬‭ the expansion of the product definition‬

● merging Product Backlogs‬

● shared Definition of Done‬

● redesigning to broader scoped teams‬

●‬‭ bring teams close together to collaborate as a team of teams‬

‬and more.‬

‭

The focus on the shared skills & technologies identifies the need for the elevating kata of‬‭ shared ownership of components or technologies (and shared functionality from a business‬‭ perspective as well). Elevating towards this is hard in practice, since there are historical,‬‭ process, technological and mental constraints to be able to achieve this.‬

‭To enable shared components or technologies, technical improvements need to be in place,‬‭ as well as organizing learning and collaboration. For the technical improvements, most‬‭ important is to assess the current situation and determine what is needed to be able to, e.g.‬‭ , with an‬‭ improvement kata‬‭ to make small steps forward‬‭ to the end goal. Depending on the‬‭ current situation, improvements often include a shared version control system across‬‭ components, continuous integration behavior (and related branching strategy) and‬‭ preconditions to make that happen, quick feedback loops with automated tests and‬‭ improving the architecture or design of the product(s) to simplify for shared work. For‬‭ organizing learning and collaboration, a shared Product Backlog with a common way of‬‭ working across the teams is a starting point. On top of that, organizing knowledge across‬‭ teams in communities, encouraging teams to talk to each other when needed and help them‬‭ to identify when to work synchronously together are among the practices that can help‬‭ elevate to shared components and technologies. These improvements typically also lead to‬‭ other elevations, like shorter feedback loops to customers and understanding the whole‬‭ product.‬‭

‭Conclusion‬

‭This case study highlights the journey of a complex product organization shifting from‬ ‭technology-focused teams to elevated teams of teams with an end-to-end focus. A key‬ ‭insight was the identification of shared skills and technologies across multiple teams to‬ ‭reduce dependencies, improve adaptability, and enhance delivery speed.‬

‭The Org Topologies Map & Assess exercise uncovered systemic bottlenecks, including‬ ‭fragmented ownership, misaligned priorities, and high amounts of dependencies. By‬ ‭elevating towards CAPS-3, the post-mortem org design confirms the desire for an‬‭ecosystem where teams of teams could own broader capabilities while ensuring critical‬‭ technical expertise was distributed effectively.‬ Identifying shared components and technologies through MADE provided clarity indesigning‬ teams and defining elevation strategies. Several additional elevating kata’s are useful to help‬‭ to move towards this desired state. Elevating shared skills and technologies is not just a‬‭ structural shift—it is a systemic transformation that requires aligned priorities, technical‬‭ enablers, and cultural adaptation.‬