Deploying Kubernetes was the easy part. Building the practices needed to operate it was harder, Marcy Paramonova and Stéphane Cusin said in a KubeCon & CloudNativeCon Europe talk about developing a cloud-native culture in a banking environment.
Cusin said open source was not an obvious choice in their setting: colleagues questioned how support and accountability would work. Rather than relying on arguments alone, the team ran real workloads. In his account, trust grew through the platform’s day-to-day operation.
The first Kubernetes platform gained adoption, but operating it was painful. Responsibilities were unclear, teams used the platform without contributing much to it, and incidents became hurried exercises in finding the right people. The team responded by working on knowledge-sharing, collaboration and ownership, while trying ideas and keeping those that proved useful. Paramonova said many improvements came from bottom-up feedback.
Their approach to the platform also changed. Cusin said the first version exposed many Kubernetes capabilities and let teams customize deployments extensively, producing different patterns across teams. In the current version, he said, Kubernetes is an implementation detail rather than the product. The team instead offers predefined deployment patterns, standardized Helm charts and shared platform capabilities, aiming to make software delivery more consistent when engineers move between teams.
In an interview with InfoQ after the talk, both speakers tied developer trust to what happens in practice. Cusin emphasized transparency and reliability; Paramonova pointed to responding when problems occur and being honest about capabilities that are not ready. She also said Kubernetes gave teams a shared language, though it did not eliminate existing knowledge silos overnight.
Source: InfoQ, published November 13, 2026.