Platform engineering promised to be the discipline that would finally tear down the silos between dev, ops, and security to help organizations ship better software, faster. But if you are part of a platform team in a large enterprise, you’ve likely experienced a much messier reality: Instead of resolving friction, your platform rollout inadvertently sparked conflicts about shared responsibility. Your team gets dragged into ostensibly technical arguments that are really just masking political opposition.
But process ownership is not the only challenge you are facing. As you roll out your fledging new platform, you face backslash from mature application teams who already have their own established ways of working. Clearly, their established way of working is superior to your immature platform offering.
The true challenge in scaling platform adoption in the enterprise is not technical; it’s diplomatic. To expand successfully, you must pick the right approach. Let’s use a metaphor from Star Trek to examine why centralized platform initiatives often fail in the field, and dive into how a federated approach can turn platform detractors back into allies.
Resistance is futile: The borg approach
In the Star Trek universe, the Borg represent the ultimate centralized platform. They have one goal: total assimilation. They bring every species into a single collective (the Hive Mind) and exercise full control over all activities.
In many enterprises, platform teams accidentally become the Borg. I get it, they run super advanced technology like transwarp drives, they automate everything, … they have quite some interesting qualities. The only problem is, they’re not particularly well-liked in the galaxy. Understandable, considering an encounter with them may result in the end of your personal freedom and becoming a drone. You might rightfully point out that this is the ultimate reduction of cognitive load, but this is exactly the key reason your platform will face fierce resistance.
Let’s suppose you decided your platform supports applications running on Kubernetes. You have a strong SRE team that operates the clusters on the cloud and frees developers from worrying about nodes, ingress and storage. Your platform team now paves a golden path that prescribes using GitHub Actions for CI and ArgoCD for deployments, all tightly integrated with your clusters.
Like the Borg, you now run a rather monolithic but tightly integrated tech stack at massive scale. However, you’ll eventually encounter Species 8472: that one department that is unassimilatable, has completely different technology, and when attempted is capable of destroying your carefully crafted platform from the inside out. It turns out this department has been on the cloud a looong time before your platform team was even formed. They have their own way of setting up clusters, have a complex microservice architecture tightly integrated with an almost telepathic service mesh. Senior leadership heralds them as the pinnacle of the evolution, after all they were the first to migrate to the cloud years ago and they’ve held more KubeCon talks than your team has even attended.
The united federation of platforms
The alternative is the platform federation model. Instead of total assimilation, the Federation focuses on interoperability and common rules. The Federation doesn't tell Vulcans how to meditate, and your platform team shouldn't tell your AI team which Python library to use. It provides a set of common protocols, standard "docking ports" (Identity, Connectivity, Landing Zones), and a shared defense pact (Security Compliance) that allows diverse cultures to thrive while still being part of a larger, cohesive whole.
With a federated platform approach, you aren't trying to build the entire stack for everyone. You are building the foundation that allows other platform teams to build their own specialized platforms on top of yours. This is the principle of subsidiarity: matters are handled by the least centralized competent authority. Your central team shouldn't be building a specialized MLOPs platform if the application teams owning ML intensive applications can do it better. Your job is to provide them the foundational infrastructure that allows them to launch their own expeditions and establish outposts while still plugging into the rest of the enterprise.
Tactical directives for a federated platform
Building the Federation requires more than just good intentions; it requires an architecture designed for empowerment while retaining accountability. Here is how you put the principle of subsidiarity into practice.
1. Establish the cloud foundation
The united federation of planets operates a network of starbases and subspace communication relays supporting its exploration of space. Federated platforms require a similarly robust base layer of infrastructure. This is your cloud foundation.
By providing automated, self-service landing zones, you offer the basic "life support" (networking, IAM, security baselines) that any specialized platform team needs to safely build and operate their own stacks. And unlike Star Trek, we don’t live in a post-scarcity economy, so you’ll also need FinOps. All major hyperscale platforms offer advice and frameworks for building good landing zones. If you need to operate across multiple providers or plan on building a private cloud, cloudfoundation.org provides a platform-agnostic capability based approach.
2. The prime directive: Non-interference and platform diplocmacy
In the Star Trek universe, a civilization must achieve faster-than light travel before they are invited to join the Federation. Until then, members of the Federation vow to refrain from interfering with them.
The Federation doesn’t conquer; it invites. When dealing with mature engineering teams that have their own established ways of working, your first contact protocol should treat this like a diplomatic mission. Like no other character in the Star Trek universe Jean-Luc Picard understood that the key to diplomatic success is to deeply respect and appreciate your counterpart's culture and the values and constraints that shape them. Carrying this spirit, the following tactics for “platform diplomacy” can help turn your first contact into a positive experience instead of a hostile encounter:
Be prepared to invest first: Invest in the relationship by finding ways to take operational weight off your partner’s shoulders. Approach them as allies: teach them, don't preach to them. Avoid the condescending trap of "we have a better tool to do this". To operationalize this, try temporarily embedding one of your engineers with their team. Not only will you gain a deeper understanding of how their team operates, but you will also create the necessary space for them to consider deeper integration with the federation.
Accept that building trust requires time: Start building trust in small increments by identifying shared interests. Don’t overrun your future partners with a 12-month project plan of demands – build on quick wins that create value for your partner and your platform’s users. Some top-down support by executives can help, but remember that at the end of the day a good working relationship is a much more sustainable basis for success.
Bring data, not dogma: Be transparent about your intentions. Instead of vague promises, bring clear numbers and stated goals to the negotiation table: "working together we can cut onboarding for each of the next 50 teams from 12 days to 20 minutes. That shaves two weeks off time-to-production for new services and directly supports the delivery of these strategic iniatives”.
3. Set rules of engagement
In a federated model, we need to establish a common system and protocols for different teams to interface with each other. When talking about enabling “platform on platforms”, the key is to define platform capabilities as a cohesive set of building blocks. A building block is a versioned contract that follows a simple logic: Inputs → Automation → Outputs. Golden paths emerge as a pre-defined or templated composition of these building blocks.
The golden rule: If your platform requires every developer to spend half their day in the engineering room just to keep the ship moving, you haven’t built a platform; you’ve just given everyone an engineering shift they didn’t ask for.
Conclusion: Federate, not assimilate
Adoption fails when platform teams try to be the Borg. The moment you try to assimilate a team that already has a working (but different) process, you've created an enemy.
The Federated Platform approach turns those potential enemies into allies. By providing the substrate and the docking protocols, you allow mini-platform teams to operate specialized platforms while still adhering to the organization's security and cost standards. You move from being a bottleneck to being the foundation upon which the entire enterprise's digital fleet is built.
Thanks to Christian Trolle Mikkelsen and Andreas Grub for their constructive feedback on drafts of this article.
