[header_ad_block]

Bengaluru, 24th October 2025: Leading transitions from traditional data centers to multi-cloud infrastructures is more than a technical challenge, it’s a full-scale business transformation. In this conversation, Mr. Sivakumar shares hard-earned insights from orchestrating migrations across AWS, Azure, and GCP, highlighting lessons every tech leader should know before embarking on a multi-cloud journey. From aligning cloud strategy with business goals and fostering a culture of learning, to embedding FinOps for sustainable cost management, the discussion explores how cloud initiatives can drive innovation, transform Global Capability Centers into strategic hubs, and link engineering efforts directly to business outcomes. Along the way, we uncover practical strategies, cultural shifts, and even some lighter perspectives on cloud platforms that make this complex journey both impactful and human-centred.

Join Mr. Sivakumar Krishnamurthy, India Site Leader – Senior Director – DevOps & SRE at Cloudera in an interesting conversation with Mr. Marquis Fernandes who spearheads the India Business at Quantic India.

You’ve led transitions from traditional data centers to multi-cloud infrastructures (AWS, Azure, and GCP). What are the top three lessons you’ve learned that you wish every tech leader knew before starting this journey?

My key lesson from leading multi-cloud transitions is that this is not just a technical migration, it’s a business transformation.

The top three lessons I’ve learned are:

  1. Cloud Strategy First, Technology Second:Do not start with a “lift and shift” mentality. Before touching a single line of code, align on a business-driven cloud strategy. Is the goal agility, cost optimization, or new market access? This strategic clarity will dictate which applications move, what architecture is best, and how you measure success.
  2. Culture and Skills are the Biggest Roadblocks:The most significant challenges are people-related. Legacy-minded teams, a lack of cloud expertise, and fear of change will derail the project faster than any technical issue. Invest heavily in training, build a cloud center of excellence, and celebrate small victories to foster a culture of learning and adoption.
  3. Financial Governance is Not Optional:Without a robust FinOps framework, your cloud bill will grow unpredictably. Implement cost visibility, budget alerts, and accountability models from day one. This proactive financial discipline is essential to sustain long-term cloud success and prevents the C-suite from viewing the cloud as a runaway cost center.

Cloud cost optimization is often treated as a budgeting exercise, but you see it as a business differentiator. Can you share an example where cost optimization directly enabled a product or business innovation?

Cloud cost optimization, or FinOps, is a strategic business enabler, not just a budgeting exercise. A powerful example of this is a product-led company I worked with that offered a data analytics platform. Initially, our cloud spending was high due to on-demand compute resources for user queries. This limited our ability to offer a “freemium” tier, as the cost per user was too high to be sustainable. Through a focused FinOps initiative, we analyzed user behavior and implemented a dynamic scaling strategy. By using a mix of spot instances for non-critical workloads and reserved instances for our core services, we reduced our per-user compute costs by over 40%. This direct cost saving wasn’t just pocketed; it was reinvested into a robust freemium model. The lower cost of entry allowed us to attract a significantly larger user base, which in turn provided a massive new source of product usage data. We leveraged this data to accelerate our machine learning roadmap and build predictive analytics features that our competitors lacked. In this case, cost optimization was the key that unlocked a new go-to-market strategy, fuelled product innovation, and ultimately became a key business differentiator.

Many see Global Capability Centers as cost-saving units. You’ve proven they can be innovation hubs. How do you turn a GCC into a driver of engineering excellence and business impact?

Global Capability Centers (GCCs) have long been seen as cost centers, but their true potential lies in becoming innovation hubs. I’ve successfully driven this transformation by shifting the focus from task-based execution to end-to-end ownership. The key to this transformation is to move from outsourcing to insourcing. Instead of simply handing over projects, we establish dedicated product teams within the GCC. These teams are fully responsible for a specific product or service, from ideation to delivery and ongoing operations. This fosters a sense of ownership and accountability that is crucial for driving innovation. To support this, we invest heavily in skill development, leadership training, and creating a culture of psychological safety where team members are encouraged to experiment and take calculated risks. By embedding these principles, a GCC evolves from a support function into a strategic partner, delivering engineering excellence that directly drives business impact and value.

In your experience, how can SRE and DevOps teams go beyond uptime metrics and directly align their work with tangible business outcomes?

In my experience, the key to moving SRE and DevOps teams beyond uptime is to embed them directly into the product lifecycle and connect their metrics to business-level KPIs.
Instead of solely focusing on technical metrics like Mean Time to Resolution (MTTR) or system uptime, SREs and DevOps teams should be aligned with business-critical Service Level Indicators (SLIs). For example, an e-commerce SRE team shouldn’t just track API latency; they should measure the latency of the “Add to Cart” button and the checkout success rate. Similarly, a DevOps team for a SaaS product can shift from tracking deployment frequency to measuring how their accelerated deployment pipeline directly impacts time-to-market for a new revenue-generating feature.

By linking their work to tangible business outcomes such as customer conversion rates, revenue from new features, or customer churn due to performance issues, SRE and DevOps teams are transformed from cost centers into strategic business partners. Their expertise then becomes a direct enabler of business value, not just a technical safeguard.

You’ve shifted teams from an operations mode to an engineering-focused execution rhythm. What mindset changes, processes, and rituals were most crucial in making that cultural shift stick?

Transitioning a team from a reactive, operations-led model to a proactive, engineering-focused rhythm requires a fundamental shift in culture and process. The most crucial change was adopting a product-oriented mindset treating our internal infrastructure as a product with developers as our customers.

To make this stick, we implemented a few key changes. First, we shifted from a ticket-based workflow to a project-based one, with a clear roadmap, sprints, and feature delivery cycles. This moved the team’s focus from “closing tickets” to “shipping features” that enhanced developer productivity.

Second, we introduced a “you build it, you own it” mentality, with engineers taking full responsibility for their services, including monitoring and on-call rotations. This instilled a sense of ownership and incentivized building reliable, self-service tools from the start.

Finally, we established blameless post-mortems and dedicated time for proactive engineering (e.g., building automation, paying down technical debt). This ritual moved the conversation from “who broke it?” to “how do we fix the system?” It was these combined changes that transformed our team from a reactive fire-fighting unit to a strategic engineering partner.

If AWS, Azure, and GCP were three types of personalities at a party, how would you describe each, and which one would you hang out with the most?

If AWS, Azure, and GCP were at a party, AWS would be the established CEO, powerful, knows everyone, but you need an instruction manual to talk to them. Azure would be the charismatic, smooth-talking enterprise salesperson who promises you the world and has surprisingly well-organized contacts. GCP would be the brilliant, slightly quirky engineer with the latest gadgets who’s always tinkering in the corner. I’d hang out with GCP because they’re full of innovative ideas and less likely to try to upsell me.

If you could go back to your very first day in tech and give yourself one piece of advice about leadership, what would it be, and would you still follow it today?

I’d go back and tell myself, “You’re going to think you have all the answers, but you don’t. Your best ideas will come from listening to the quietest person in the room.” I’d still follow it today. That, and “Don’t ever, ever try to release just one line fix to production on a Friday.” Some lessons are just timeless.

If you could invent a magical tool to solve one engineering pain point, what would it do?

I’d invent the “Git-O-Matic,” a magical tool that automatically resolves all merge conflicts with 100% accuracy. It would also write the commit message for you, a haiku summarizing the changes, and send an automated message to your manager saying, “Project is ahead of schedule, I am a genius.” It would essentially eliminate the need for late-night coffee, public shaming, and all forms of professional humility.

Through this conversation, Mr. Sivakumar Krishnamurthy highlights that successful multi-cloud transformations are as much about culture, ownership, and business alignment as they are about technology. By embedding strategy-driven decision-making, fostering engineering excellence, and linking operational metrics to tangible business outcomes, organizations can turn cloud initiatives into powerful engines of innovation. From cost optimization to building high-performing, accountable teams, his insights reinforce that a human-centred, proactive approach, not just technical execution, is what truly drives sustainable impact in today’s complex cloud landscape.

[blog_bottom_ad]
Share.
Leave A Reply