Building Talent Density in India

Building Talent Density in India
Photo by Abhas Mishra / Unsplash

We think a lot about talent density here at SPC. It’s something we’ve spent the last decade cultivating, and is – in many ways – one of our core products. We’re quite curious about how folks have built it around the world.

We’re joined by SPC member Gaurav Bhalotia (ex-CTO @ Udaan), Saurav Shah (second employee @ Rippling), Dinesh Ajmera (ex-Head of Engineering @ Atlassian), and Utkarsh B (ex-Chief Architect @ Flipkart) to dive into how they’ve built talent-dense engineering teams in India.

Gopal: Something I’ve noticed after spending a bit of time in Bangalore is that folks really self-identify with a handful of talent-dense environments over the last 10 years. You say, “Walmart Labs,” you say “Flipkart,” and people respond – “ah, you’re part of that mafia.” For the person who’s not as familiar with the Indian ecosystem, what have been the really formative pockets of talent density over the last decade?

Then, the follow-up is: what do these different ones stand for? In the U.S., if there’s a high-craft, high-talent density, you’d say “Notion” or “Figma” or “Apple.” But if you said “quantitative, intense, commercial,” that may be a different set of companies.

Dinesh: Before I answer which ones currently have top-tier talent density, maybe it’s worthwhile to see the history behind it — the inflection points. There was a time when these “captive centers,” so to say, would open up, and they didn’t usually do much exciting work (mostly resource augmentation). That slowly changed to more ownership in India, and then the startup ecosystem itself really took off, in the late 2000s or early 2010s. That completely changed the mix. 

Companies like Yahoo, for example, brought in a lot of talent from the U.S. People came on ex-pat compensation packages and whatnot, and they spread around, not just within Yahoo but outside. You can clearly see that seeded a much bigger talent tree over time.

In terms of larger companies that have had a real impact on India’s talent pool, Amazon has brought in a lot of talent, Google as well. Walmart pulled in a lot of talent, Atlassian too. Among India-based companies that I used to hire from like Flipkart and InMobi. There are quite a few Indian startups and also global startups with a good presence here. Rubrik, for example, Cohesity — though those may not be Indian startups, they have a strong center in India. So it’s a mix.

Gopal: I’m curious, for those of you who worked at Walmart Labs, what made that place special? Three of you were there, right?

Saurav: That’s correct. For me, I joined around the end of 2011, about six months after that entity was formed in India. There were a bunch of Googlers in that crowd. I got introduced to the company through ex-Googlers, who were my ex-colleagues as well. The talent density was immense. And the promise was that Walmart, this huge company not known for its engineering prowess, wanted to hire high-quality engineers doing cutting-edge tech. 

They wanted to deviate from the typical Walmart brand, so they hired these engineers under “Walmart Labs,” right? That itself had the attraction of working on high-scale, “sexy” problems alongside talented colleagues. That pulled me into Walmart.

Gaurav: I wasn’t directly in Walmart Labs. I was part of this startup called Kosmix, which got acquired by Walmart and became Walmart Labs. There were three things: first, as Saurav mentioned, there was a significantly high talent density already in Kosmix — so you had people to look up to. Second was the promise of world-class problems — these magnets or “mafias” had access to outsized impact, which attracted the best engineers in the country. Walmart was definitely one of them, offering direct influence on the U.S. Walmart business. In our case, we were acquired for a certain amount, and by just applying changes to Walmart’s search technology, we recuperated the cost of the acquisition. That was huge. 

The third thing was significant empowerment. A bunch of my friends at Walmart Labs could work on large problems — like redoing the pricing engine. And of course, at the time, Walmart Labs was ready to break any barriers on compensation, to do whatever it took to get the best people.

Dinesh: Let me just add that Walmart acquired Kosmix to change the culture of the larger company. That was a huge opportunity. As Saurav mentioned, Walmart didn’t have that technical prowess or culture, so this set of people was brought in to fix that in the wider organization. The interesting part is that the larger tech org ended up leveling up to Walmart Labs, rather than Walmart Labs being leveled down to Walmart standards.

I think that culture also included having really small “two-pizza” teams—a concept from Amazon—spread across Walmart Labs. You’d have small teams taking on huge problems. Folks in India were tackling big problems for Walmart.com in the U.S., sometimes larger than what people in the U.S. offices were solving. One example is affiliate marketing for Walmart. It was basically run by one marketing person with LinkShare—there was no in-house tech. We took that on, built everything in-house, and that’s how we got that program to a different level. Same with display retargeting: from the ground up, understanding that space and building our own RTP platform. It was a great experience for really small teams. I think that’s what everybody loved about Walmart Labs.

Utkarsh: Prior to Flipkart and InMobi, there was this global outlook toward brands like Walmart, Microsoft, Amazon, and so on. People had an affinity toward those companies. Flipkart and InMobi did not have that brand recognition.

What happened in this last decade is that the pedigree of engineers coming natively from India changed. Prior to 2010, we had solution engineers who would mostly just “plumb” solutions — following the same repeat patterns in a three-layer architecture, and so on. They’d take on multiple tech stacks and just piece them together. But with Flipkart and InMobi, because we were solving native problems — at an Amazon scale — we created our own warehousing solutions, our own supply chain ecosystem, the first Big Billion Day (mimicking Black Friday), and so on. We couldn’t rely on existing tools. So there was this generative mentality that came about: we graduated from “solution engineer” to “platform engineer,” creating platforms rather than just solutions. That pedigree has matured over the last decade.

Today, I can proudly say — and because I come from that background, I can identify tons of such people — that I can pick someone and say, “Can you create this platform for us?” or “Can you create this tech infrastructure in India?” That entire landscape has changed. It’s not just hooked on Amazon, Google, Walmart — there are these native companies breeding new-age talent that have learned the art of creating platforms out of India, on their own.

Gopal: I’m curious to do a bit of a deep dive into your story, Saurav, with Rippling. I don’t know whether most people really understand how deep Rippling’s roots in India are. Many people on the surface might just assume – “Oh, they opened an India office.” It’s not really like that. How did it all come together?

Saurav: I joined Rippling because I knew the co-founder and CTO. Toward the end of my stint at Walmart, I was bored and wanted to go back to a startup. I pinged him one day to see if he could connect me with folks in Bangalore who were in a similar boat — either starting something or having just started. He mentioned, “Dude, I just started a company — why don’t you talk to my co-founder?” So, I spoke to Parker a couple of times, and it was very hard to say no.

Initially, from Parker and Prasanna’s perspective, it wasn’t like, “Let’s go ahead and open an India center.” Their view was, “We’re getting this talented senior engineer who can build a team in Bangalore. Let’s at least hire this person and see where it goes.” For the first six months of my tenure, Parker tried every week to convince me to move to the Bay Area — because that’s where all the action was going to be. But once we started hiring, whenever a position opened in SF and we couldn’t fill it in a week, I’d say to Parker and Prasanna, “Why don’t we try hiring in Bangalore?” And organically, we filled those roles there much faster.

So, the team just kept growing. By the time we had about 50 engineers in the company, 40 to 43 were in Bangalore, and only six or seven were in SF. It shows how fast and easy it was for a startup to access talent in Bangalore compared to hiring in the Bay Area, where there’s a lot of competition — even for a company like Rippling, with a well-known founder. It’s hard to stand out in the Valley because there are so many other companies. In India, that story is still relatively rare, and we were able to capitalize on it to hire great engineers early on.

Gopal: Who were the first five to ten hires in the office? In hindsight, what should you have optimized for?

Saurav: The first five or ten hires came from our own network. The first three or four were from my immediate network, and then they brought in folks from theirs. Something we deliberately optimized for was hiring mid- to senior-level engineers in the early stage, because we wanted people who could take on open-ended problems. 

Rippling was one of those companies with a multi-product portfolio from day one. You needed engineers where you could say, “Here’s an abstract problem — build a payroll app, and here are the competitors. Go study them. We have a rough outline of what we want, but you fill in the blanks.” Parker was our only product manager, so we needed engineers who could run with it.

Dinesh: Atlassian’s approach was quite different — maybe more deliberate. We had the luxury of not going super fast and could be more thoughtful about what we wanted to build. Some context: before the India center was opened, Atlassian took quite some time to do due diligence. I was in Dubai working with Souq.com in early 2016 when a friend at Atlassian reached out about building a new tech hub in India. I had just moved my family to Dubai, so I wasn’t interested at the time. But they kept me in the loop with their questions and thoughts.

Then in early 2018, they said, “Now we’re really looking to open in India.” I asked, “What happened in these two years?” Turns out there had been a lot of due diligence, including a founder visit to Bangalore to confirm that yes, we really do want to be there. They talked to multiple companies to understand playbooks of what worked and what didn’t. They’d opened an office in Saigon before, which failed and shut down, so those scars were still fresh — especially around senior hires. They realized in India, you can find strong senior engineers and leadership who’ve already dealt with large-scale problems, whereas in Saigon that was missing.

Also, in Bangalore, you can find not only engineering but product, design, security, SRE, all sorts of specialties, plus leadership with global exposure. Based on those learnings, they decided to open an India center around March/April 2018. Even before I joined, they were clear they wanted it to be one of the three major tech hubs for Atlassian. At the time, Atlassian was only about 3,000 people. By the time I left in 2023, the company had grown to around 10,000, and India itself was around 2,000 of those — so a lot of growth.

In terms of the early hires, it was very deliberate. We hired senior leadership across product, engineering, and design first, plus talent acquisition. We also knew we wanted to scale big, so we needed to establish our employer brand early. Among the first 10 hires was a talent brand person, someone in HR, and a campus recruiter, because you need to sow seeds at universities. So we had fewer “doers” and more “overhead” in the first 10 people, but that was by design. We also hired one or two engineers in that initial batch, and that’s how the India center started.

The “why” was clear (why we were setting up the India center), but the “what” and the “how” mattered too. We wanted some areas that could be fully owned and driven from India, so we identified a couple of anchor initiatives and products.

Gopal: Fascinating. I’m curious because, in some ways, Atlassian might not have been the only large incumbent with a great brand and a lot of pull. Utkarsh and Gaurav — when you’re building companies in India for Indian customers, you’re competing with these foreign firms. How did you think about competing with them — or even with a Rippling that has a “sexy” U.S. founder like Parker Conrad? What were the axes you would win on when you went after the same engineer or the same product lead? How did you get them to join you instead?

Utkarsh: I’ll start by telling my own story. I was at Amazon, and Flipkart approached me — though I hardly knew Flipkart at the time. Amazon was already a strong brand doing good work, with a lot of mentorship from principal engineers in Seattle. So there had to be a trigger to leave, right? That trigger came during conversations with Sachin and Binny, and the rest of the leadership. The team was maybe 25 people then.

Sachin told me: “Today, we’re just selling books. Tomorrow, we’re going to dream big — we don’t even know exactly what it will be, but we’ll create history in India.” I asked him, “What kind of history? What’s in it for me, technically?” He said, “I don’t know. But if you’re on the journey with me, you’ll look back one day and realize you helped create history.” For passionate people like us, who want a clear mission statement, that really resonated. I could see his passion, his audacity. 

He showed me a roadmap: “We’ve cracked books. We’re going to expand to two, three, four more categories. Today, it takes three to six months to launch a category — can you help us get that down to three days?” Or, “We’re selling a thousand books now — if we want to sell a million products across a huge variety, what kind of supply chain do we need to build?” As an engineer, I saw that it’s not just about scale — warehousing involves designing a system that mirrors real-world operations. This fuzzy storytelling convinced me I’d get to build something that matters. And indeed, every year for 13 years, a new, harder problem came along.

So the first people we hired were deeply passionate. A lot came through our network. Sometimes it was just a casual conversation: “I like you. You’re a passionate person with high ownership. Let’s bring you in. We can figure out skilling later — tools and skilling are the easier part if you have the right DNA.”

When I exited Flipkart after 13 years, in my farewell, we looked at a metric that HR rarely tracks: tenure. Out of about a hundred architects and senior ICs, 75% had been there at least eight years. I personally reported to six different CTOs, three different CEOs in that time — leadership churned, but we engineers stayed because we loved solving real problems. That continuity mattered.

Dinesh: Quick follow-up, Utkarsh. Out of those 100 people you mentioned in that architect community, how many were homegrown and grew into larger ownership areas, versus how many were brought in from outside?

Utkarsh: Around 60% were homegrown. Many of those folks are now at Atlassian, for example — I know three personally, and a fourth one is joining soon. I myself joined Flipkart with no architect title; I was just a tech lead. Later, I became the first architect, and others followed a similar path — SD2, SD3, then got the right problems, the right mentorship, and careful nurturing. By 2014–15, we started hiring outside specialists because there were certain world-class problems we couldn’t solve just by home-growing people. So yes, about 60% were homegrown, 40% were externally hired.

Dinesh: Thanks, that’s what I’ve seen too, especially for senior, highly skilled folks. Most are homegrown, and some come in from outside—maybe 30–40%.

Gaurav: I joined after Utkarsh. By then, the architect group was already there. Flipkart had this vision and audacity: “We’ll make it big in India, build a great brand out of India, bigger than Amazon. And we’ll do it by creating a great tech team and culture.”

When I joined, the engineering team was about 50 people, so we were competing mostly with two sets of companies: the Infosys-type consulting orgs and the big MNCs like Yahoo or Amazon, which already had large tech centers. For the consulting types, it was easy to pitch a stronger engineering culture — people wanted to move somewhere they could work on cutting-edge products and build platforms. For people in big MNCs, it was more about ownership and impact.

I joined to lead the website team (which became the customer platform). There were 10 people. We had to build search and recommendations. You couldn’t find a “search engineer” in India in 2012 — let alone someone who’d built recommendation systems. Same with strong UI engineers; it was tough. So we keyed in on people who were super passionate. Honestly, we weren’t competing directly with those big brands for that talent. Some people wanted to be at Amazon for different reasons; some wanted a more local sense of purpose, to be in India, with family, with more tangible ownership.

Even at Udaan, we compete with plenty of companies — Indian, MNCs. Engineers come for different reasons, but they stay for two key things: (1) the quality of the problems they work on, and (2) the quality of the people they work with. If you keep up that talent density and keep people they can learn from, that’s what differentiates you.

Gopal: If someone outside India — maybe in SF — wants to build a team in India, finding Rippling’s success or other examples aspirational, how do they decide if they should do it? If you sat down for coffee with them, how would you help them decide whether or not to build out their engineering team in India?

Saurav: I’ve had similar conversations with companies wanting to open offices in Bangalore. One big reason for U.S. companies is still currency arbitrage — ten engineers in India might cost what two or three do in the Bay Area. But once you have a few engineers on the ground, it also becomes about talent density. 

I think the key for a U.S. founder is to be clear: they’re not just building an “offshore” team for discrete tasks. They need real partnership, real ownership in India. The time-zone difference is brutal in early stages if you’re going back and forth constantly.

What worked at Rippling — and for a few other companies I’ve seen — is hiring a senior “tech lead” persona rather than a director or senior director. Someone who can code on day one, but is also hungry enough to grow and build a team around them. Once you reach critical mass, you can hire more senior folks, but early on, you need that hands-on leader who can grow the team, bring people from their network, and day-to-day mentor folks while the founders are asleep in another time zone. You also have to give that person a meaningful stake in the company so they’re in it for the long haul.

Utkarsh: I’ve seen exactly this scenario in my “architect in residence” role, helping new or scaling tech-centric startups. Twice in the last few months, a U.S.-based founder reached out on day zero: just two founders, no team, wanting to build in India.

Almost any specialized domain you can think of, there’s at least someone in India who’s done it. The real thing that impresses people, though, is our hunger: many Indian engineers are hungry to build something, including a lot of “techpreneurs.”

So from a Valley founder’s perspective, they might see more passion and excitement in India. You can tap into that hunger to build a strong foundation, and then later you can decide if you need a Valley presence as well. For the initial momentum, it can work really well to start in India.

Dinesh: Just to build on that, one of the key points is identifying someone you can “root on,” be it a tech lead or somebody who can be the nucleus of that team. If you start off hiring one or two junior engineers without a strong leader, I’ve seen that fail.

You also asked about deciding between the U.S. vs. India. Time zones can be critical. The founder needs a clear “why.” Is it cost arbitrage, or is it faster access to talent? Because there’s overhead for the first year or two as you get that momentum. You have to be realistic about that.

Gaurav: It’s a tricky question for a U.S. startup to have a team in India—time-zone alignment is challenging. I had to travel to the Bay Area very often, which took a toll on me. I’ve seen another unicorn whose founder was in the U.S. for family reasons, but he started the company in India. For six months, he operated on India time—basically working U.S. nights. In early-stage mode, there’s so much ambiguity, it’s tough to align with engineers if you’re not actively available. 

I think the sweet spot for opening an India engineering presence is when the ambiguity is somewhat reduced—when you have clarity on what you need from that center. As Saurav said, it should be an empowered, independent team with minimal day-to-day reliance on the U.S. time zone. India offers the upside of hiring faster and cheaper with good talent density — especially if you have strong funding, a solid founder, and VCs. You’ll rise above the noise. So there are definitely benefits, but there are guardrails as well. If I were a founder in the U.S., I wouldn’t open in India too early unless I had a co-founder or a key leader on the ground.

Saurav: Right — one of Rippling’s co-founders is Indian, but he was also based in the Bay Area.

Gaurav: That must have been tough on you.

Saurav: It was. We’d have midnight or 1 am, 2 am calls. There was a lot of churn in the first two years just due to the time-zone challenge. We were very clear in telling senior hires, “You will have 11 pm calls — there’s no hiding from that.” We tried to shield mid-level and junior folks from it, but we still lost some senior people who didn’t realize that’s what they were signing up for.

Gopal: What are some specific stories that come to mind, either highs or lows, that inform the advice you give now?

Saurav:  If I think back, the first two or three folks who joined us at Rippling were all from Walmart Labs — former colleagues of mine who reached out after I left. The day they joined, there was this surge of energy because our team effectively doubled or tripled. 

When we started hiring outside our network, we had all sorts of stories. I remember trying to hire a mid-level engineer who was not in Bangalore at the time. After the interviews, we made an offer and tried to convince him it was a real company. I even had to show him our small office space (or do interviews in coffee shops before we had a proper office) to prove it was legitimate. Sometimes candidates just walked out halfway through the interview.

But what kept us going was that our business was strong from day one. 

As soon as we built the product, we had paying clients. So if you wrote some code today, you’d see ten clients using it tomorrow. That constant adoption created a high for our early engineers. Had we experienced major dips in product success, combined with the time-zone challenges, I think the India-U.S. story at Rippling would’ve suffered. I can’t recall any specific big “mistakes,” but the successes in hiring and product launches — and that instant feedback from real users — stand out.

Gopal: Dinesh, maybe a similar question for you: what mistakes did you avoid? What did you learn from others and very consciously decide not to do? I imagine you spoke to many other site leads and heard their horror stories. Which ones were most pivotal?

Dinesh: We’ve been talking about “ownership” all along — giving teams real empowerment. One big takeaway for me at Atlassian was ensuring we really committed to giving people impactful problems, plus the authority to solve them. A key mechanism was having a strong executive sponsor. In our case, this was the CTO, Sri Vishwanath.

I reported directly to him, so we had a tight bond and consistent support from the top. At Walmart, after the Kosmix acquisition, we initially had strong champions, but once they left, the link to the broader leadership weakened. That contributed to the talent drain.

Another thing: many companies have “India teams” and “U.S. teams.” Atlassian wanted global leaders. We didn’t want people stuck managing only local engineers. We wanted product leads in India who also had teams in Australia or the U.S., and vice versa. That helps you think as a true global leader rather than just a “site lead.”

Lastly, as we scaled from zero to 2,000 people in India, we had to be deliberate about preserving culture. We wanted to maintain that “triad” approach—engineering, product, and design working hand in hand, not losing it under the weight of rapid growth.

Gopal: Who are the unsung heroes in all these stories?

Gaurav: When we talk about high-performing engineering teams, we often highlight high-caliber engineers who build platforms, tackle ambiguity, and communicate well. But there are parts of the system — like accounting — where you’re not doing heavy innovation. You just need a high-quality, reliable system day in and day out. These folks are like the “Pujaras” in cricket. People celebrate the “Tendulkars” who hit flashy fours and sixes, but you need the “Pujaras” who hold the team together with consistent performance.

A team can’t be all superstars. You need those steady engineers who quietly build the foundational fabric. They rarely get the big spotlight, but without them, you can’t do a lot of the flashy work.

Utkarsh: In my 13 years at Flipkart, I saw so many unsung heroes. For instance, building the website that handles high throughput often gets glorified — “we can handle X million requests!” — but nobody talks about the “pick-pack-dispatch” system in the supply chain that must be consistent for operators on the ground, who might not be very tech-savvy, but rely on it daily.

Another category: cultural ambassadors. Maybe they’re not shipping the most business-critical features, but they elevate everyone around them. For example, I remember a guy who did amazing code reviews, projecting his own code onto a screen and inviting everyone to critique it. That attitude created a healthier review culture. Or the best troubleshooter you’ve ever met—maybe he’s not building the next big system, but he’ll take you from the application layer down to the kernel to solve a deep issue, teaching others along the way.

Saurav: We eventually started giving awards for “Unsung Heroes” at Rippling’s engineering all-hands, just to shine a light on these folks. And specific to India-based teams, I’d add there are also unsung heroes on the U.S. side—team leads who invest in time-zone-sync calls, handle ambiguity, travel frequently, and really make India integration work. We saw some attrition among senior U.S. people who weren’t up for that.

Gopal: What’s changing in the next 5–10 years that people might be under-appreciating? What will really affect how we might talk about this again in 2030?

Saurav: Early on at Rippling, it was hard to convince people to value equity, because Indian engineers hadn’t seen many successful exits or IPOs. We had to offer more cash upfront. Now, with success stories like Zomato, Flipkart, and others, equity is more attractive. Risk tolerance has increased. That’s going to compound. You’ll see a lot more engineers wanting meaningful equity and being willing to join earlier-stage companies.

Dinesh: Another big change: as India’s economy grows — potentially becoming the third-largest — the local B2B and consumer markets will, too. Historically, most India-based engineers work for products or customers in the U.S. or Europe, so they’re far from their end users. If more large paying customers emerge in India, that’s going to give Indian engineers deeper insights, making them even stronger product builders.

Utkarsh: Two things:

  1. I see less loyalty — tenures are shrinking. People hop between startups quickly. So if you’re a founder, you need to plan for redundancy. You can’t rely on two founding engineers to stay forever. Maybe equity helps, maybe a bold vision helps, but watch out for that churn.
  2. Generative AI is disrupting how we write software. We need to be careful about over-reliance on AI-generated code and stay thoughtful about maintainability and depth. Engineers should leverage these tools but also up-level themselves so they can be productive without losing deep understanding.

Gaurav: I’d echo that. Hiring and retention will become harder with remote work expanding. Engineers in India can sit at home, enjoy the local culture, and work for a Silicon Valley startup that pays U.S. compensation. Meanwhile, more engineers want a robust engineering culture — autonomy, ownership, work-life balance, and so on. Startups have to deliver on those fronts or lose out.

I also see more specialization — AI, search, data infra, etc. Specialists command a premium. Plus, generative AI will likely create two extremes: a group doing cleanup or interpretability on AI-generated code, and a group of top-tier “10x” engineers who become even more productive by harnessing these tools.

Gopal: This has been a blast, and, hopefully, a bit of a reunion for you all. I really appreciate all of you spending time with us.