How a bank built platform trust with open source, not mandates

Key Takeaways

• Trust in platforms comes from predictable behavior, not feature lists
• Open source provided a common language between teams, vendors, and tools in a banking environment
• Ownership and transparency, not top-down mandates, drove cultural change

Engineers trust a platform because it behaves predictably, not because it has impressive features. That was the core message from Marcy Paramonova and Stéphane Cusin at KubeCon & CloudNativeCon Europe, where they described how their bank adopted open source tooling without any management mandate to do so.

Their talk, "Building Cloud Native Culture in a Bank," reframes platform engineering as a collaboration system rather than a technology stack. Both speakers work in an environment where trust is the default requirement, and they found that open source gave them something they desperately needed: a shared standard and common language across teams, vendors, and tools.

Why open source was not obvious for a bank

Banks face unique constraints around support, accountability, and regulatory compliance. Open source raised immediate questions in their environment. Who do you call when something breaks? Who is accountable for security patches?

Cusin's answer: trust is not a decision you make once. It is built by operating the platform day after day and through consistency. The platform team earned credibility by standardizing deployments across development, testing, and production environments. Whether a team deploys to dev or prod, the experience and expectations stay the same.

They made platform responsibilities explicit. Teams know which services the platform team operates, what service levels they can expect, and where their own operational responsibilities begin. This clarity reduced friction and set realistic expectations.

Reducing cognitive load instead of exposing every option

A common mistake in platform engineering is exposing every Kubernetes capability to application developers. Cusin's team took the opposite approach. They provided sensible defaults and opinionated workflows, so developers could focus on their applications rather than understanding the complexity of the underlying infrastructure.

This is a practical choice. Kubernetes is powerful, but that power creates overhead. Most application teams do not need to understand Ingress controllers, service meshes, or custom resource definitions. They need to deploy code reliably and get consistent feedback when something fails.

The Genius Bar model for platform support

Paramonova described an approach they called Genius Bar sessions. The platform team stepped back from standard support tickets and offered open sessions where developers could come with problems and solve them together.

The format caught on. Over time, infrastructure teams started joining these sessions, expanding the collaboration beyond the platform team. This model treats developers as collaborators rather than ticket submitters. It also creates opportunities for knowledge transfer that tickets never capture.

Paramonova emphasized that engineers benefit from upskilling their soft skills. Technical competence matters, but the ability to communicate, teach, and collaborate determines whether a platform team actually helps or just operates infrastructure.

Ownership changed engagement

The speakers described a community-driven approach where engineers create clubs or communities around specific technologies and maintain them. This shifts ownership from the platform team to the broader engineering organization.

"They are not only trusted to execute tasks, but also trusted to make real decisions and have a real impact," Paramonova said. This distinction matters. When engineers feel like implementers following instructions, engagement drops. When they own outcomes, they invest differently.

Being an engineer, she argued, is about problem-solving and sharing that passion. Open source communities embody this. They document decisions, contribute back, and make ownership explicit so people know who maintains a component and who makes decisions.

Transparency over polish

When introducing new components or features, Paramonova's team did not wait for perfection before sharing. They gave users visibility into what they were building and why. Users became early testers and collaborators rather than passive consumers.

"That relationship built something that a release announcement never could," she noted. This approach requires accepting that early versions will be rough. It also requires users who understand they are seeing work in progress. But the payoff is a user base that feels invested in the platform's success.

Open source as compass, not dogma

Cusin was clear that open source was never a management directive. Nobody told them they must use open source. It was a compass, something that helped them orient decisions. If you only change tools but not how people think, collaborate, and build, you will hit a wall.

Adopting Kubernetes, he argued, is not just adopting a container orchestrator. You are joining a community with norms, expectations, and a way of working together. That cultural pull toward transparency and collaboration shaped their internal practices.

Frequently Asked Questions

How do platform teams build trust with developers?

Through predictable behavior and consistency. Deploy the same way in development as in production. Make responsibilities and service levels explicit so teams know what to expect.

What is a Genius Bar session in platform engineering?

An open support session where developers bring problems and solve them together with platform engineers, replacing traditional ticket-based support with collaborative troubleshooting.

Why do banks use open source for platforms?

Open source provides a shared standard and common language across teams, vendors, and tools. Trust is built through consistent operation over time, not vendor contracts.

How does ownership affect platform adoption?

When engineers are trusted to make real decisions rather than just execute tasks, engagement increases. Community-driven ownership of components distributes responsibility and investment.

Source: InfoQ