About
Engineering leader and technology strategist who builds and transforms scalable platforms, high-performing engineering organizations and technology businesses. I combine deep technical and architectural expertise with organizational leadership and business thinking to turn complex technology challenges into measurable outcomes.
I started as a hands-on engineer building enterprise software for Fortune 500 customers — provisioning and inventory systems for telecom operators, healthcare and insurance platforms, retail systems. I still care about the same thing I cared about then, which is whether the thing actually works for the person using it.
That foundation took me to VMware in 2013, where I was handed a product the company had bought and nobody in my office had built. I learned it by reading it. Over the next three years I helped grow that from one engineer into a full engineering site, while contributing to a rebuild of the platform’s architecture.
The role kept expanding before the title did. From engineering and architecture into building teams, shaping product direction, and leading work that crossed products, geographies and eventually company boundaries. I took on larger and more ambiguous problems, and the scope followed.
At CloudHealth I moved into organizational and business leadership. The data platform organization started with me, and I built it from there. I led a modernization that changed the platform’s architecture, its data foundation and its economics at the same time — none of which could be done without the other two.
After the Broadcom acquisition the question changed. It stopped being how do we build more and became how do we deliver the same or greater customer value for materially less. I led engineering strategy, architecture and investment against that, which is a different discipline from growth and taught me more than the growth years did.
The thread through all of it is fairly simple. I take complex technology and organizational problems and build the systems, teams and strategies that move them to their next stage.
How I operate
The problems worth taking on rarely sit cleanly at one level. The architecture question turns out to be an organizational question, which turns out to be a cost question. I have spent most of my career moving between four of them.
- Strategic
- Business strategy, product direction, investment decisions
- Organizational
- Team structure, hiring, leadership development, engineering culture
- Technical
- Architecture, distributed systems, performance, cost
- Customer
- Customer problems, adoption, time to value
The useful part is not operating at any one of these. It is moving between them without losing the thread — being in a steering committee in the morning and in an architecture review in the afternoon, and having the second conversation change what you argue for in the next one.
What I bring
I grew into leadership without leaving engineering behind. My technical judgment is not historical. I can still tell you why three data technologies on one platform was the right call and what it cost us every year afterwards.
I have built capability from nothing, twice. Once as the first engineer at a new site, for a product I had not written, without the title that would have made it my job. Once as the first engineer of an organization I then led. The second was easier because of what the first one cost me.
I own economics, not only architecture. Cost is a property of the design, not a finding that arrives later from finance. Some of the work I am most confident about is work no customer ever saw.
What I got wrong
Early on, I chose an XML-based database to store and retrieve event data. It was the right shape for the problem on paper — the events were hierarchical and semi-structured, and the query model fit the way we needed to read them. I was confident in the technology. I had seen it work.
It failed in production. Query performance degraded badly as event volume grew, and the customer experience degraded with it. We had shipped something that got slower the more it was used, which is close to the worst property a monitoring system can have.
What I got wrong was not the shortlist. It was the evidence. I had validated the data model and not the access pattern at scale — I proved the thing I already believed and never seriously tried to break it. A proof of concept that can only confirm your choice is not a proof of concept. And the fact that the technology worked somewhere else was never evidence that it would work here. It was just a reason I stopped asking.
We replaced it with PostgreSQL and Lucene indexing, and performance recovered.
What changed is how I evaluate technology now. I want the proof of concept run at the shape and scale of the real workload, aimed at the failure mode rather than the happy path, and I want someone in the room whose job is to argue the other side. It is also why, years later, I could lead the move off a query engine I had championed myself.
What I’m looking for, and what I’ll pass on
I am most interested in environments where technology, organization and business strategy all need to evolve together — complex platforms, data, cloud and AI problems where engineering can create advantage that is difficult to copy. Convince me the problem is real and the opportunity is large, and I am in.
I would pass on a role with a title and no real authority — over roadmap, over people, or over budget. And I would pass on an organization whose values I did not share. Both of those are things you find out afterwards if you do not ask beforehand.
M.Tech in Software Systems, BITS Pilani. B.E. in Information Technology, Government College of Technology, Coimbatore.