Platforms: Finding the Balance Between Enablement and Control

Developer platforms emerge from a legitimate need: teams shouldn't waste time solving the same problems repeatedly. Authentication, logging, monitoring, deployment pipelines – these are all capabilities that benefit from centralisation and standardisation. However, the temptation to continually add features to the platform can lead to "platform bloat," where the platform becomes increasingly complex and prescriptive, ultimately undermining its original purpose.

When Good Platforms Go Bad

The path from helpful platform to hindering bottleneck often follows predictable patterns. Consider a platform team that decides to standardise on a specific frontend framework and component library. While initially beneficial, two years later when new framework features or alternatives emerge, teams find themselves unable to adopt them without significant platform changes. What was meant to accelerate development now impedes progress.

Similarly, platforms often implement database abstraction layers to simplify data access. While these work for common cases, teams building high-performance features find themselves fighting against the abstraction, often building workarounds that add complexity rather than reduce it. The same pattern emerges with deployment pipelines – what works perfectly for web services becomes a constraint for teams building real-time processing systems with different deployment needs.

When Should Something Belong in the Platform?

A healthy developer platform is about enabling teams—not controlling them. Instead of defaulting to "put it in the platform," organisations should use clear heuristics to determine what should be standardised versus left flexible.

Netflix's approach to their microservices platform provides valuable lessons in platform design. While their platform standardised many aspects of service development, they intentionally kept certain decisions, like database choices, outside the platform's scope. This allowed teams to optimise for their specific use cases while still benefiting from platform capabilities where standardisation made sense.

This mirrors the open-source world's "small core" principle. The Linux kernel maintains a relatively small core while pushing many features into modules and user space. This approach allows for rapid innovation at the edges while maintaining stability at the core – a principle that translates well to internal developer platforms.

When to Standardise:

High Coordination Costs → Standardise

If multiple teams must frequently align on a problem (e.g., security policies, authentication), centralising it in the platform reduces friction. Example: A unified role-based access control (RBAC) system simplifies permission management across teams.

Undifferentiated Heavy Lifting → Standardise

If teams must repeatedly solve the same infrastructure or compliance problem, the platform should handle it. Example: Cloud provisioning, secrets management, and API gateway configuration.

Security, Compliance, and Stability Risks → Standardise

Anything that, if misconfigured, poses a major risk should be enforced at the platform level. Example: Enforcing TLS and secure network boundaries.

When to Leave to Teams:

Frequent Innovation & Experimentation → Leave to Teams

If teams are actively evolving how they solve a problem, forcing a platform-wide standard too early can kill innovation. Example: A/B testing frameworks—different teams may need different experimentation methods.

Divergent Needs Across Teams → Leave to Teams

If different teams have fundamentally different requirements, a one-size-fits-all solution will create more problems than it solves. Example: Frontend frameworks—some teams may need React, while others use Web Components.

Tightly Coupled to Business Logic → Leave to Teams

Anything deeply tied to how a product works (as opposed to how software is delivered) should remain in the domain of the teams. Example: Recommendation algorithms—should not be standardised across teams, as different products have unique needs.

Forcing Functions: Platform Success Metrics

A platform's success extends beyond simple adoption metrics. Effective measurement requires understanding the platform's impact across multiple dimensions. Developer productivity should be tracked not just in time saved, but in the ability to deliver features without platform-induced delays. Platform health involves more than uptime, it includes adoption rates, the number of approved exceptions, and the frequency of workarounds.

The business impact proves equally important, measured through cost savings from shared solutions, security incident reduction, and compliance audit success rates. These metrics together paint a picture of whether the platform truly enables teams or simply adds another layer of complexity.

Moving Forward

A good rule of thumb is "small core, extensible edge." Platforms should provide a solid foundation of common capabilities while allowing teams the freedom to innovate where it matters most. The platform should be an accelerator, not a straitjacket.

The most successful platform teams operate like product teams, with internal development teams as their customers. This means regular engagement with development teams to understand their pain points and needs. Platform teams must maintain a clear value proposition, demonstrating concrete benefits and being transparent about tradeoffs. They should continuously evolve the platform based on team feedback, regularly evaluating features, deprecating unused (or inefficient) capabilities, and adding highly-requested functionality.

Remember: Every feature added to the platform is a long-term commitment to support and maintain that feature. Choose wisely what goes into the core, and create mechanisms for teams to extend and customise outside of it. The goal isn't to solve every problem but to make the right problems easier to solve.