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