A personal reflection - written mostly for anyone who’s trying to figure out a career at the intersection of technology and customers, and enjoys the same kind of work.
The other day I was at the NVIDIA office, and their MD for South Asia, Vishal Dhupar, made a comment that stuck with me: there’s a real scarcity of people who genuinely understand fast-changing technology - even more so in the agentic world - and who can sell, and sell well. The two rarely live in the same person, and the gap is only widening.
I’ve written before that in the age of AI, when building something is no longer the constraint, the real question becomes what to build. Taste matters. And for the right taste to reach the palette, you need what I’ve called the missing translator - someone who understands what a customer actually needs and nudges them toward the right solution. Vishal was describing the scarcity; the translator is my answer to it. That instinct shows up today under a dozen titles: solution engineer, architect, consultant etc.
For a long time I’ve wanted to write down what got me here, and how. Not as a victory lap - more as a map for someone standing where I once stood.
Our past choices quietly shape who we become, and who we’ll keep becoming. To borrow the line everyone borrows, from Jobs at Stanford: you can only connect the dots looking backwards. So let me try to be honest about which choices made sense in hindsight - and which ones I’d do differently.
It started with a commute
It began in the summer of 2012, when I was an intern at the Mumbai Monorail. Getting to the office meant changing four or five modes of transport - campus bus, city bus, the Mumbai local, a cab, and a walk. Somewhere in that daily friction I started wondering: even if you can’t remove the mode changes, could you at least reduce the friction between them?
That question pulled me into transportation. I dug into multimodal commuting, married the idea to the smartphone wave that was just picking up, and submitted it to a global competition. It made the finals, and I got to show it at Computex 2013. I wanted to push the idea further into research, but my grades were average - so I took the longer road: a research internship at IIT Madras, a paper at the TRB conference, and eventually a ticket to my master’s at UT Austin.
That stretch was my first real encounter with what drive for excellence and genuine curiosity feel like. I’ve come to believe those are the two single most important traits for a career that compounds. Not raw talent. Not a perfect transcript. Curiosity to keep asking, and the standard to not stop at “good enough.”
Numbers, ROI, and the first taste of “so what”
After a couple of years of grinding - and watching my love of transportation widen into a broader fascination with cities, maps, and location - I landed a job as a transportation demand modeler, later a data scientist, working out of the Miami and Chicago areas. It was a job where diligence mattered and numbers mattered. It was also my first real encounter with ROI: I was forecasting traffic over ten-year horizons, where someone was committing real dollars on the strength of my models.
Around the same time, machine learning and deep learning were heating up, so I picked up a few courses to keep pace. Looking back, the recurring theme of my early career was a restless “what next?” - the next job, the next skill, the next thing to learn. I always knew I wanted to build something of my own. Eventually, for a mix of reasons, I moved back to India to try.
The founder years: learning how not to do it
Building a product from scratch is an intense craft, even when you’re technically capable. Selling that creation is harder still - and selling it to an Indian enterprise is harder yet. A company is really born only when you can map a problem to a solution that a customer will actually pay for. That last part is where I got my education.
Fueled by what I can only call unflinching optimism, I tried a few ideas. The first was crime-hotspot prediction from urban data - I’ll admit I was a little too inspired by Minority Report. I built a prototype, but I couldn’t get a single civic agency to put money behind it. I pivoted into what I called “Google Analytics for physical spaces” - location intelligence for the real world - and ran with it for a while. I still believe in that idea. But between customers who wanted a service rather than a product, a shrinking runway, and - most of all - my not knowing how to sell to an enterprise, I had to shut it down.
I learned a lot about how not to do things. And that lesson led, almost naturally, to the next chapter.
Learning to sell - first inside, then out
I joined a startup where the founder backed me to build the product, but I had to sell it internally - to the very stakeholders who’d have to change how they worked. It was a dynamic pricing engine: optimize bus ticket prices so you fill 90–95% of bus seats within a given window, later steering prices with AI-driven demand and revenue forecasts. The mandate was to replace a third-party tool, justified by measurable ROI.
I’d always picked up whatever tech stack a build required. What was new here was everything around the build: how to pilot a product, how to scope and communicate it, how to phase an onboarding, how to report wins and failures and feed them back into the roadmap. How to nudge different departments, help them see the benefit - sometimes how to give them a “lever” so they felt they were winning. All of it backed by real impact, never spin.
Once I was comfortable selling to internal stakeholders, the obvious next question was whether I could do it for external customers. I loved the customer face-time, but I also wanted to stay close to the tech. That pull is exactly what led me to an AI solution engineer role.
Salesforce: a ringside seat to enterprise AI
When I joined in 2024, the AI team in India was being built from the ground up. The job over the next couple of years ran the full arc: evangelizing AI from the absolute basics - yes, sometimes explaining what the G, P, and T in ChatGPT even stand for - to helping enterprises find their first credible use cases, to running the pilots that proved value, to nudging what a company’s AI strategy should even be, and finally to driving real consumption.
What that looked like in practice: dozens of workshops at customer sites, across banking, travel, retail, and real estate; reference architectures and use-case playbooks built from scratch; C-suite sessions on the unglamorous-but-decisive stuff - guardrails, governance, build-versus-buy, the agent lifecycle. Over time it became a repeatable motion: pilot, to production, to expansion. Doing it inside an enterprise-application company gave me a genuine ringside seat - watching, up close, how large organizations actually metabolize AI.
What helped - and what I’d change
If I try to name the thing that’s helped most, it isn’t any single skill - it’s a combination that took years to stack. A technical inclination strong enough to keep learning and to hold an honest conversation with engineers, paired with a slowly-acquired feel for how selling actually works. Neither alone would have been enough. The engineers I admire who can’t read a room get stuck below the decisions that matter; the salespeople who can’t go a layer deeper than the brochure lose the technical buyer in the first ten minutes. The leverage lives in the overlap - and that overlap is exactly the scarcity Vishal named, and the missing translator I wrote about. It’s also why a winding path turned out to be an asset rather than a liability: the transportation modeling taught me to respect numbers and ROI, the founder years taught me what it costs when you can’t sell, and the product role taught me how change actually moves through an organization. Each chapter looked like a detour at the time. In hindsight they were the curriculum.
The other thing I’d underline for anyone earlier on the path: curiosity and a standard for excellence beat credentials over a long enough horizon. My grades were average. I didn’t follow a clean, linear plan. What carried me was refusing to stop at “good enough,” and staying genuinely interested long after the novelty wore off. Those two traits compound quietly, and they’re available to anyone - they don’t require permission.
If I’m honest, there’s a regret threaded through all of this. I’m not a coder by profession, and I’ve often wondered how much further I’d have gone - how much bigger I might have thought - if I’d been more hands-on with the technology rather than one step removed from it. Being able to build the thing, not just describe it, changes the questions you’re even capable of asking. The consolation is that the tooling has finally caught up to people like me. With coding platforms like Claude Code, the gap between an idea and a working prototype has collapsed; I can build and test something over a weekend that would once have needed a team and a quarter. It’s made me more dangerous in the best sense - closer to the build, with fewer translation losses between what I imagine and what shows up on screen. As they say, culture - a culture of building, of evidence over slideware - eats strategy for breakfast. I’m trying to live a little more on the building side of that line.
Where this goes next
I think the next decade belongs to enterprise AI transformation, and we’re still early. Most large organizations are going to spend five to ten years on this - not because the technology needs that long, but because they do. The hard part was never the model; it’s rewiring how a company decides, who it trusts, and what it’s willing to let an agent do unsupervised. That’s slow, human work. And it means an enormous amount of investment, learning, wins, losses, and careers will be made inside that window - much of it by people who can sit in the messy middle between the boardroom mandate and the engineering reality and make the two talk to each other.
That’s exactly where I want to be: at the front of that wave, on work that’s large enough to matter and concrete enough to ship. I don’t think the winners of this era will be the people with the flashiest demos or the loudest predictions. I think they’ll be the ones who stay through the unglamorous part - the deployment, the trust-building, the second and third iteration - and who keep their curiosity switched on while the hype cycles around them rise and fall. That’s the bet I’m making with my own career, anyway.
If you’re somewhere on a similar path - part builder, part seller, perpetually asking “what next?” - I’d genuinely love to compare notes. Some of the best dots only connect when you lay them next to someone else’s.