The Hardest Part of Kubernetes Is Not the Tech

For one bank, the hardest part of adopting Kubernetes wasn't the code. It was building a new engineering culture from the ground up.

In a surprising admission for the highly regulated banking industry, engineers revealed that the technical side of adopting Kubernetes was the easy part. According to a report from InfoQ covering a talk at KubeCon Europe, the real struggle was transforming the company's engineering culture. Speakers Marcy Paramonova and Stéphane Cusin explained that while deploying the container orchestration platform was straightforward, the success of their entire cloud-native initiative depended on solving human challenges. They identified four key pillars for this transformation: building a community of practice, fostering shared knowledge, establishing new rituals, and clarifying team ownership. This focus on people over tools highlights a critical, often-overlooked aspect of major technology migrations in large enterprises.

The bank's strategy for cultural change was intentionally bottom-up, avoiding a rigid, top-down mandate. Instead of prescribing a single way of working, they empowered individual teams to experiment with new processes and tools. This approach allowed teams to discover what worked best for their specific needs, keep the effective practices, and discard the rest. This created a powerful feedback loop of continuous improvement. Central to this model was the creation of a "community of practice," an internal group where engineers could share learnings, ask questions, and develop common standards organically. This method built a sense of collective ownership over the new platform, turning developers from passive consumers of technology into active participants in its evolution.

This experience is not unique to banking; it reflects a broader trend across industries attempting to modernize their technology stacks. Many large organizations, particularly those in finance, healthcare, and insurance, are burdened by legacy structures and siloed teams. A common mistake is the "lift and shift" approach to cloud adoption, where old applications are moved to the cloud without changing the underlying processes or culture. This often fails to deliver the promised benefits of agility and scalability. The bank's story serves as a powerful case study demonstrating that true cloud-native transformation requires a fundamental shift in how teams are organized and how they collaborate. It is a move from project-based thinking to product-oriented ownership, a difficult but necessary evolution.

For CTOs and engineering leaders, the key takeaway is that a successful platform strategy requires as much investment in people as it does in technology. Before embarking on a large-scale Kubernetes adoption, leaders should first assess their organization's cultural readiness. The focus should be on creating an environment of psychological safety where teams feel empowered to experiment and even fail without blame. Building forums for knowledge sharing, such as internal talks or dedicated chat channels, is crucial. Ultimately, the goal is to treat the internal platform as a product with its developers as customers. By focusing on developer experience and fostering a collaborative Kubernetes culture, organizations can unlock the full potential of their technology investment and avoid the common pitfalls of modernization.

This case study shows that platform engineering is a socio-technical challenge, not just a technical one. For engineering leaders, it proves that the success of tools like Kubernetes hinges on investing in developer experience, shared ownership, and a culture that supports experimentation.

Ignoring the cultural side of a tech migration leads to wasted investment, slow adoption, and developer burnout. Building the right culture accelerates innovation, improves system reliability, and helps attract and retain top engineering talent, creating a significant competitive advantage.