Framing so-called Technology Platforms from an organizational perspective is a common problem in organizations with a substantial technological advantage in technology and hardware-intensive markets.

 

What are Technology Platforms?

It’s common to use such terms to describe the mix of R&D and Manufacturing capabilities for organizations that offer a variety of products and services based on relevant hardware components with a significant technological component to market.

An automotive platform could be a good example, as it can reduce the cost of producing different vehicles and achieve cross-model economies of scale and efficiencies. Similar examples exist in aerospace, defense (see the success of companies like Anduril), healthcare, etc.

Developing modular technology platforms enhances flexibility and shortens the time to market for product variants. It can also help produce one-off solutions for specific customers.

Due to a market shift towards vertical integration, technology platforms are increasingly important. In a recent two-installment article, analyst Packy McCormick described vertical techno-industrial integrators:

 

Vertical Integrators are companies that:

1. Integrate multiple cutting-edge-but-proven technologies.
2. Develop significant in-house capabilities across their stack.
3. Modularize commoditized components while controlling overall system integration.
4. Compete directly with incumbents.
5. Offer products that are better, faster, or cheaper (often all three).

 

For Vertical Integrators, the integration is the innovation.

According to McCormick, vertical integrators gain an advantage by integrating commoditized components, developing modular architectures, and controlling the supply chain. This is a general pattern across industries. Some may also have to develop a competitive advantage in technology capabilities rather than just system integration.

What’s the issue with traditional organizational structures?

Technology departments have long been interested in modularization for many reasons. It can reduce and distribute the burden of managing and evolving a technological component and help distribute responsibility for innovation across teams. Furthermore, modular technologies are easier to recombine when responding to requirements.

Modularity is a holy grail for tech companies. The concept of “refactoring,” born in the software realm, can easily explain why the modularization problem is hard to tame.

In his newsletter “Software Design: Tidy First?”, Agile legend Kent Beck has an article “To Design or Not To Design?” explaining why modular design is simultaneously a key advantage and a pitfall:

Consider two design styles: connected and modular. In a connected system, elements are highly available to each other (via global state, for example). Adding the first feature to a connected system is cheap. All the resources you need are available. However, the cost of all those connections is that subsequent features are very likely to interact with previous features, driving up the cost of development over time.

A modular design has connections deliberately kept to a minimum. The cost for the first feature is likely to be higher than in the connected system because you need to find the necessary resources and bring them together, possibly re-modularizing in the process. Features are much less likely to interact in a modular system, though, leading to a steady stream of features at relatively constant cost.

Here is a conceptual graph of the cost of adding features in the two design styles (I say “conceptual” because the graph displays a way to think about the differences, it doesn’t display data):

 

 

 

Beck advises against embracing modular design from the start with software because refactoring has a reasonably manageable cost, and focusing too much on modularity early on can harm the organization’s experimentation capability.

With techno-industrial integrators, though, the picture could be more complex as the cost of refactoring a hardware, tech-intensive system is usually much higher than with software, and customer replacement cycles are usually very long: no customer will swap a nonmodular tech platform for a modular one, once installed, to allow your company to reduce maintenance costs or optimize manufacturing costs.

Due to the lack of modularity focus, long replacement cycles and high investments have been historically managed by vertically integrating the organization into bureaucratic, rigid structures. Tech-intensive companies often adopt divisional or matrix structures. Divisions manage product lines rigidly, often with functional replications.

Advancements in technology and digital design have enabled modern techno-industrial integrators to develop modular platforms from the beginning. Technological departments, pressed to respond to niche customer needs captured by their go-to-market departments (the need for personalization is another significant driving force for the platform economy, along with technological progress), have embraced modular approaches, encouraging the rest of the organization to adopt a connected “platform organization” model to reflect and leverage the new capabilities, providing shorter Time To Market, easier product line creation, and lower manufacturing costs.

 

Using a Platform Organization Setup for Technology Platforms

Using a platform-organization setup in technology-intensive vertical integrators can provide substantial advantages and counteract the typical rigidities.

Customer needs should influence technology platform development roadmaps, but avoid direct influence of specific requirements and organizational politics. These can misdirect development away from long-term adaptability.

A technology platform typically gives the organization a unique competitive advantage. Therefore, organizations prevent these units from directly connecting with the market, potentially serving competitive players.

In a platform organization, it’s common to configure technology platform units as Node Micro-Enterprises, i.e., entrepreneurial units that manage their P&L and negotiate agreements with the rest of the organization.

Node MEs are often hired by product units that:

• combine technological solutions with services (like customizations, post-sales, etc.)
• create various business models (solution sales, rentals, per-use….)
• facilitate the collection of local, context-specific, or vertical needs

Depending on the organization, product units can be more or less autonomous in reaching the market, sometimes complemented by an org-wide sales organization.

The cost of refactoring and the need for relevant “upfront modularity” in non-software-centric technology platforms make it important to frame the management of Profit and Loss and investment cycles.

Units using the platform-as-a-product technology should have a role and stake in its development. Generally, as outlined in the following graph, a combination of a high cost of refactoring (mirroring a long investment cycle) and a common technology platform serving different product units/business lines justifies organization-wide investment in platform development (1 in the picture).

 

 

 

When technological intensity is high, but there’s little or no cross-unit technology reusability across units, the organization should embrace an Industry Platform (IP) pattern. IPs are 3EO/Rendanheyi artifacts (the 3EO is Boundaryless‘s framework for the platform organization co-developed with Haier Model Institute) that are normally adopted to distribute an organization’s investment capacity into business sectors. Each industry platform is a “sub-organization,” using Shared Services Platforms for support services (typically HR, IT, Legal, and Finance…) but managing investment cycles autonomously (2) at times even mimicking some Venture Capital behaviors.

When refactoring costs are low (e.g., with software-centric platforms), client units can easily negotiate with the platform development directly for personalizations. This makes platform development cheaper and the relationship more transactional. It will be less complex for the platform unit to develop personalizations, and the platform unit itself can entertain different contracts with product units, creating an internal portfolio process to triage requests into a consolidated platform roadmap (3). Suppose technology development and refactoring costs are low and technologies have low cross-unit reusability. In that case, it’s probably worth it for the product units to embed the technology development or sourcing it from the market.

In such a case (lower refactoring costs, software-centric platforms, componentized platforms), the whole idea of a technology platform doesn’t apply much as a start.

As a recap, we offer the following illustration for a potential Technology-platform-driven organization setup:

 

 

This picture shows alternative patterns (that could also co-exist):

• On the left, an Industry Platform (for example, Marine) is set
• It contains two subunits/business units (for example, Leisure Motorboats and Port Operations Motorboats)
• Inside the IP1, a Tech-Platform Node MicroEnterprise (for example, one developing modular hulls) where both MEs mentioned above do both long-term investments to influence the roadmap and shorter-term contracts, for example, to respond to certain tenders
• Outside the IPs, there’s a Manufacturing Shared Services Platform
• On the right, another IP (IP2) (for example, Automotive)
• Both IPs invest in a shared Tech-Platform Node MicroEnterprise (for example, Diesel Engines)
• Go-to-market interfaces are scattered and made visible in red. The yellow GTM interfaces are highlighted as potentially dangerous, diverting attention from competitive advantage-providing units.

In this setup, Go-To-Market and P&L management are the most complex issues. Despite the efficiencies of centralizing go-to-market in a Shared Services GTM platform, developing a Sales Force for technology-intensive industries is complex. Most sales cycles require specific ground coverage and long-term relationships. Multiplying Go-To-Market interfaces can yield notable benefits.

Often, both Product units and Technology Platform units can explore new go-to-market strategies to boost revenue and gain more skin in the game. This could result in new market avenues that traditional sales channels might miss due to their focus on existing methods. For instance, a technology unit sourcing skills or material through a new ecosystem might market excess capacity through the same channel or find new, less sales-intensive go-to-market options, like digitally enabled marketplaces that don’t require traditional sales activities.

These alternative go-to-market strategies can lead to unexpected opportunities and innovations. By allowing both product and technology units to explore new channels, organizations can tap into previously untapped markets and customer segments. This approach fosters a more entrepreneurial mindset throughout the company, encouraging units to think beyond their traditional roles. Additionally, it can help the organization become more responsive to market changes and emerging trends, as different units can quickly adapt their strategies based on direct market feedback.

Conclusions

Today’s article explores the complexities of technology platform management within platform organizations. It emphasizes balancing centralization and decentralization, considering cross-unit reusability, refactoring costs, and industry-specific needs. By adopting a flexible approach to platform management, organizations can foster entrepreneurial mindsets, adapt quickly to market changes, and tap into new customer segments and revenue streams.

This overview of implementing a platform organization model in tech-intensive contexts is not exhaustive. Implementing a platform-based structure depends on each organization’s unique context and culture. Influencing factors include:

• Industry and market dynamics
• Company size and maturity
• Existing organizational structure and processes
• Leadership style and vision
• Workforce skills and adaptability
• Technological infrastructure and capabilities
• Regulatory environment and compliance requirements

When transitioning to a platform-based model, organizations must assess their needs, challenges, and goals. The strategies and practices outlined in this document should be seen as a starting point for discussion and adaptation rather than a one-size-fits-all solution.

A thoughtful, iterative approach that aligns with the company’s values, objectives, and vision is required to successfully implement a platform organization. Organizations should be prepared to experiment, learn, and adjust their platform strategy as they navigate the complexities of this model.