Mind The Gap Between The Train And The Platform!
In the rush to platformization, organizations often create a chasm between the platform and its customer-centric parts. This divide can lead to misaligned priorities, inefficiencies, and stifled innovation. Mind the gap!
Caution
This topic is highly contradictive as many consultants advice for exactly the opposite — to focus on platform development. That is probably why recent LinkedIn post on avoiding platformization has triggered a lot of attention.
In this detail article I’m going beyond this false dichotomy (i.e. to platform or no to platform) and aim to advise for a balanced view on this subject with a preference to focus on the whole product.
Problem Statement
Imagine an architect who discovers that several stream-aligned teams share a common concern that could be extracted and reused. Thrilled by the opportunity, the architect identifies an important task ahead. The default reflex is to design a platform to address this shared concern. However, each stream-aligned team has its own roadmap and is busy with their tasks. The proposed solution seems simple: create a new team dedicated to this platform. Thus, a platform team is born.
The architect collaborates with this platform team, spending weeks meticulously designing and implementing a platform solution, complete with beautifully published APIs. The next step? Mandate that all the stream-aligned teams integrate and utilize this new platform. This seemingly straightforward approach, however, is fraught with challenges and often leads to unforeseen issues. This modus operandi assumes that all variables can be anticipated through extensive analysis and design, a notion that often proves unrealistic in the dynamic environment of software development and organizational operations.
The Pitfalls of Platformization in Software Development and Its Effects on Org Design
Platformization, particularly in software development and organizational design, often stems from misguided priorities and expectations.
While platformization aims to achieve economies of scale by standardizing processes and creating reusable components, it can paradoxically lead to inefficiencies if not approached correctly. The key is to balance the pursuit of economies of scale with the need for flexibility and customer focus.
Viewing the "platform" as a separate product or value stream can lead to prioritizing internal efficiencies over delivering tangible customer value. Instead of focusing on what customers truly need, organizations may fall into the trap of building elaborate platforms that do not align with actual market demands.
Despite the broad spread of populist ideas that promote platformization and the need for dedicated "platform teams", the long-lasting undesired effects of premature platformization cannot be overstated:
Hindering Adaptability and Innovation
Leading to Lower-Level Org Topologies Archetypes
Overengineering and Waste
Creating Internal Silos and Dependencies
1. Hindering Adaptability and Innovation
Emphasizing platformization can stifle organizational adaptability and innovation by creating monolithic structures resistant to change. This contrasts sharply with higher-level archetypes within the Org Topologies model, such as B2, B3, and C3, which champion adaptability, cross-functionality, and a shared focus on customer outcomes.
2. Leading to Lower-Level Org Topologies Archetypes
For instance, dedicating separate teams to platform development can lead to a "not our job" mentality and hinder value flow. This issue aligns with lower-level archetypes like Y2 ("component development with narrow-specialized teams") and A2 ("hopeful yet entangled teams"), known for their siloed nature and struggles with dependencies. These archetypes often lack the fluidity to adapt quickly to changing market needs, which is critical for innovation.
3. Overengineering and Waste
Premature platformization frequently results in overengineered solutions. Without a validated business model or clear customer demand, organizations risk investing heavily in features and functionalities that are not actively sought after. This approach can lead to significant waste of resources and effort.
4. Creating Internal Silos and Dependencies
Dedicating separate teams solely to platform development can create unwanted silos within an organization. This isolation often leads to misaligned priorities, communication breakdowns, and a "not our job" mentality, ultimately hindering the overall flow of value creation. Such internal silos can disrupt collaboration and efficiency.
Alternative Approaches to Mitigate Platformization Risks
To mitigate the risks associated with platformization, several alternative strategies are recommended:
Validate Your Business Model: Prioritize building successful, customer-facing products first. Only consider platform development when a genuine need for shared services emerges from these validated products.
Promote Shared Ownership: Avoid dedicated platform teams. Instead, encourage a collaborative approach where product teams contribute to platform development as a shared effort. This fosters a sense of collective ownership and ensures the platform evolves in alignment with real-world needs. This resonates with higher-level archetypes like B3 ("interdependent teams collaborating on business value") and C3 ("holistic product development"), which prioritize shared ownership and cross-functional collaboration to deliver customer value.
Focus on Emergent Architecture: Allow the platform to emerge organically based on actual usage patterns and requirements. This iterative approach supports adaptability and prevents overengineering by ensuring development remains closely aligned with real-time needs.
Consider Shared Code Libraries/Services: Instead of building a full-fledged platform, start with reusable code libraries or services that any team can create, co-own, and co-develop.
Whole Product Focus: Avoid creating "value streams" dedicated to internal non-customer-facing concerns, such as platform or infrastructure development. Concentrate on delivering a complete product or its vertical slice that meets customer needs comprehensively. This involves integrating various components and services seamlessly, ensuring that the final product provides a coherent and valuable experience for the end-user. By focusing on the whole product, teams can avoid fragmented efforts and ensure that platform developments align with broader business goals and customer expectations.
Key Takeaway
Approaching platformization as a primary goal is ill-advised. Instead, a more customer-centric, adaptable, and collaborative approach to organizational design and software development is recommended.
By prioritizing validated business models, shared ownership, emergent architecture, reusable code libraries, and a whole product focus, organizations can mitigate the risks associated with platformization and create a more agile and responsive environment for delivering customer value.
Additionally, this approach allows for the realization of economies of scale in a lean manner without sacrificing adaptability and innovation.
This approach doesn't say imply that platforms are not necessary or wasteful in general. This is just a just caution that premature platformization can harm organizational adaptability, innovation and resilience due to the gap between the platform-creating and customer-focused parts of the organization.
Comments