Platform Monopolies and the Decay of Leverage

Build the platform your developers want to use, not have to use

There are two reasons why internal, proprietary software platforms are used by engineering teams in the company:

1. They want to use it, because the software platform is highly attuned to (usually) application developers’ domain-specific needs, and proactively solves common technical or business needs for them
2. They have to use it, either through organizational mandate or decree, or because the cost of using an alternative, superior, offering is too high. This cost can manifest in terms of OpEx, migration cost, compliance gaps, or poor integration with common developer workflows.

In the latter case, platform teams effectively operate a monopoly¹ within their solution space.

While a good platform steers its customers into opinionated and effective solutions for their tasks, it is entirely possible that the key differentiator of a platform technology versus alternatives is that it’s too expensive to use anything else. This might be due to the inherent efficiency of its purpose-built, domain-aware solution. Or the entrenchment of the technology in the application codebase and data layer. A statement like “our platform supports 90% of the company’s products” doesn’t necessarily equate to either customer endorsement or positive business ROI if it’s the result of internal vendor lock-in.

Although most platforms get built for noble reasons, over time, the value of the platform compared it its cost to operate and extend may follow very different trajectories | from chart.xkcd

What’s happening here?

Failure to Out-Innovate Alternative Solutions

Internal platform teams have a major advantage over SaaS or general 3rd party vendors: they (should) know exactly how their products are being built and what constraints are being imposed on those teams, while also having access to information about industry trends and technology advancements.

Failure to do so, over time, may be a function of:

• Inadequate platform staffing, relative to the scope and size of the customer set (platforms are never “done”, they must evolve)
• Fundamental architectural or domain modeling failures in the platform itself, leading to constant attention on fixing the platform rather than improving it
• Related, combinatorial customer-side code complexity trying to fit the platform into application use-cases, resulting in high customer effort and near-impossible application migration scenarios
• Lack of attention to the broader technology landscape and its applicability to the business
• Lack of attention to forward-looking customer needs, causing problems of both value and narrative, discussed below

Poor Communication and Alignment

Effective platform leaders understand that part of their job is to continually prove to their internal customers that they are listening to their needs and actively outcompeting alternative solutions based on a variety of dimensions important to the business.

The main things these customer teams tend to care about is whether the platform is easy to learn, easy to use, and solves real problems. In the case of product teams, this is because their incentive structures are aligned with short-term business metrics impact, so rapid building, easy experimentation, and cheap throwaway is key. Failure to accommodate or address these needs leads directly to failure.

Critique of internal platforms often sounds like:

We’d rather use SaaS product X directly from vendor Y

While that might make logical sense from a narrow perspective, would the customer teams and their org leads be willing pay for the operation of those capabilities at 5x the TCO? Depends on the context, but probably not. The answer is highly dependent on whether they trust the platform leadership team. But the narrative remains.

This forms a tension for platform teams: sometimes the bigger picture demands attention to things not always visible to their customers, but may benefit the company more broadly:

• Investments into scaling, to avoid customer outages and facilitate large capacity requests
• Redesign of metadata subsystems, to more easily support annotation and lineage of fields for privacy-related outcomes
• Kubernetes bin packing, to consolidate resource usage and reduce waste in the compute stack

These are all important, and perhaps more important than any independent set of customer team demands.

So if this is the case, the customer teams need to understand why it’s the case, and how investment into things like scalability eventually benefits them (more serving / storage capacity; fewer bespoke application-side workarounds, etc). Strong platform-customer relationships are more than ticket-taking and the delivery of bespoke features. Strategic customers need to be brought into context for the platform’s broader strategy and its balancing of other long-term company inputs.

Failure to do so results in two things:

• Complaints to platform leadership about the quality of the platforms, directly from customer teams, but also up-and-across the organization tree, from product development leadership
• The introduction of rogue alternative solutions by the application teams, often in a fragmented and unsustainable fashion, which become platform team problems in the long run

These are ultimately platform domain-owner problems to solve.

Software platform teams need to avoid the creating the impression within their internal customers that they are complacent operating their organizationally-granted monopoly. This is through

• Understanding where the broader industry is going, and predicting how that may influence their customers’ thinking
• Funding internal platforms for continuous improvement rather than just build-out
• Communicating with with their customer teams and staying ahead of their needs, whenever possible
• Focusing on the largest opportunities for the overall business within their problem domain, aside from delivery of specific customer requests
• Incorporating their major customers into their strategy and decision-making process about their short and long-term investments, to share context about why customer-facing features are delayed, or not
• Adequate team funding to ensure the platform continues to innovate and stay ahead of the value/lock-in cost curve
• Managing the amount of bespoke platform-interfacing code within customer codebases

Otherwise, what once was a high-leverage solution ends up being a development tax defeating both product iteration and platform efficiency goals. Build the platform your developers want to use, not have to use.

[1] More specifically a government-granted monopoly