A platform is a collaboration system, not infrastructure. Culture follows structure: platform teams can build open support sessions, create super user awards for contributing developers, and establish shared open standards to grow an engineering mindset, Marcy Paramonova and Stéphane Cusin explained in their talk Building Cloud Native Culture in a Bank at KubeCon & CloudNativeCon Europe.
Developers and product teams depend on a platform team, Paramonova said. The platform team depends on application teams, and both need to go forward; for that, they need shared standards.
A platform is not a piece of infrastructure; it’s a collaboration system through which lots of communication goes, Paramonova and Cusin explained in How Open Source Enables Collaboration in Creating a Platform.
Cloud native is a cultural shift, not just a technical one; their transformation journey also required a cultural shift, Paramonova argued. The platform team started offering open support sessions where developers could come, and they could solve their problems with them:
We wanted to step back from the usual support for driver tickets and offer something new and fresh to our users. Many people got interested, including infrastructure, cybersecurity, network, identity, and cloud teams. We sit together, share solutions, and help to solve problems collaboratively.
If every action required a ticket, manual intervention, or direct support from a platform engineer, we would unintentionally create a culture of dependency, Cousin said. Teams would wait for the platform team instead of learning and operating independently.
Paramonova mentioned that they created events to recognize adoption of their platform. They introduced super user awards for developers who actively contributed to improving the platform:
Their feedback, sometimes hard to hear for us and a little bit painful, actually helped us to create something more beautiful and better. So we’re grateful for that.
The activities they organized changed how they perceive and value human skills.
When you use open source with open standards, your skills become very transferable, Paramonova said. You don’t relearn something from zero; you build on a shared foundation that’s shared across the open technologies, she added.
An engineering mindset is the most important thing, Paramonova argued. It’s not what you know today, but your capacity and ability to take new technologies, to learn them, to execute and to operate them:
Being an engineer is about problem solving, being passionate about that, and sharing your passion about problem solving.
Culture follows structure. You cannot wait for culture to emerge on its own; you have to design systems that create the culture you want, Cousin explained:
If your team complains about being interrupted all the time, don’t blame the other team. Ask yourself: have you defined a structure for people to reach out to you?
Kubernetes transformed more than our platform. It transformed how our organization builds software, Cousin concluded.
InfoQ interviewed Marcy Paramonova and Stéphane Cusin after their talk.
InfoQ: How did your engineering culture shift over time?
Stéphane Cusin: One principle we established from day one was that platform capabilities should never depend on manual intervention. Instead of opening a ticket and waiting for an engineer to make a change, teams interact with the platform through declarative configuration and automated workflows. For example, enabling a capability can be done through a simple configuration change in Git, which is automatically applied by our GitOps process. This creates a self-service experience while providing full traceability and visibility into platform adoption.
This approach changed how we operate the platform. We can now understand which capabilities are being adopted, which ones are no longer needed, and which users are affected by a change. It has already allowed us to safely retire unused features and migrate teams toward newer platform capabilities with confidence.
InfoQ: How did you design systems that create the culture that you wanted to establish?
Marcy Paramonova: You cannot mandate a culture into existence, but you can design structures that make certain behaviors natural. For us, that meant building rituals around collaboration rather than just talking about it.
We run a "Genius Bar" twice a week, two hours each session. If you have a question about the platform, if something is not working the way you expected, if you just want to understand how a component fits together, you come there. No ticket, no waiting for someone’s calendar to open up. It keeps feedback loops short, and it keeps us honest, because you hear very quickly when something is confusing or painful.
We also run user insights sessions where we share priorities, work done, and visibility gained, and we prioritize together with users rather than for them. And we do demos, showing what is shipped, what is on the roadmap, and how to actually use the platform day today.
Internally, the platform team has its own planning sessions to stay aligned and to make space for deliberate decisions, rather than just reactive work.
None of this is revolutionary. But when you stack these rhythms together, the culture you want starts to emerge from the structure you build. It is not magic, but it is also not accidental.
Cusin: We tried to make platform decisions visible. Platform capabilities are delivered through versioned artifacts, reusable deployment patterns, and documented interfaces rather than individual agreements between teams. This creates consistency and shared understanding across the organization.
Another important design principle was that every platform feature should have a lifecycle. We wanted to know who was using a capability, how it was being used, and whether it was still providing value. That visibility allows us to evolve the platform intentionally instead of accumulating complexity over time.
In many ways, our platform became a mechanism for reinforcing the behaviors we wanted to encourage: self-service over ticket-driven operations, standardization over customization, transparency over tribal knowledge, and shared ownership over dependency on a few experts.
When those principles are embedded into the platform itself, the desired culture becomes the easiest way for people to work.