Munich, Germany
We keep adding tools, dashboards, and AI features without fixing the fundamental problem: network expertise is still trapped in the heads of a small number of people, while everyone else operates through increasingly complex abstractions. I think that's about to change — and I'm working on what comes next.
I spent the first decade of my career learning how things actually work — deep in engineering at Samsung and Sony, followed by a graduate degree in Computer Science at the University of Utah. I learned to think in systems, understand technology at a fundamental level, and build things that work.
Eventually, I realised the problems that interested me most weren't technical. They were the decisions around the technology: What should we build? What shouldn't we build? Why does a customer care? Where is the market going? And why do some products take off while others disappear?
So I moved into product.
At Cisco Meraki, I had two weeks of onboarding before being thrown straight into the deep end — a new platform, fires to fight, and no shortage of things that needed fixing. The first six months were brutal. Instead of rushing to ship features, I focused on understanding what was actually broken. Quality before novelty. Get the fundamentals right, then introduce things nobody else has.
That approach helped turn a product line with zero revenue into a $200M+ business.
More importantly, seven years in enterprise networking taught me something that isn't obvious from the outside: the official workflow and the real workflow are rarely the same thing.
I've spent years talking to the people who actually deploy, operate, troubleshoot, sell, and support enterprise networks. I've seen the spreadsheets, tribal knowledge, partner escalations, screenshots, CLI commands, documentation searches, and workarounds that exist outside the product. Those invisible systems are often where the most interesting opportunities are.
That's where I tend to operate — at the intersection of technology, customers, and the problems nobody has properly solved yet.
I'm also interested in people, institutions, and the forces that shape them. I grew up in India, spent formative years in the US, and have since lived in Canada and Germany. I've visited 30+ countries and compulsively collect languages — seven so far. Moving between cultures taught me to pay attention to how differently people think, what motivates them, and how relationships create opportunities that aren't obvious on paper.
That curiosity extends to macroeconomics, geopolitics, and markets. I like understanding where power sits, how it moves, and what changes when incentives change. Not because I want to predict everything, but because understanding the system gives you more agency within it.
I'm interested in people who are building things, operating at the edge of what's possible, or seeing a change before it becomes obvious.
If I can bring something useful to the table — a technical perspective, product judgment, a customer connection, a contrarian view, or simply a useful introduction — I'm interested in the conversation.
And I'm always thinking about what to build next.
Modern LLMs can understand messy technical context, reason across documentation and configuration, and turn intent into action. Network platforms are now exposed through APIs and automation frameworks rather than locked behind CLI and proprietary workflows. The pieces finally exist to close a gap that's been open for a long time. The question I keep coming back to is: how much of the manual translation work — between customer requirements, network configuration, documentation and troubleshooting — can actually disappear, and where does a human still need to be in the loop?
The hard part at Meraki was never just building another feature. It was making complex networking disappear for the person using it. I've spent years watching customers not want more networking technology — they want the complexity to stop being their problem. A conversational layer that actually understands network context — topology, compliance posture, device lifecycle — is not a chatbot wrapper. It's a fundamentally different way to interact with infrastructure.
I've spent most of my career inside large organizations learning how to build things well. I'm now at the point where I want to find out what I can build without those constraints. The transition from domain expert to product builder is its own discipline — knowing a problem intimately and shipping software that solves it are different skills, and the gap between them is more interesting than most people admit.
Leaders of IT solutions provider industry - want to collaborate on AI, enterprise networking and the future of AI networking infrastructure? let's talk.