Career

I started as a software engineer working on enterprise systems for large customers, first in India and then alongside teams serving customers in the United States. The work covered telecom provisioning and inventory, workflow, and retail systems, and taught me the fundamentals that still matter: understand the customer problem, make the system reliable, and deliver what was actually needed rather than what was easiest to build.

I returned to India and moved into healthcare and insurance systems, including a shopper portal and provider-facing applications. The work brought a different kind of constraint: security, compliance and business-critical availability were part of the engineering problem rather than things handled around it.

I learned that technology decisions can have consequences well beyond the system itself — operational, financial and sometimes regulatory.

This was the first clear move from being responsible for my own work to being responsible for how other engineers succeeded. I led an engineering team technically, working across provisioning, inventory and network-management capabilities while staying close to the systems themselves.

It was the bridge between engineering and leadership, and it clarified what I wanted next: harder technology problems, at greater scale.

Eleven engineers.

I joined VMware as the first engineer in Bangalore for an acquired infrastructure-management product that nobody local had built. I learned the system by reverse-engineering it, began contributing to releases, and helped establish the engineering presence that followed.

The site grew from one engineer into a broader organization, while I moved from technical contribution into architecture and increasingly into building the capability around the work.

1 → 4 → 10 → ~100, across engineering, QE, support and documentation.

Member of Technical Staff, then Senior MTS, then Staff Engineer.

• First Engineer to Organization
• Transforming an Enterprise Platform

The platform had become capable of much more than its original shape, and three opportunities arrived at once.

An acquired application-monitoring capability needed a home after an organizational change. I took responsibility for it and built a team of around ten around it, then integrated it properly into the platform rather than running it alongside — and once it was integrated it largely stopped needing us, which was the point. When the company’s analytics strategy moved toward streaming with Wavefront, I handed the capability to a sustaining team. It was the right call and it wasn’t a comfortable one. I had built the team and the integration, and what came after was maintenance. But investment follows strategy, and a capability that works and needs little is a good thing to hand over rather than a thing to defend.

At the same time I was working two questions from the engineering floor: how the product could become easier to use, and what VMware could offer developers as containers and cloud reshaped the market. One prototype entered the product roadmap. The other made a developer experience tangible enough for product leadership to react to.

The same period produced the platform-integration work — putting operations capabilities into the workflow where a far larger customer base already spent its day.

This was the point where engineering stopped being only implementation for me. It became a way to change product direction, distribution and organizational capability.

• Turning Platform Integration into Product Adoption
• Innovation From the Engineering Floor

I served as the VMware-side architecture lead for Amazon RDS on VMware, working directly with AWS on a system where neither company controlled the whole architecture.

The work was less about owning every component than about making the boundary precise enough that two organizations could build and ship together.

• Building Hybrid Cloud Across Boundaries

I moved into engineering management and took on a platform where architecture, organization and economics had become inseparable. The data platform organization started with me and grew past forty engineers, and developed the leadership structure needed to sustain the modernization.

The work changed how I operated. Architecture decisions now had to survive against organizational capacity, customer commitments and the economics of running the platform.

Within a 75+ engineer global organization.

Engineering Manager, then Senior Engineering Manager.

• Transforming a Global SaaS Platform

After the Broadcom acquisition the engineering question changed, from how to build for growth to how to deliver customer value while operating for materially less.

I led engineering strategy, architecture investment and the technology roadmap through that change, working across Product, Customer Success, Architecture and finance. The emphasis shifted from adding capacity to deciding where capacity mattered.

That is a different kind of engineering leadership. Not only deciding what the platform should become, but deciding what it could afford to be.

• Engineering for Economics