Studying Elevation Opportunities in Automotive Data Exchange

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.