How automation is changing managerial roles

I recently sat down with Business Standard for their Manager's Mantra series (BSmart). What started as a conversation about automation and managerial roles turned into a wide-ranging discussion: enterprise cloud strategy, the economics of AI infrastructure, how to build data platforms people actually use, modernizing legacy systems, and where the next generation of leaders (including non-engineers) can have the most impact. Here are the main ideas we covered.

From cloud adoption to cloud optimization

For a decade, the assumption was simple: move to the cloud and you automatically get faster and cheaper. For many companies that held. But the "lift and shift everything" era is essentially over, and there is a healthy correction underway. The biggest shift is from cloud adoption to cloud optimization. A lot of enterprises moved workloads without rethinking the design, took on-premise architectures, dropped them onto cloud VMs, and ended up paying more for roughly the same infrastructure.

Three things are changing. Organizations are getting serious about measuring what they actually need versus what they pay for. In my own experience, replacing a manual, spreadsheet-based capacity process (where every team padded its estimates and you could never tie capacity growth to business growth) with data-driven forecasting tied to business metrics reduced infrastructure forecasts by over $300 million in one cycle and $400 million in the next, not by cutting capability, but by replacing guesswork with data. The conversation has also moved from "cloud versus on-premise" to "right workload, right environment": some latency-sensitive, high-throughput workloads are simply more cost-effective on dedicated infrastructure. And FinOps has matured from a buzzword into a real discipline, with dedicated teams, clear metrics, and accountability. The winners are not the ones spending the most; they are the ones with the clearest visibility into what they spend and why.

The GPU cost problem in AI infrastructure

GPU cost is the single biggest infrastructure challenge in AI today. At large companies, just serving models in production can run into hundreds of millions a year, and demand keeps climbing as AI gets embedded into more products. This is not about trimming budgets; it is about building a sustainable cost structure for AI at scale.

The most overlooked lever is fungibility: making the GPU fleet interchangeable across teams and workloads. In most organizations GPUs are statically allocated, one team owns 200, another owns 300, and a big chunk sits idle because workloads are bursty. Pool them and assign dynamically based on real-time demand, and utilization jumps without buying a single new machine, often 30 to 40% more useful work from the same fleet. The second lever is architectural. Most models are deployed monolithically on a single GPU, but modern models have components with very different compute profiles. By disaggregating them and running each piece on the right hardware, the gains are large: on one major advertising model, re-architecting serving took us from about 90 queries per second per GPU to nearly 400, a 4.4x improvement on the same hardware and roughly $20 million in capital savings, and business performance went up too, with click-through rates improving 17% against a planned 6%. The third lever is right-sizing: not every workload needs the newest, most powerful GPU. Match workloads to the right tier and the savings compound. Efficiency and innovation velocity are not in tension: when infrastructure is efficient, the same budget funds more experiments.

There is no single "data platform"

Data platforms are becoming the backbone of organizations, but the most important thing to understand is that there is no single data platform. Broadly there are three types. Offline platforms handle batch work like analytics and model training, where latency is measured in hours. Online platforms serve real-time requests at millisecond latency, think instant recommendations. Nearline platforms sit in between, processing in seconds to minutes, useful for fraud detection or content ranking where freshness matters but instant response does not.

Companies fail in one of two ways: they try to build one platform that does everything (and it does nothing well), or they build the wrong type for the use case, like serving real-time recommendations from a batch system. The ones that succeed start with the business need, not the technology: what decision needs this data, how fresh does it need to be, what latency can the user tolerate. They treat platforms as products with dedicated ownership that iterate on user feedback, not one-time projects. And they make the standard path easy. When the right pipeline requires filing tickets and waiting weeks, teams go rogue and build their own thing; the best platform teams make self-service so straightforward that nobody wants to deviate.

Automation is reshaping managerial roles, not eliminating them

There is a lot of unnecessary anxiety here. I have not seen automation eliminate managerial roles, but I do see it reshaping them, honestly for the better. Automation is good at removing repetitive operational work: automated deployments, monitoring, incident detection, the things that used to consume enormous amounts of human time. In the large-scale reliability programs I have led, automating detection and response freed people to focus on higher-value work: understanding patterns, driving systemic improvements, making strategic decisions. The people were not replaced; their work became more meaningful.

For people coming out of MBA programs, the opportunity is actually expanding. As AI, cloud, data, and infrastructure converge, the demand grows for people who can operate at the intersection of technology, business, and people: translating between engineers and stakeholders, finding the critical path through a program with dozens of dependencies, driving organizational change and not just technical change. The key shift is that you cannot lead what you do not understand. You do not need to write code, but you do need to understand how systems work, what the tradeoffs are, and how to ask the right questions. Do not fear automation; embrace it as a tool that removes low-value work from your plate, and invest in enough technical fluency to be a credible partner to engineering teams.

Modernizing legacy systems without a big bang

Plenty of large enterprises still run on legacy systems like SAP, and modernization is one of the hardest problems in enterprise technology. The temptation is always the big-bang migration: rip out the old, drop in the new. At scale that almost always fails or costs three times the budget. What works is incremental modernization, like renovating a house while people still live in it, room by room, making sure each section is livable before moving on.

In practice, start with the interfaces, not the core: build modern APIs and data layers on top of the legacy system so new applications talk through clean interfaces while the core keeps running, then replace the underlying components one by one. Be honest about what actually needs to change. A system like SAP encodes decades of valuable business-process knowledge, so target the real constraints (slow deployment cycles, inability to scale, poor data accessibility, high maintenance cost) rather than rebuilding from scratch. The successful programs I have been part of all had clear, measurable goals: cut deployment time from weeks to hours, hit specific availability targets, enable real-time data access where only batch existed. And the organizational challenge is usually harder than the technical one: you need executive sponsorship that understands this is a multi-year journey, you need to protect the modernization team from constant legacy firefighting, and you need to celebrate incremental wins.

What being data-driven actually looks like

A lot of organizations call themselves data-driven but are really "data-decorated": they decide by intuition or authority, then find data to justify it afterward. Real data-driven decision making looks different. It starts by defining the right metrics before you begin, not after. When we standardized service level objectives across roughly 1,400 production services, deciding the metrics upfront replaced endless debate about whether a system was "good enough" with a clear quantitative answer. It makes data accessible and understandable, not just available, translating "CPU utilization across cluster X" into "cost per million queries" or "capacity runway in weeks" so a product manager, a finance leader, and an engineering director can all act on it. It is willing to let the data change your mind, regardless of who proposed the alternative. And it builds feedback loops: every decision has a measurable outcome you track. Did this move the metric we cared about? If not, why?

Where MBAs and non-coders create the most impact

Some of the most impactful people I have worked with in technology do not write code. In large transformations the bottleneck is rarely code, it is coordination: getting hundreds of teams aligned, driving accountability without bureaucracy, managing dependencies across interconnected systems, which are classic strengths of strong program and portfolio managers. Internal platforms need product thinking just like external products: understanding users, prioritizing, measuring adoption. FinOps and cloud economics is exploding, because people who can bridge finance and engineering and turn spend data into optimization strategy are rare and valuable. And AI strategy and governance, the business implications, ethics, regulation, and positioning of AI, is exactly the cross-functional work MBA programs develop well.

On the India and US question, having built my career across both: India has an extraordinarily deep, world-class engineering talent pool that has matured over the past decade, from execution against headquarters specs to genuine innovation and ownership. Some of the most complex distributed systems and AI platforms today are designed and built there. Where the US still has an edge, and it is closing fast, is systems thinking at scale: holding business implications, organizational dynamics, and long-term architecture together. That is an experience difference, not a capability one, and the era of treating India as a low-cost execution center is over. My one piece of advice for anyone non-technical: invest in technical literacy, not technical expertise. You do not need to build models, but understanding how they work and what the tradeoffs are earns you a seat at the table.

Watch the full conversation on Business Standard.

Note: the opinions expressed are those of the speaker and do not represent the employer or any other companies.