From Building Platforms to Delivering Capabilities: KubeCon + PlatEngDay EU 2026 Summary
- Daniel Bryant
- 3 hours ago
- 6 min read
We’ve just arrived home after an exciting few days in Amsterdam for KubeCon EU 2026. Thanks to everyone involved for making this a conference to remember.
The main event and the colocated Platform Engineering Day this year felt familiar in many ways. The rooms were full, and the conversations were buzzing. We also saw many familiar themes, such as golden paths, internal developer platforms, and building platforms as a product.
But there was a noticeable shift in what people were actually talking about. Not new tools (except for a few AI tools!). Not new frameworks. Not even new abstractions. Instead, the focus has moved to something more fundamental: why is it still so difficult to make platforms work in practice?
We’re no longer asking how to build a platform. We’re asking why, after building one, delivering value through it remains such a challenge.
From Platforms to Capabilities
One of the clearest signals across both events was a shift in focus from the platforms themselves to the capabilities they provide. Abby's keynote, "From Cloud-Native Apps to Cloud-Native Platforms," explored this concept and provided references for emerging community solutions:
Talks on golden paths, backend-first IDPs, and extensible platforms all pointed in the same direction. The emphasis wasn’t on standing up infrastructure or wiring together tools. It was on defining, delivering, and evolving platform capabilities in a way that actually helps developers.
This is an important distinction. Platforms are no longer judged by what they are. Instead, they’re judged by what they reliably deliver.
A platform with a polished UI but inconsistent or fragile capabilities doesn’t succeed. Equally, a platform built on solid infrastructure but lacking clear, usable interfaces won’t gain adoption. The unit of value is the capability, and increasingly, the challenge is not creating those capabilities, it’s operating them over time.
Day 2 Is Where the Real Work Happens
At Syntasso, we’ve been talking about “Day 2” for a while. But this year, the tone changed. Sessions like Cat's panel "Scaling Platform Engineering: Lessons From Europe’s Largest Enterprises" with Stéphane Di Cesare, Anna Kozachenko, and Gayathri Thiyagarajan didn’t just acknowledge the importance of Day 2; they explored where things go wrong.
The pattern is consistent: Initial platform demos go well, early adoption looks promising, and then reality sets in. Capabilities need to be updated, dependencies change, user expectations evolve, and support requests grow. This is where platforms are tested.
Cat and Nitish dived deep into this in their talk, "The Day 2 Hangover: What To Do After the Platform Party Ends."
The complexity isn’t in provisioning infrastructure; it’s in maintaining and evolving it safely, across multiple teams, over time. That’s why platform capability lifecycle matters:
Versioning
Upgrades
Deprecation
Rollout strategies
It’s also why platform engineering doesn’t stop at delivery. In many ways, that’s where it really begins.
The Bottleneck Isn’t Kubernetes
Another consistent theme was a reframing of where the real challenges lie. Kubernetes is no longer the primary concern for most teams. It’s become a relatively stable foundation. Instead, the friction shows up in everything around it:
Defining workflows
Managing ownership
Coordinating teams
Enforcing governance
As Abby mentioned in her keynote, the bottleneck was never Kubernetes; it was everything surrounding it.
This aligns with the broader shift towards recognising platform engineering as a sociotechnical discipline. The hardest problems aren’t purely technical. They’re about aligning incentives, enabling collaboration, and balancing autonomy with control.
This is why concepts like inner sourcing, platform ownership models, and shared responsibility came up repeatedly. Building a platform is one challenge, but operating it within an organisation, particularly an enterprise, is another.
AI Is Changing Where Platforms Add Value
AI was everywhere at KubeCon EU, but not in the way it might have been a year ago. There was less focus on novelty and more on practical implications.
One insight from Paula in the panel "How Platforms Can Save Junior Engineers (and Thus the Tech Industry)" with Jennifer Riggins, Leena Mooneeram, and Molly Clarke stood out: As AI accelerates software development, the bottleneck shifts from writing code to verifying and deploying it safely.
This has significant implications for platform teams. More code is being generated, faster than ever before. But that increases the need for:
Validation
Guardrails
Policy enforcement
Controlled rollouts
Platforms become the layer that ensures this increased rate of change doesn’t introduce instability. In this context, platforms aren’t just enabling development; they’re governing it. This is where platform engineering provides real value in an AI-driven world.
Platform as a Product Has Moved Into Execution
There was a time when “platform as a product” needed explaining. That’s no longer the case. At both events, the conversation has moved on.
Instead of discussing what it means, speakers focused on how to apply it:
Measuring success
Gathering feedback
Prioritising work
Iterating based on user needs
There’s a growing recognition that adopting a product mindset introduces its own challenges. Platform teams now need to make trade-offs. They need to decide what to build next and how to balance competing user needs. The idea has been accepted, and now teams are working through what it takes to apply it at scale.
Portals Are Part of the Experience; Not the Platform Itself
Another subtle but important shift is how portals are being positioned: we bumped into the question of whether the P in IDP stood for “portal” or “platform” quite a few times at the booth!
Developer portals remain a key part of the platform experience. They provide a valuable interface for discovering capabilities, understanding ownership, and enabling self-service. But they are increasingly being seen as one way of interacting with the platform, and not the platform itself.
Different developers prefer different workflows:
Some use UI-driven portals
Others work via Git
Others rely on CLI tools, APIs, and MCP
Modern platforms need to support all of these, with an increasing focus on enabling AI, as Shane mentioned in his talk, "Lessons from Putting AI in Front of a Platform: Taming the Non-Deterministic Beast":
This leads to a more flexible model in which the same underlying capabilities are accessible through multiple interfaces.
There’s also a growing recognition, reflected in thinking like Cortex’s Engineering Ops manifesto, that improving developer experience goes beyond providing a UI. It involves clear ownership, well-defined interfaces, discoverability, and reliable systems behind the scenes.
The interface matters, but it’s only one layer of the overall experience. The real challenge is ensuring that, regardless of how a developer interacts with the platform, they are accessing consistent, well-operated capabilities.
Sovereignty, Regulation, and Control
KubeCon EU also highlighted themes that are particularly relevant in a European context. Across several keynotes, there was a strong focus on:
Digital sovereignty
Regulatory requirements
Multi-cloud strategies
National infrastructure platforms
These aren’t abstract concerns. They directly influence how platforms are designed and operated. Organisations need to balance flexibility in where workloads run, control over how they are managed, and compliance with evolving regulations.
This has clear ramifications for open source projects:
This also adds another layer of complexity to platform engineering. It’s not just about enabling developers; it’s also about doing so within clearly defined constraints.
Bringing It Together: What This Means for Platform Teams
Taken together, these themes point to a clear shift. The challenge is no longer building platforms; it’s about orchestrating how capabilities are defined, delivered, evolved, and operated across an organisation.
This requires:
Strong lifecycle management
Alignment across teams
Flexibility in how platforms are consumed
Systems that can handle continuous change
For platform teams, the implications are practical. It means focusing less on assembling tools and more on designing capabilities that can evolve, supporting multiple interaction models, enabling contributions from across the organisation, and maintaining consistency at scale.
It also means recognising that success isn’t measured by platform adoption alone, but by how effectively developers can use the capabilities provided.
Closing Thoughts
Platforms don’t succeed because they exist. They succeed because they consistently deliver what developers need, speedily, safely, efficiently, and at scale. That’s the shift we’re seeing now. And it’s where platform engineering continues to evolve.
Thanks again to all the speakers at the event, the attendees, the sponsors, the organisers, and everyone who dropped by our booths for a chat. We look forward to seeing you at the next one!
And if you want to learn more about Syntasso Kratix Enterprise (SKE), the benefits of an enterprise platform orchestrator, or joining the team, please contact us!
Comments