Engineer, then product manager, then director.

I grew up in Chennai and Mumbai, came to the U.S. for grad school at the University of Minnesota, and never left. As a kid I was the one taking things apart to see how they worked, then building something else from the parts. Engineering was where that impulse fit.

That instinct carried me through three pretty different jobs. I started as an electrical engineer at Joby Aviation, working on eVTOL aircraft systems with NASA. Then nine years at Rockwell Automation, where I moved from embedded engineering into product management. Today I lead engineering at Williams AV, where we build assistive listening systems for classrooms, courtrooms, and other venues that need to work for people with hearing loss.

The Rockwell jump from engineer to PM was the hardest of those transitions. Engineering is mostly black and white: the math works or it doesn't, the schematic functions or it doesn't. Product management is gray. You're sorting out what customers want versus what they actually need, building business cases on projections that aren't really first-principles math, and making calls before all the information is in. It took me a while to get comfortable working that way.

That stretch is also why I'm a better director than I would have been otherwise. When the PMs on my team don't have an answer, or change one they gave me yesterday, I know what they're working through. We work the problem together instead of me waiting for clarity that was never coming.

Another thing the years have taught me, more painfully than I'd like: not everyone on a team has the same goal. I used to assume that shipping the product was the shared priority. Often it is. But people sometimes bring other incentives. Career visibility, team boundaries, how a project will be remembered. None of those motivations are bad-faith. They just don't always line up with what's best for the project. I've learned to spot them earlier and work with them. Sometimes that's a direct conversation. Sometimes it's restructuring the work so the misalignment isn't a blocker. The job isn't to wish people were different. It's to ship the product.

Williams is also where I've gotten the clearest picture of what a small company can do that a big one can't. At one point we were stuck on defining the next product for a key segment. Meetings every week, opinions in every direction, no written requirements, no clear vision anyone could rally around. The engineers were ready to build and we had nothing to give them. I'd been reading about Google Ventures' Design Sprint and proposed a modified version. Over two weeks we sketched, built rough prototypes, and ran user interviews. By the end we'd coalesced around a product vision the team could rally behind. We also killed a feature that would have been a costly mistake. We'd been planning to make the device rechargeable, which sounded obviously good in a meeting room. Almost every user we talked to told us they wouldn't have time to charge it or would forget. That single feature would have cost us months of engineering and shipped us a product nobody wanted. And running the experiment in the first place was only possible because I work somewhere small enough that I could read about an idea, propose it, and try it without months of approval cycles. At a Fortune 500 it might have died on a slide deck. That's the part of small-company engineering I keep coming back to.

I'm also starting to share more of what I've learned publicly. First talk is at Minnebar 20 in May 2026, with more writing planned.