Run Your Platform Like a Business within a Business

This post is excerpted from the 2022 DevOps Enterprise Forum guidance paper The Developer Platform by Rosalind Radcliffe, Charles Betz, Betty Junod, Ravi Maduposu, Luke Rettig, Mark Imbriaco, and Levi Geinert.

The concept of internal capabilities running as “businesses within the business” is not new. Entrepreneurship within the bounds of an organization was termed “intrapreneurship” in 1978 by Gifford Pinchot III. Companies such as MorningStar and Haier have pioneered intrapreneurial approaches and increasingly operate as collections of “micro-enterprises.” More mainstream companies are adopting the same playbook. JPMorgan Chase recently announced that it was assigning twenty-five general managers to act as “mini-CEOs” that will focus IT teams on a product-centric transformation. 

This “business within a business” trend in Agile and DevOps is the primary focus of A Radical Enterprise: Pioneering the Future of High-Performing Organizations, a recent book by Matt K. Parker.

Over the past few decades, a small but growing percentage of corporations have pioneered a new way of working founded on partnership and equality instead of domination and coercion. A way of working that is, as Dr. Eisler puts it, “based on the principle of linking rather than ranking”—where static dominator hierarchies, managers, and bureaucracies are jettisoned in favor of dynamic, self-managing, self-linking networks of teams. As we’ll see shortly, these organizations feature a radical approach to collaboration, grounded in the intrinsic motivation of the participants and formed through the freely given commitments of peers.

Why is this so important?

Developers are critical to delivering new software, and the developer platform offers critical support to your developers as they build and deliver software, ultimately enabling business growth. With that in mind, it is important to treat your internal platform like a product and your developers as customers.

Consider the following five key principles:

1. develop
2. market
3. sell
4. deliver
5. support.

Figure 1: Five Key Principles of Platform as a Product

1. Develop

Development is the entire process: from initial ideation, through the confirmation of direction and product/market fit, to the ongoing maturation of the developer platform. This process is well understood and accepted in product management when developing revenue-generating products but is not applied to products developed for internal customers (namely, developers).

Product managers focus on understanding the market and the competitive dynamics that create an unmet need for their target customers; then they define a product vision that prioritizes features and capabilities. The product/market fit is achieved when target customers/users adopt and buy large volumes of a product.

A key to success is starting your process with a dedicated product manager for the platform, who will measure sales and revenue for the developer platform, identify the target customer, prioritize features and capabilities, and measure business outcomes. In fact, without clearly identifying these, the platform may mismatch expectations and exacerbate any existing friction between teams.

Key considerations in platform development:

• Define the Target Applications: Which applications are you targeting for the platform? Is the goal of the platform to help modernize your existing application portfolio or to enable the development of new applications? Enterprises typically have thousands of existing applications, and their dependencies must be well understood to plan for the right platform functionality to support them.
• Identify the Target Customer/User: Which team(s) will you prioritize the platform for? Large enterprises have many application teams—each using different languages, tech stacks, and generations of technology. Are they all good candidates to start using the platform on day one? Are teams familiar with which practices will be required for the platform?

Clearly defining the platform’s purpose (user and application) helps set platform goals and the direction of its development; from there, functionality can be prioritized and success metrics defined. Additionally, a road map can clearly articulate when different populations (users and applications) can be onboarded based on the availability of new functionality. Investment decisions can be made based on how those capabilities impact the applications addressed.

Case Study: A Platform for Punishment vs. Enablement

Download the full paper for free to read the case study.

2. Market

Marketing to internal customers follows many of the same practices as marketing to external customers, in that the platform team needs to focus on messaging/positioning, awareness, and engagement. In some cases, this can be supported by organizational change management through the HR department (though should not be confused with IT change management). Feedback must also be systematically captured. Consumers of the platform should be regularly surveyed on their experiences and perceptions. Some use Net Promoter Score, sometimes as employee Net Promoter Score (eNPS).

As a product owner, the key point is that the platform owner needs to dedicate time and attention to internal marketing. A strategy of “build it, and they will come” has all too often ended in underused capabilities and even failure.

Proper messaging helps internal teams understand what type of users and applications the platform is designed for, how to start using it, and whom to contact for help. Many organizations use a service catalog or portal to publicize the platform’s existence and value proposition, and facilitate initial access to the service.

Awareness programs need to be designed around proactive outreach to internal teams that promote the availability of the platform, its capabilities, and any success stories. Internal communication tools like organizational newsletters, blogs, wikis, and knowledge management repositories may be useful for posting and sharing information about the platform.

A key part of outreach is engagement. Common practices include asking to speak at regular meetings of other groups, hosting lunch-and-learns, supporting a guild or other form of interest group, and establishing an internal developer-relations (DevRel) function. These forums allow for interactive discussion and bidirectional feedback to the platform team. Through engagement, the platform team can build relationships with key users and start to innersource contributions to the platform. By innersourcing new technology areas or key application differences, teams can onboard the platform with minimal effort, without waiting for someone else to do it for them.

Case Study: Adopting the Concept of a Platform Team

Download the full paper for free to read the case study.

3. Sell

What does “sales” look like for a platform team? It’s unlikely that your internal platform team will have a dedicated sales group looking for funnel opportunities, but there are still analogous concerns between the platform owner and the customer.

Perhaps the most important concern is the terms of the value exchange. IT has long used concepts such as charge-back or cost recovery to provide transparency into who is asking for IT services and for what purpose. Without some mechanisms like this, the IT budget simply appears as a large cost, ripe for cutting. But charge-back is a hard problem. It can result in “dollars chasing dimes,” as accounting for IT activities becomes more and more detailed and costly.

Organizations that are pursuing a platform team strategy, such as Nationwide Insurance, report that they are investing considerably in next-generation cost-recovery practices. However, charge-back and cost recovery can discourage platform use and needs to be implemented with caution. Localized decisions based on charge-back don’t necessarily equate to savings for the company. If the charge-backs are created in such a way that drives consistent work and bursts to an external cloud environment, the cost of the on-premises systems does not go away—the total cost to the organization only goes up. Being transparent about the actual fixed costs and variable costs to the organization is critical for clarity. As part of the value exchange, the platform team can position themselves to “sell” the response times and service levels needed for their application and developer services. Aligning these goals with enabling developers should result in better outcomes than without the platform.

4. Deliver

Delivery is the initial transition from the internal customer to a fully empowered platform consumer. This may include provisioning and training, including communicating major new releases of the platform.

Delivery should be as automated as possible. However, initial provisioning must often include some form of approval for initial access to the automation. (Given security realities, it’s rare that a platform would be open to any enterprise user with no validation whatsoever.) The provisioning process itself can include a few selectable values that can direct the developer to different processes, depending on the requirements or compliance.

And while the ideal is that platforms should be self-explanatory and automated, the reality is that, at scale, usage questions are inevitable. Documentation is required and must be maintained to ensure that functionality and constraints are properly understood. Onboarding and training are advisable or may even be required, especially if there are specific security implications. In larger organizations, learning and development capabilities (often supported via the HR department) may provide essential services and position platform training as part of the broader employee career journey.

Case Study: Large Multinational Consumer Goods Company: Using Product Practices/Techniques to Improve Developer Happiness and Organizational Alignment

Download the full paper for free to read the case study.

5. Support

Platforms can be heavily leveraged and critical to ongoing operations, especially if they directly underpin critical customer- or business-facing services. Platform owners need to set aside appropriate resources, namely budget and staffing, to define a support model. Adopting an internal, customer-success model is critical to this process. While self-service is ideal, any complex digital system will generate questions and occasionally unexpected behavior. Organizations can use instant-messaging channels, internal bulletin boards, and regular incident-management capabilities to identify platform issues. Issues identified in support channels should be routed to the platform team’s backlog and prioritized along with new features. It must be easy for developers to understand what went wrong, and procedures must be established to help them with remediation or with filing an issue.

Understanding the SLAs and SLOs associated with the application teams using the platform is also important. If the application team requires 99.999% (five 9s) availability, the platform team must also be prepared to provide that level of support. Clearly defining the provided SLAs and SLOs for the platform will be critical for teams to set expectations with application teams. Application candidates should align technical functionality and support capabilities to the support the platform team can provide at that time.

Continue reading for The Developer Platform paper for free here.