Arpit Tandon on the road ahead for Indian IT

Sales cycles, delivery cycles, AI bloat, the disappearance of the middle manager, and more nitty-gritties.

Hi folks. I’m Pranav, and I have a gripe.

I might do a podcast that I might shoot it today, and it releases after 3 weeks. But within that time, something has changed about the world that renders many things about that conversation untrue. This fear of mine manifests itself most strongly whenever the conversation is about what AI is doing to the Indian IT industry.

It’s always nice to do a regular rain-check on the small things that AI has changed in the industry. So beyond questions of whether AI is deflating the business, we end up looking at all the little ways in which they’re trying to turn the tide. New business models, faster sales conversations, slower decision-making (because everyone’s a little afraid of bloating up AI budgets), and a little bit of the technological decisions being made to become AI-native.

So, I spoke to Arpit Tandon.

Arpit has spent most of the last two decades working in the Indian technology sector. Currently, he’s the Director of AI Strategy at the APAC division of Canadian IT services giant CGI. He has also spent a good chunk of his career in Accenture, Dell and TCS. It would be an understatement to say he tracks the subtle shifts in how large service providers are restructuring themselves. He’s an active part of those shifts.

I spoke with Arpit about the structural shifts in the IT services industry. They discussed the transition from headcount-based billing to outcome-based pricing, the real impact of AI coding assistants on entry-level hiring, and how companies are attempting to move up the value chain. I also got him to explain to me, a complete non-techie, a little context engineering and all that :)

This conversation builds on top of the previous conversation on Indian IT that I hosted with Ameya P a few months ago. Together, you can piece a lot of nuances to this industry that will often be missed in mainstream discussions.

Here are a few standout quotes from the chat.

On thinking in workflows instead of products

For years, the software industry was built around selling discrete products. But as AI models become more capable, the unit of value is shifting from the product to the entire business workflow. The product is no longer a standalone tool; it is the entire sequence of human and agentic actions.

“Today, rather than thinking in terms of products or replacing existing products with more efficient AI solutions, a better approach... is to think in terms of workflows. Okay, what my product used to do, what product did interact? And then combine the workflow and then deploy AI to really transform those business workflows.”

On codifying enterprise context

Domain specialisation is a well-understood concept in IT services; perhaps the most important concept in the age of AI. But the true differentiator in the AI era is what Arpit calls the ‘enterprise context layer’ — the unwritten, tacit rules of how a specific company actually operates.

When I mention enterprise context layer, it is about codifying the way each organisation works. For example, to get to a report, if I have to do five different things, if I’m an expert in something... it just sits in my mind. It’s the way I operate, and I become good at it. Translating that intuition onto paper and codifying it... that is a very difficult part. For example, to get to a report, if I have to do five different things, if I'm an expert in something, if I'm an equity analyst and I've been doing it for years, typically it just sits in my mind.

It's the way I operate, and I become good at it. Translating that intuition onto paper and codifying it, that's what skills are basically, what Anthropic releases and some of the stock prices go down of IT firms. So that is a very difficult part. So when you mention about the differences across industries, yes, to an extent, some kind of M&As and some kind of partnerships do help in that to get that domain specialisation.

But, this requires a level of client proximity (which, say, Palantir is known for) that offshore-heavy models often struggle to achieve.

But the second level of context layer where each organisation, how they function, what is their cultural way, what are the kind of language they use or what is the kind of sequence of steps they use, I would say that requires much deeper client proximity. Yes, high-level sector trends and reports are available, but client proximity, sitting with the clients, observing in their offices or at their workplaces on the shop floor, I think those are some of the things that all the tech firms are looking how do we invest in, and that's where this idea of forward deployed engineers and so on also became very popular.

On the illusion of a centralized AI mandate

A common fear among CIOs is ‘AI sprawl’—the uncontrolled proliferation of different models and tools across an enterprise. The solution, surprisingly, isn’t strict centralisation.

AI bloat or AI sprawl is definitely an issue in the industry. But the way I’m seeing many of our customers... the way to tackle it is to have a strong central governance layer, but the usage typically is more decentralised... How they get used, what is the usage pattern, what could be the different budgets... that cannot be centrally decided. That has to be very much on the ground.

The centre provides the guardrails; the edges figure out the use cases. This, of course, sounds like a government.

So taking an analogy for any large country if you take, I mean, it's the same analogy, right? Some of the core functions reside with the federal government, with the central government, but most of the on-ground usage and so on has to flow down, you know, to the state governments, to the municipalities to see the benefits because a central layer cannot govern it all.

But of course, in a government, the fiscal power primarily resides with the centre rather than decentralized units. Is that what we’re seeing with organizations trying to go AI-native? In Arpit’s view, it is far more nuanced.

While the budgets, the actual usage budgets are, in my view or, you know, the organisations, the clients I'm seeing, is flowing more on the ground towards the business lines. So, for example, if, you know, there is a credit function in a bank, it's up to that, the manager of that particular function to decide based on their targets, based on their usage, how much they can allocate the kind of token cost and so on to their team.

On new pricing models

The fundamental business model of Indian IT—billing for hours worked—is under pressure. But moving to a purely outcome-based model is proving difficult, not just for the service providers, but for the clients.

The challenge is most of the firms have been earlier commercially charging on the input or the effort basis... But moving to a completely outcome-based model... there are two points that are hindering that shift. One is agreement on the outcome... The second very important point is, are the procurement teams of large enterprises actually ready for this outcome-based point? That’s the point we often miss.

On the disappearing middle manager

While much of the anxiety around AI has focused on junior developers, the middle layer of IT services is undergoing an equally profound, if less visible, transformation. The roles are not vanishing—they are changing shape.

That still holds true that you need more experts, you need more domain expertise, you need more tech expertise at the middle layer to steer AI. However, what is disappearing is a lot of the roles which involve primarily coordination, administrative tasks, purely project management activities and so on... So on the prima facie it looks like, ‘Hey, the middle layer is declining.’ But no, the middle layer is still expanding, but it is expanding from less of coordination and administrative tasks towards more of domain-based, tech-based expertise.

The future belongs to the domain expert, not the coordinator.

On the future of junior talent

With AI taking over basic coding and coordination tasks, the role of the entry-level engineer is fundamentally changing. The skills that got you hired five years ago are no longer enough. The junior developer of tomorrow looks more like a systems orchestrator.

I have a slightly optimistic view around that... Typically, the junior talent comes into play for the new kind of new age roles or new age skills. Now, roles like somebody who’s managing the different LLM models, who’s seeing the cost of different LLM models, somebody who’s evaluating the output of different LLM models and routing the models... those kind of roles have not become mainstream, but they will.

It was a great, clean conversation, just a little over an hour long. I make multiple references to Arpit’s LinkedIn blog in this conversation, which you may refer to here.

Do listen to the chat, it’s available on YouTube, Spotify and Apple Podcasts. The transcript of the whole conversation is below.

Note: The transcript is generated using AI and may contain some errors.

---

Full transcript

Pranav Manie: Hi, folks. Welcome to another episode of Subtext by Zerodha. I’m your host, Pranav, and today my guest is Arpit Tandon. Arpit is the Director of AI Strategy at the APAC division of Canadian IT services firm CGI. He has been a veteran IT professional, spending time at TCS and Accenture, and holds an MBA degree from IIM Indore.

He has donned a variety of roles in the industry and is uniquely qualified to speak on what AI is doing to the industry. We have also had a previous chat where it was sadly unpublished for various technical reasons. But we are now having Arpit back again to give us his peace of mind on what’s going on. Thank you so much, Arpit, for gracing us yet again.

Arpit Tandon: Thank you. Thank you, Pranav, for having me on your show. It’s fantastic to, you know, be interacting with you.

Pranav Manie: Great. So Arpit, lot of stuff is happening in the Indian IT industry, and obviously we are not even techie, so we don’t really know how to make sense of it.

But I want to start with a blog post that you wrote on LinkedIn, where you were discussing that you were in a client meeting and the client wanted your team to help them reorganise their product team for the AI age, right? And where you were expected to address the field of product management.

That’s a field that was basically defined by tech, right? Product managers at Meta, product managers at CRED, for that matter, right? And this is a field that operates at the intersection of tech, design, and business, right? What did product management look like before AI, and how did it change, how did that relationship between tech design and business change after AI?

And how do you-- what are the impact of that in the field that you’re in?

Arpit Tandon: Awesome, Pranav. So great to start with product management. It’s a space that’s been close to my heart over the years, and that’s dramatically changing with AI. So just to talk about, you know, how product management looked like before AI.

In very simple terms, if you think about this role really gained prominence over the last 10, 15 years when these SaaS firms became big and social media and all the big tech started launching products. So the whole idea was you needed somebody who could understand business very well, who could understand customers well, at the same time, who’s comfortable with the engineering side and could translate the business language to the technical and bridge that gap.

That’s fundamentally what product managers used to do and still do in a way. What AI has done is dramatically made that bridging job more efficient, quicker, and some say it’s easier or not, I won’t really term it easy. But it has dramatically changed how quickly you can bridge that gap.

However, that’s one part of the thing that has really changed. But two other things have happened. It’s just not about translation piece might have got quicker and more efficient. But with AI in the mix, a product manager’s job today is more important to figure out what to build.

See, with AI tools in the hands, it’s very easy for all of us to, you know, consume tokens, spend some money, do token maxing, and build something. But will my customer pay for it? Is it really solving some kind of a problem? I think that’s become a even more difficult question to answer, and that’s a product manager’s job. Another point very important to mention here is today when a product manager is working, you know, designing any kind of system, I don’t really call it a product anymore because product really combines a lot of services, whether human or agentic along with it.

When a PM is working on some kind of a system, what kind of usage will be done by the humans? What kind of consumption will happen by the agents? Combining all that into a seamless flow, that never existed before, and that’s a completely new way of thinking that today the PMs need.

Pranav Manie: How do you look at a product today?

Because I think there’s a blog post of yours that I remember where you said that people should think not in terms of products anymore but workflows. Help me visualise what you mean when you say that, because that’s what I feel like you were hinting towards in this answer of yours.

Arpit Tandon: Yeah, absolutely. Absolutely, Pranav. See, earlier, the thing is, in every department, for example, if you are hiring a candidate, recruitment team used to have their own systems to screen, manage the candidate flows. HR system would have something if the candidate gets onboarded, they would have something to manage.

With AI, the efficiency not only comes in improving the existing one system. Nobody stops AI from reaching out to the candidate, to the recruitment function, to finally the HR function and obviously, finally, the onboarding to the business teams. So the whole idea is typically the efficiencies in AI come from the workflows, the entire workflows, and not just from software system.

See, Pranav, just to simply explain, software systems or SaaS systems were mainly meant for human consumption because as humans, we can only consume this much amount of information. I can be an expert in something. But when AI is consuming information, it doesn’t consume in one system. It makes better sense when it is combining and trying to link out the parallels across the systems, and that’s where I mentioned in the blog post.

Today, rather than thinking in terms of products or replacing existing products with more efficient AI solutions, a better approach, and a lot of companies that are seeing benefits, a better approach is to think in terms of workflows. Okay, what my product used to do, what product did interact?

And then combine the workflow and then deploy AI to really transform those business workflows.

Pranav Manie: I think one debate that I’ve seen quite often on social media around this idea of workflows is that workflows can always change, right? Because the next day you have A Fable 5 that completely changes the workflow that you had built and renders it fair to some degree useless, right?

How do you think of not just the division between workflows and SaaS products, as you’ve mentioned, but also the division between, oh, today’s workflow is not gonna be tomorrow’s workflow. There is an entire possibility that we will need to change everything in the next week, especially if you’re working with a client that demands very quick turnaround times.

Arpit Tandon: So Pranav, no, I would slightly disagree on the point that workflows would change. Yes, the models change. So what happens is if I decide that this is a specific workflow, whether around procurement, whether around sourcing, whether around supply chain, whatever it is, and we deploy it with whatever model.

Yes, tomorrow it’s very much possible and probable rather that tomorrow Fable 5 will come, maybe Fable 6 comes or whatever. They are much better. So the way to think is if a better model comes, and a better model will come, will it improve my workflow? Will it improve the efficiency of my workflow or will it really render my workflow useless?

If it renders my workflow useless, then maybe I have not really thought about fundamentally on how to really change it and I’m thinking only in terms of models and intelligence layer. But if I really think about a business workflow, see, Pranav, the way we work together or the way any task gets done, for example, when you write reports, or equity analysts work in Zerodha, I’m pretty sure the work fundamentally remains the same.

They look at the same parameters, they look at the same metrics and so on. But what model they use or you know, how quickly they can do it, those elements can change.

Pranav Manie: So I mean, I think this is a question I will ask you maybe towards the end of this conversation about LLM skills versus access to frontier models.

But that’s a very helpful frame of thinking that we’ll eventually get back to. I want to move from talking about this idea of products and workflows to workflows within domains, right? And domain specialisation has now become this huge factor in the AI world, right? Where all Indian IT companies seem to be focusing on this idea that industrial knowledge is everything.

And every enterprise, as you’ve said in your blog post as well, is that the enterprise context layer matters a lot. Which is that whatever AI workflows you’re designing, it has to know how the company works, right? How the industry works, right? How do you see the workflows differ from say, healthcare versus banking, right?

On one hand, say you have a company that works on streamlining drug discovery, like using a bunch of pipelines. I have no idea how they work, but I’m sure drug discovery is a very, very complicated process as such, and it

Pranav Manie: literally results in life or death, right? So Indian IT companies have to take it very seriously when they’re working with a pharma client.

But on the other hand, you have, say, a European bank, right? You are building software for them that has to adhere to European regulations, which can be quite strict. How do workflows for one differ from the other? Like, how much of the difference in context is important when we are talking about domain specialisation?

Arpit Tandon: So, no, no, no, that’s a very intelligent question. Thanks for asking. I would say the differences lie at two levels. One is across industries. So you asked how would the workflows differ from, say, healthcare to a banking sector. So there is a dramatic difference, and the dramatic difference comes from the sequence of steps, the language used, the complexity of the documents, what we are trying to achieve.

So there is a lot of difference across industries. So that is where you see a lot of, as you rightly said, Indian IT firms, in fact, mid-size are moving faster. They are acquiring a lot of those other firms in niche sectors and niche geographies to get that domain specialisation. That is important. But I would say when I mention enterprise context layer, it is about codifying the way each organisation works. For example, to get to a report, if I have to do five different things, if I’m an expert in something, if I’m an equity analyst and I’ve been doing it for years, typically it just sits in my mind.

It’s the way I operate, and I become good at it. Translating that intuition onto paper and codifying it, that’s what skills are basically, what Anthropic releases and some of the stock prices go down of IT firms. So that is a very difficult part. So when you mention about the differences across industries, yes, to an extent, some kind of M&As and some kind of partnerships do help in that to get that domain specialisation.

But the second level of context layer where each organisation, how they function, what is their cultural way, what are the kind of language they use or what is the kind of sequence of steps they use, I would say that requires much deeper client proximity. Yes, high-level sector trends and reports are available, but client proximity, sitting with the clients, observing in their offices or at their workplaces on the shop floor, I think those are some of the things that all the tech firms are looking how do we invest in, and that’s where this idea of forward deployed engineers and so on also became very popular.

Pranav Manie: I think one would say that there can be multiple different ways of manufacturing a phone, and multiple companies use different organisational structures to manufacture, say like if you’re comparing a Vivo versus an Apple, right? That’s the parallel that I can describe, and I assume a similar parallel might exist within companies in the same sector.

Arpit Tandon: Absolutely. Absolutely, Pranav. I think that’s the point I was saying when you have to codify that enterprise context. So as you rightly mentioned, how Vivo manufactures a phone versus an Apple, I think that is the key or that’s a moat, that’s a moat that an enterprise has their internal processes that helps them develop that kind of product.

Now, codifying that process into agentic workflows, that needs a lot more client proximity, that needs a lot more closer partnership than typically what we have seen till now or typically in the IT world till now.

Pranav Manie: A term I’ve heard very often in this context, no pun intended, is this idea of context engineering, right?

And within that, I’ve heard one term that I don’t understand at all is retrieval-augmented generation. What is RAG, right? Where does it sit in the broader context of context engineering, right? Like, how would you explain it to a complete idiot like me?

Arpit Tandon: So basically, these LLMs are stateless.

When I mention stateless, basically when you type something into an LLM, it gives you a response, it gives you a probabilistic response. How it functions is a complex mathematics behind it, but it gives you a probabilistic response. The next time when you ask it again, it starts fresh and it doesn’t remember anything.

So all the things around it, the memory, from where it pulls the information, how it searches, all those are external engineering systems that are built around LLMs. Now, that is all context engineering, what you want to provide. Now, coming to your RAG portion, retrieval-augmented generation. The whole point was, for example, an LLM can be typically trained on vast amount of publicly available information.

But I can have a document, I can have a confidential legal contract based on which I need to extract or understand some clause around it. How do I provide it to the LLM? If I provide the whole document, each LLM has a context window what amount of information you can give, and then it becomes very expensive to compute.

So the whole idea was that you provide an external knowledge source, and if I say, for example, if I say I want to search a clause 2.1.1, so rather than giving the whole document along to the LLM, what happens at the back end is first there is a retrieval happening that you retrieve this clause 2.1.1. You pull out, so there is some engineering, how much chunking, how much information you pull out from that clause, add it to your prompt at the back end, and then the LLM understands that context and gives you response.

So that’s a very cost-effective way of using external information without every time fine-tuning the AI model.

Pranav Manie: And the LLM is not involved in this chunking process as I understand it. Please correct me if I’m wrong. The LLM is the last call of this.

Arpit Tandon: Yeah. So all that engineering happens, whatever you need to retrieve the information, you need to chunk it.

You only add it to the LLM in the prompts, and the LLM responds. Obviously, all that happens at the back end sometimes, so a normal user wouldn’t observe that.

Pranav Manie: Makes sense. And this principle, I’m assuming, is true across industries even though the workflow of how the context is managed will be different.

Arpit Tandon: That RAG portion remains constant. That’s the concept. Now, how do you, what amount of document you use, how much chunking you do and all are engineering matters that differs from workflow and the outcomes you want to achieve.

Pranav Manie: Got it. Now you keep doing a lot of this context engineering work, especially in these days, right?

And you do it for enough clients, you do it in a way that you start looking at reusable, repeatable patterns. When do you start, if at all, when does this process show potential to turn into some kind of intellectual property platform?

Arpit Tandon: Well, that’s a slightly difficult question and I’ll come to why.

So what happens typically is when there is a use case or there is a business idea that somebody wants to achieve, and when we discuss with our customers, our clients to understand what they want to achieve, what they have, the first basic thing to start, and that’s where the potential and the promise shows up, is what kind of information or what kind of codified knowledge we can get.

Sometimes some organisations can have a lot of rich available documents or richly available processes laid down, so that becomes a highly promising source. Some organisations have typically worked more on human relationships and more of intuition basis, so then it becomes can we partner with them and sit down and codify that knowledge?

That obviously takes time. So once that codified knowledge comes into picture, once we are able to feel confident that whatever the input, whatever the context layer that we need to build around any company, if that is there, then obviously that’s when the promise starts showing up.

And if it’s generic enough, then it depends. Obviously, a use case can be for one department, multiple departments. If, for example, there is a process that is commonly followed across multiple departments, then that’s a codified knowledge. You basically write a skills file, write in English, simple English language about the process and so on.

And if it is repeatable, if it can be used across departments, then typically we can look at figuring out if it’s an intellectual property for the organisation.

Pranav Manie: Got it. But, and this is a paradox that I think might apply to other industries as well. If when you say that a repeatable pattern turns into an intellectual property of some kind, right?

If it’s reusable, then it’s likely that there are other competitors who can replicate the same thing. What stops domain expertise from just being commoditised then? And on a deeper level, what does it mean for intellectual property in the industry then?

Arpit Tandon: Yeah, I think it comes to what is your competitive differentiator or what is the moat you’re having in this case.

So while context in itself is not the moat, it’s a combination of multiple things, Pranav. So I would say combining the right context layer, combining with the right model routing to have an optimised cost around it. You can’t give the context to the most expensive model every time to achieve basic outcomes. Having the right harness. Harness is a very commonly used word these days. What kind of external systems you can access, what kind of,

Arpit Tandon: context you need to summarise, what kind of context you need to drop off along the way, and so on. When you combine these three or four elements, your harness, your context layer, your model routing, and obviously some kind of AI governance around it, human oversight.

When you combine these things, then you start in my opinion, start getting some kind of a differentiator. So differentiator doesn’t come only in one element of the stack, but when you combine three, four complex elements to achieve a outcome, that’s when you see lot of differentiation in the performance.

Pranav Manie: So what’s an example that you would give of such a differentiator? Like, if you had to use industries, you have to use enterprises, what’s an example that you can give?

Arpit Tandon: I mean, I’ll use a simple example that everybody knows about Claude. Anybody who’s used Claude Code, Claude Code seems very different than when you are just using Claude in a simple chat or in a simple, directly you are using a Claude model for coding.

If anybody has used not for coding, for any purposes, for even for co-work, if you are making a deck, if you are generating some kind of a fancy report or artifacts. The reason why it works so well, Claude Code or Claude Co-work, is the combination. Yes, the model remains the same what you can externally get, but the harness around it is brilliant.

Then you know how do you connect it to the access to the different system files and so on that Claude Code is able to generate. A human oversight is anyways different. It depends on the human to human. But I think these factors combined makes Claude Code so much better than competitors.

While Codex is catching up, but the idea is that rather than only the model, developing the right harness, developing the right engineering system around that model gives you the competitive differentiator.

Pranav Manie: Because you’d addressed that a lot of IT companies, I think just a few days ago, Persistent Systems made their biggest acquisition in their history. Obviously, over the last few months, we’ve been seeing HCLTech, Infosys buy companies left and right. Coforge, also a very strong rising giant, has bought a company called Ancora for some $2 billion. Can you buy domain expertise through mergers and acquisitions? And how often does it fail? Because usually mergers and acquisitions have a pretty mixed track record.

I’m not sure what the track record looks like overall for Indian IT. But can you buy expertise like that straight up, and how much time does it take to integrate it?

Arpit Tandon: Yeah, that’s a good question. I would say you can, to some extent, when I was talking about the context earlier, the industry context, the industry, you know, general processes, knowledge about the generic processes, the language and terminology, those you can, yes, get through M&As and plus the client relationships.

I think that’s a very key element for these acquisitions. I think the key reason for these acquisitions is often not only the domain. Yes, domain is one part of it, but also the client access, access to their decision-makers. That you can get. But to really integrate and get sustainable benefits, what you need is to bring some kind of your client proximity to those existing relationships.

When I say yes, for example, you get some access to certain clients in the banking system, you get great understanding about a specific geography, about the regulations, whatever accelerators they have, you get the client relationship. But unless, until you are able to build the proximity, you are able to develop that relationship, you are able to bring other services and integrate them with your overall solution, then that’s where the challenge lies with these M&As.

Oftentimes, one of the biggest things that AI is changing in terms of services, what I am seeing, a lot of organisations have, I don’t want to take the names for now, but the fact that offshoring, yes, while, you know, sitting afar you can do a lot of the work, but that understanding of sitting in face-to-face and figuring out how they work and codifying that knowledge, that differentiator has become 10X more important than what it was before AI age.

Pranav Manie: Great. And that I think leads very naturally to this idea of understanding how the sales side of IT has changed, because I have a bunch of questions on that front, and you’ve written quite a bit on that front. The first thing that I want to ask you is that idea of sitting face-to-face with the client and understanding how their business works, right?

Because that’s something that you would find very common in management consulting firms like Bain, McKinsey. You would find in IT consulting firms where you go, you sit with a CEO, not necessarily just the chief information officer, but also with the CEO or with the board, right? And you have a blog post where you’ve talked about, oh, you know, sales team must map these processes before you start recommending AI solutions, right?

Does that put IT services more akin to a consulting business, the way Palantir does forward deployed engineering, so to speak? Does it put IT services on a possible trajectory where it goes closer to consulting?

Arpit Tandon: Yeah, Pranav. That’s a very structural industry shift that is possible. And I’ll come why I think that that could be the potential path.

So first we have to see who have been the decision-makers earlier for all these large tech contracts and who could be the potential decision-makers going forward. So earlier, most of these large contracts in Fortune 500 companies came from enterprise CIO offices. While that is still true, it’s not that contracts not come from there.

But with AI, money is going where the accountability lies. I’ll repeat the term, where the money is flowing, the budgets are flowing where the accountability lies. And typically, if you deploy agents, AI agents in, say, an HR workflow or a supply chain, the accountability at the end of the day lies with the person who’s heading that supply chain function or who’s heading that HR.

So what we are seeing in the industry is a lot of these budgets, these tech budgets are kind of, you know, also coming from the business functions. As CIO functions also have a, you know, lot of role to play to manage the existing functions plus, you know, build the central AI layer. But this decentralised, this thing is becoming important.

Now, coming back to your question about the consulting approach. Yes. So unless and until the tech services firm, the IT services firms have relationships on the business stakeholder side, unless and until they are able to understand all these priorities of the department heads, the business unit heads, it becomes very important to, you know, align IT to that.

Because today, your AI deployments in silos do not serve any purpose, it rather increases the cost. So that obviously builds a very natural way that many of these IT services firms are today looking how to deepen their business consulting, how to deepen their business relationships. And while it can have some similarities going forward on the consulting path.

Pranav Manie: It’s a very helpful answer because, like, I can imagine that, you know, you have an HR head, you have a marketing head, you have an ops head, and these are all points of accountability as you’ve mentioned, and they want to adopt AI for their particular function. But as you pointed out and I wanted to ask whether does this create the possibility of AI bloat, if that’s a term, similar to the kind of bloat that existed when SaaS software when SaaS was a big thing, right?

You have this idea of SaaS bloat, which became very popular a decade ago, where within the same company, like, say, if you’re Facebook, right? And you’re such a large organisation, but you don’t have one person that’s overseeing all the software. You have multiple different people, multiple different heads of functions buying different kinds of software, and that creating a lot of procurement bloat.

Do you see that kind of thing happening with AI at the moment?

Arpit Tandon: Yes. AI bloat or AI sprawl is definitely an issue in the industry. But the way I’m seeing many of our customers and we even as an organisation and many other organisations, the way to tackle it is to have a strong central governance layer, but the usage typically is more decentralised.

Let me explain. So, you know, if you are using say ChatGPT, Claude, whatever, the usage of it, the governance rules, what you can do, what you cannot do, where it will be hosted, all that should be centrally governed by, you know, some office, whatever, you know, is decided by the organisation. That cannot be decentralised, otherwise you’re mixing things up.

However, how they get used, what is the usage pattern, what could be the different budgets, what kind of roles would use it in what ways, that cannot be centrally, you know, decided. That has to be very much decentralised. That has to be very much on the ground, otherwise it becomes a mandate that people use tools without any benefits.

So taking an analogy for any large country if you take, I mean, it’s the same analogy, right? Some of the core functions reside with the federal government, with the central government, but most of the on-ground usage and so on has to flow down, you know, to the state governments, to the municipalities to see the benefits because a central layer cannot govern it all.

Pranav Manie: You read my mind. I was just going to use an analogy of industrial policy because we’ve been having a lot of conversations on Subtext around industrial policy, and obviously Indian industrial policy is one where you have the centre or for that matter, in China, obviously the biggest test case where you have the CCP, the central government, but a lot of the work is actually done by local provincial governments.

Pranav Manie: But using that analogy, usually the lever of control with this idea of strong centralised governance but decentralised usage, the conflict point ends up being the budget, right? How do you look at that conflict evolving with the era of token maxing coming to-- seemingly coming to a decline?

Arpit Tandon: So yeah, you are very right, Pranav.

Token maxing, I think, has almost not just a decline, I think it has its time. It had its glory days. Now I think the focus is more towards token optimisation or tokenomics as many people call it. So I won’t say there is any kind of conflict, but the line typically is the central governing function is more focused on the tech side of it or making it sure that it seamlessly connects with the other systems, it seamlessly remains secure, and so on.

While the budgets, the actual usage budgets are, in my view or, you know, the organisations, the clients I’m seeing, is flowing more on the ground towards the business lines. So, for example, if, you know, there is a credit function in a bank, it’s up to that, the manager of that particular function to decide based on their targets, based on their usage, how much they can allocate the kind of token cost and so on to their team.

If some team is really not seeing the benefits, it could be cut, and so on. So the central team typically would not be holding the token budgets. Otherwise, it becomes a... Yes, there could be, you know, you can provide a certain base level of tokens to everybody and then decentralise, but I don’t see a conflict. Rather, I see very complementary roles played by the central team in providing a base level of, you know, AI access, enterprise access to everybody. And then that could be complemented by different business units based on their individual P&Ls and so on, and what outcomes they achieve.

Pranav Manie: If I’m understanding this correct, the centre provides some kind of baseline access, but each of these functions decide how they want to use that baseline access as and when they want.

But does that process also create-- So for example, a lot of clients, a lot of companies in these industries have what is called an enterprise resource planning system, right? Which is a centralised, something like SAP basically, right? Which is a centralised, I’m not sure software’s the right-- I guess software is the right word to call it, but where it connects everything from inventory to finance, right?

Like, every system of record mentioned, like, that’s entered by, say, a finance head, has to balance out somewhere because it has to show, like an accounts receivables has to have an accounts payables, right? So that kind of balance sheet balancing is something that SAP does. Does this kind of decentralised approach with AI, does it conflict in any way with the centralised nature of how ERP systems work?

Arpit Tandon: Absolutely not, Pranav. In fact, it again complements that. So if you see an ERP system, yes, the central system of records remain the-- that remains the single source of truth and... But the kind of reports, so for example, you work in a function, I work in a different function, the kind of reports you can generate will be very different from the kind of reports I can generate from the same amount of data.

So that applies to, you know, even AI deployments as well. So as I mentioned, the central team, the CIO or the CTO team in any organisation, their job is to make sure that, you know, the intelligence layer sits on top of ERP, that system of record. It has access to the different platforms, the tools and so on. But how they would be used, what kind of data will be pulled out, even the source data remains the same. There is no change in that or this thing. That does not, you know, get altered by the business units. But the usage part of it, what reports, what kind of information they want to access or what kind of, you know, workflows they want to get into, those can be decided by the individual business lines.

Pranav Manie: Understood. That helps frame things better. With all of this that we’ve discussed about sales and product, right? From where I sit, it seems like sales and execution, right, like the final-- like the ultimate delivery, they’re increasingly being blurred out. Earlier, maybe you had very specific salespeople teams that reached out to clients or had client relationships, would talk to them.

Then the execution team would give you the demo, and that process would take two, three months until you finalise the deal and you were like, “Oh, you know, we have locked you in for five, 10 years, and you are now our client.” Right? And obviously, that was also characterised with sales teams often over-promising certain deliverables, right?

Has that changed with-- Because obviously the conversation now is clients are demanding very concrete productivity improvements in terms of numbers or in terms of actual outcomes, right? Which is why the industry seems to be moving into an outcome-based pricing model. How do you look at this particular blurring of the lines between sales and product, and how much has the line actually blurred?

Arpit Tandon: It is in the process. So, Pranav, AI has given the power to all the non-technical folks as well to use technology. That’s the fundamental. I was-- I just was visiting a doctor sometime back for some health checkup. And therein I saw some of the health professionals. They were using AI really to check out few things, and then they were using as good as any tech professional would use.

So I think the lines between what a tech professional can do and a non-techie can do have blurred. Now, coming to your point about sales and product, yes, these two functions have again got closer. So the way I am looking at it, what’s happening in the industry, if I’m a salesperson, if I’m sitting in front of the client, yes, there is an expectation to very quickly show a prototype.

There is an expectation to come up with faster proposals and so on. So the sales team obviously is expected-- So for example, if there is a team sitting somewhere and, you know, they are working on the proposal, earlier my role would be to get on the meeting, explain them 100 points what I discuss and so on.

Right now it’s very easy for me. It’s rather easier and better if I develop a very simple prototype for them using AI, some kind of an image or even a working software, a very simple one, pass it to the team and, you know, based on that, they can estimate the overall production cost, understand what needs to be built, and work out a faster turnaround time.

So in that sense, the roles still remain same because, you know, sales need much more relationship skills that have become more important. The product teams need to think more about longer term AI management, longer term AI deployments and so on. So that expertise definitely remains where it was in some ways.

But today, any individual, you know, whether in the sales role or product and definitely in the sales role, is expected to capture those discussions and rather than only talking, may be able to show something that is working in real time.

Pranav Manie: How much faster has it become for you? Because you’ve mentioned now that, oh, earlier I would spend time on a proposal.

Now I just like, “Oh, you know what? I’ll just whip up a demo and I’ll send it to you.” How much faster has it become for you personally going from demo to market?

Arpit Tandon: Turnaround times can even be cut by, at least what I have seen in some of the cases, by 40 to 50% easily. Because you-- rather than, you know, getting into those endless meetings and so on, if you can just develop some kind of a working prototype and share with the team, it’s very quick to get the feedback and, you know, things rolling across.

So I think there is definitely a lot of benefit.

Pranav Manie: Got it. And with how faster it has become to move from demo to market, I’m assuming other IT companies will be looking to doing the same. Has that increased the competition for deals? How do you see the industry competition that way shaping up?

Arpit Tandon: Industry competition, I think this has always been a very highly competitive industry, so it remains so.

So I don’t see that industry has suddenly got more competitive because of AI. But yes, there is a pressure to, you know, have faster turnaround times and respond to customers quickly and so on. That’s definitely there. But that doesn’t necessarily result in more competition immediately for the same market.

However, one trend that I am seeing is your addressable market or the kind of customers that you can reach out has definitely evolved. For example, if I had only 10 hours earlier, and if I could respond in that time only to one proposal, I would only do it maybe for the largest deal. But if there is a mid-sized client, if there is a mid-sized deal that earlier I would skip because I did not have time, now because I have the bandwidth to respond to that proposal because of AI, then definitely that expands my market to smaller deals that were earlier economically less viable.

So that expands your market to maybe mid-sized clients, mid-sized deals and so on. So not necessarily increasing the competitive intensity in the Fortune 500 segment, but I definitely see that trend happening where the addressable market expands to mid-size clients and niche geographies and so on that were earlier unserved.

Pranav Manie: The only thing that I noticed around this was-- And this is where I think we move on to the broader industry And because some of these things were also said in quarter four of last fiscal year by the various Indian IT companies that are publicly listed, right? So I think both Infosys and Wipro, I think in their earnings calls, said that they deliberately stayed away from deals that did not meet their margin guidance, which has more or less remained the same as in the last quarters, right?

Pranav Manie: But on the other hand, you’re telling me that now with AI, y- the space to address those kinds of deals at least has increased, right? How do you look at this contradiction? Can India’s largest IT companies afford to forgo deals that do not meet their margin guidance? That’s obviously, a kind of a deeper industry shift that’s happening.

Arpit Tandon: While I cannot comment on the exact deals that, you know, Wipro or Infosys had to forgo or this thing, but, there has been definitely an overly focus by, by the large firms on their margins, and that has given space to a lot of the mid-size firms to start gaining market share. So that’s definitely a shift.

If you look at the growth rates, if you look at the kind of deals that are being won in different geographies, there is definitely a, an interesting trend happening, w- what we discussed. Now, coming to the large firms, whether they can, chase those mid si- mid-segment market or so on, now it’s up to each organisation what they want to do.

But the fact is also the kind of incentives, the kind of quotas, the kind of, bonuses you give to the salespeople and all that has to evolve. It cannot be remained the same for the same for both across the segments, so mid-size and the Fortune 500. So there is definitely s- large firms definitely take more time to leave, to shift maybe- Not leave.

But when I look at the industry, what AI is fundamentally changing, I definitely see a lot of the midsize firms growing at a faster rate bec- not because they are chasing the same market, but because they are expanding their addressable market and getting into niches where now it’s very much economically viable to, serve those deals.

Pranav Manie: So if I’m reading this right, if I had to summarise what you just said, you might say that midsize IT firms are somewhat eating large firm, the lunch of lunches of large firms, because large firms tend to be-- tend to have more inertia when it comes to reacting to how things like margin guidance, which has always been a key feature in every earnings call.

Arpit Tandon: Yeah, at least the, the numbers and, you know, the anecdotes definitely suggest so. The, the big, big-- Simply because, you know, the, the market itself, the addressable market, what you can do has changed, and I think large firms have yet to respond to what they can potentially do rather than only focusing on becoming more efficient with the current.

But there is a huge market waiting, outside that can be chased.

Pranav Manie: Got it. I think a lot of the inertia conversation around large cap firms tends to rotate around the business model, which is the headcount-based, shift away from headcount-based billing to outcome-based billing. But I think this is the shift that I don’t think I had particularly foreseen, is that how do you react to a new addressable market opening up for you?

Or how do you decide? Because now that I look back at it, margin guidance is something midsize firms may or may not choose to tell you because they’re like, “Oh, we don’t really want to tell you guidance because that’s not how we work.” But for large firms, it’s always, “Oh, this is twenty, twenty-one percent is what we’re aiming for next year.”

Yeah, absolutely. On that note, that being said, there is-- there were some shifts that, we were able to see away from headcount-based billing, at least for the largest firms. For example, Tech Mahindra, I think in their earnings call, announced something called a serviced, service token-based pricing, right? Where they divided each function like finance and accounting operations into its own token, right? And within, like, each sub-function, there was a certain amount of work attached to it, and billing was based on how much that work could be decomposed into human work and agentic work. That is one example of a model that we have seen.

How much progress do you think this represents in that entire conversation around headcount-based billing versus outcome-based pricing? And do you think there is still room to change?

Arpit Tandon: Yeah. No, I think, that’s becoming a very fundamental, point for the whole industry about the commercial models. I would say in very simple layman terms, I would divide the commercial models, at least for the tech services industry, in three buckets: input or effort-based, second would be output-based, and the third would be outcome.

Now, the challenge is most of the firms have been earlier, commercially charging on the input, or the effort basis. Now, it could be T&M basis, time and materials, headcount basis, or it could be fixed price, it could be, you know, cost plus or whatever, but at the end of the day, it was effort basis. But moving to a completely outcome-based, model I would say there are two points that are hindering that shift.

One is agreement on the outcome. So a lot of these firm, whatever, when they service, both the client and the, and the supplier or the vendor have to agree on some kind of an outcome metric based on which the commission is based. It’s not always easy to arrive at the single number. It’s not always, simple to agree.

That’s obviously a friction point that’s, hindering that, movement. The second very important point, Pranav, is bigger shift, that, Pranav, we are seeing is about the, are the procurement teams of large enterprises actually ready for, this outcome-based point? That’s the point we often miss.

See, as long as we often focus that, you know, IT services have built a huge headcount around that, but we also have to understand that many of these Fortune 500 firms, huge procurement departments, you know, huge IT teams built over the years that do vendor management and so on. So are they ready for that shift, because that requires a lot of changes, on their side as well.

So unless until that aligns and that-- it’s not that that’s not changing. Gradually, it’s on the table for every organisation. But that shift typically will take some time. And in the meantime, you will see some of those interesting models that you mentioned about Tech Mahindra, and I, I had seen that sometimes, you know, it, it’s slightly more on the output side of the model, what you can do, what agents are doing, what humans are doing.

So, you know, it’s not completely outcome basis, but you are trying to, you know, bridge the gap and come up with, interesting, commercial models in the middle for now.

Pranav Manie: This is something that in our podcast with Amir P. as well, he had mentioned that agreement on outcomes is 100% not easy. But who has leverage in that conversation?

I would assume it’s the clients because they’ve now realised that the competitive landscape has changed in favour of them. How do you see the leverage in that deal, right? Where if I’m an IT services firm and you’re a client, right? And now you have that power, but at the same time, you’re also telling me that the client has to now think about, “Oh, how do our own procurement teams deal with this shift?

Are they ready for this?” How, how do you think of that leverage?

Arpit Tandon: I-- Rather than seeing as a direct leverage, I would frame it more as an opportunity for closer partnership. So earlier, it was a very-- It has been a vendor-supplier relationship But typically the outcomes are not very clear when, the technology is relatively new and the deployments have yet not happened.

It opens opportunity for closer partnership rather than very strong SLA-based vendor-supplier relationships. So I would say the leverage part, I won’t really focus too much on it, but, it-- because unless and until, really it’s very difficult for SLAs to come up when you have not even deployed any agents.

It can come maybe three, four years later or five years later. But for now, the opportunity is more for closer partnership to jointly figure out things, whether on the commercial model, whether on the agents or, you know, whether on the workflow, transformations.

Pranav Manie: Correct me if I’m wrong, but I think a helpful analogy parallel to this is, Foxconn and Apple’s relationship, right? I think a lot of people might tend to think that the relationship is very, oh, Apple gives you-- like they’ll give you SLAs and you work on them, et cetera, et cetera. And because you’re Foxconn, you operate in such a lowly business or whatever. But the relationship-- But it’s fundamentally entangled. They cannot separate from each other.

Apple cannot find another Foxconn, and Foxconn is also trying really hard to find another Apple, but it’s not easy.

Arpit Tandon: Absolutely. I mean, that’s a great example. Even it came to my mind, you know, when I was thinking, because that’s the most famous corporate example of a very strong partnership. And, and just imagine what it can do.

It has changed the fortunes, like it has created some of the largest companies in the world and maybe changed the economics of some of the countries, in fact. So I think that partnership models can definitely evolve now, in, in this era.

Pranav Manie: And you think that there might be a future where an IT services firm ends up using that model to like very large scale?

Arpit Tandon: Absolutely. I think I definitely see possibilities when we see what is possible. I see a very strong possibility of that, some kind of, you know, closer partnerships, with different businesses evolving rather than only vendor-supplier. Yes, that remains a strong commercial model. Some of the firms can really build some close commercial partnerships that can, you know, change the complete game and, you know, take things to another level.

Pranav Manie: That’s a lot of food for thought. But with that, I will move to the last section, probably the most, existential section of this podcast, which is this entire idea of sovereignty, right? Because we have so far talked about token maxing and LLM skills and frontier access to LLMs and all of these things, right?

Pranav Manie: But I think the only thing that’s changing faster than AI is the geopolitics of AI. I personally don’t like geopolitics, even though I have to deal with them, right? Two years ago, you had written a blog post on LinkedIn saying that LLMs may become more fragmented and even more skewed towards open source.

There is an article on Rest of World, I think, that was released just one, two weeks ago, that was looking at this trend of American startups increasingly adopting, in fact, faster than they adopt Claude, ChatGPT, but they’re adopting open source models, particularly those from China, right? And obviously, these models get the work done at a mere fraction of the cost of an Anthropic or an OpenAI, right?

But in Indian IT, the conversation is a little different, right? Because I see large companies like Infosys doing enterprise deals with Claude, right? But from where I sit, that looks to me like a lock-in, where you’re locking in frontier access to an LLM. But what does that mean for LLM skills? Like, how do you look at these differences in strategies where, you know, one is dependent on frontier access, but the other creates skills regardless of what LLM you use.

Arpit Tandon: No, I think geopolitics has definitely become very important in the AI conversation. AI is not complete without geopolitics these days. So I think this, when we talk about sovereignty, I think if somebody in India is deploying AI models in critical infrastructure, for example, ports, airports or railway stations and so on, that discussion is very different from what Indian IT is trying to do.

Now, we have to remember primarily a majority of the customers of these Indian IT firms have been clients outside India. So the way I am seeing the firms typically doing these partnerships are rather than relying on a single LLM provider, rather than relying on a single frontier lab, they want to have partnerships with different providers.

And that partnership obviously often depends on what my customers are asking for. Your customers could be located in a certain geography. My customers could be located in a different industry, in a different geography. What kind of models are they asking for? If they are asking more for Claude, for OpenAI and so on, that’s where the partnerships will go.

If those larger enterprise clients start asking more for open source, I’m pretty sure you will very soon see those partnerships coming through as well. Framing this discussion rather than what if Fable Five gets stopped and so on, I would frame it, what the customers are asking for and whether I have a relationship to be able to serve them.

I think that’s the way Indian IT is focusing on.

Pranav Manie: Got it. And when an Indian IT firm has that conversation with a client, right, I would have assumed that the conversation’s primarily around the discussion of outcomes or rather even input effort, rather than deciding what model to use. “We want to use Claude because we’ve seen that it gives us great whatever.”

Like how much of that features in those conversations rather than, say, outcomes or input?

Arpit Tandon: It is surprisingly quite high. That is an important element. So while theoretically you are right that a client might say, “Hey, I need these outcomes. You go and figure out what model you need to use.” But no, there is an element that all these technologies, these famous names, the tech labs, have become a part of our daily lingo, have become a part of the daily usage.

And they do influence the thinking of the client executives as well. So yes, it’s important that... Sometimes there could be a mandate, no, that we have a partnership. So often, Pranav, it’s possible that the client might first do a partnership with the tech firm and then do a partnership with the services firm.

So in case if that happens, then you know you are locked in with what the client wants. In some cases, the client might have a soft preference. I think Gemini could be better than Claude, Claude could be better than OpenAI or whatever. Then obviously you do a cost-benefit analysis, you do a pros and cons, SWOT analysis, and see what works well in the case.

But in many cases, what we are seeing is clients first do a tech partnership with whichever firm of their choice, and then come to the services. I have a partnership. Now you figure out with them how you’d want to deploy the model. So both are possible situations.

Pranav Manie: Understood. That is super helpful.

In our last conversation, you had mentioned that a deal like Infosys signing with Anthropic is motivated by the idea of API distribution, right? Because like you said, right, a system integrator could recommend... Or for that matter, even a client, if they’ve signed a deal with Anthropic or whatever, a system integrator recommends that the client use the Claude API, right?

But that also means new recurring revenue for Anthropic. Do you think that particularly amplifies the risk of dependency on just, say, Anthropic or OpenAI?

Arpit Tandon: It does not. Obviously, when you deploy any of the large mission-critical systems using any of the models these days, there is a huge dependency on any of the LLM provider.

I would not be the right person to say that. I would be a fool, in fact, to say that there is no dependency on these AI labs. Of course there is. But at the same time, what I’m also seeing in any of the large scale deployments, very rarely today you see only one model provider or two model providers.

Typically, there is a whole model routing system where you have multiple models available for multiple users, and you can route them differently, and so on. Obviously, you would figure out which works best and prefer that. So in that sense, I don’t see a very huge engineering dependency.

But in terms of the overall AI market, the kind of models that are coming out, there is obviously a huge dependency on the AI labs, what work they are doing, so that would definitely be there.

Pranav Manie: I’m sure you’d also have conversations with clients where the client themselves might also be wary of these kinds of dependencies, right? Like they’re like, “Oh, you know what?” Because they’ve read the news, Stable 5 got cut off or whatever, right? How does one manage around these external constraints where you don’t have access to frontier models?

Or you cannot use that access to frontier models just because your client says, “You know what? Like, let’s figure out a different way to do this.”

Arpit Tandon: The answer lies definitely in a multi-provider, multi-geography, and multi-technology partner or multi-cloud solution. So typically, the way most of the tech services firms are approaching it is to have multiple options for multiple industries and multiple geographies.

Rather than depending on only any of the frontier labs, yes, those are there, you can always have options. Now, when you mention Chinese open source, Chinese open source is typically 12 to 14 weeks behind the frontier models, so it’s not that they are far behind. So that’s where the answer lies.

Now to your question, what happens if a frontier model access gets restricted and so on, that is obviously happening. And the way to deal with it is in many of the systems integration if you see Reliability often beats the performance. Often, I’m not saying always. Reliability often beats the performance.

So in most of these deployments, the idea is to use a system which is fairly accessible, which is fairly available, and which is fairly reliable. Most of these frontier models are great for advanced research. Most of these frontier models are fantastic for the future business possibilities, but for existing deployments, you do not necessarily go with a frontier model every day.

Pranav Manie: I think that’s a very helpful way to put it, that reliability is far more important than performance. I’m curious about one thing, though. Is it hard to like, because they’re Chinese, is it hard to sell this to clients that, “Oh, you know what? We’re using Chinese models to get your work done”?

Do they have any kind of perceptions around that?

Arpit Tandon: It depends very much on where your clients are from. So it is a very geopolitical, this thing. If your clients are based in Asia, if they are in West Asia and Southeast Asia or wherever, I think the discussion is very different from what if your clients are based in US, Canada, or Europe. So I think it depends completely on the client’s preference and obviously knowing the geopolitics, how things are, clients based out of Asia or West Asia and so on would be more inclined towards using open source system coming from Chinese ecosystem.

Pranav Manie: I’m assuming US, Europe in particular would not be... Maybe Europe more than US, because as the US is adapting these at a frighteningly fast speed than I thought. But moving just broadly away from Indian IT and just in general Indian tech innovation, right? Product innovation, like the kind of fintech product that we build or anything that we build, right?

Like for product-based companies, what do you think frontier access or the lack of it does? Like I’m sure you must have opinions on it. I’ve seen some of your writing on it, and obviously we’re trying to build our own LLM with Sarvam, right? How do you look at the future of Indian innovation with the possibility that we might not have access to the frontier?

Arpit Tandon: We cannot completely say that it doesn’t matter. It does affect the quality of research. It does affect the access to maybe talent, because this talent is also very niche, who wants to always leverage the most frontier of models if... And we see a lot of brain drain anyways happening in our country and so on.

Arpit Tandon: So the restriction of frontier models definitely has a negative impact on the research side of things, on the talent, and obviously the future possibilities. So, for example, if frontier models enables a certain kind of a business model that was not possible earlier, for example, in cybersecurity, that’s where a lot of the discussion is.

I don’t want to get into the specific, but if certain new business model is possible, maybe it would come up in countries where that frontier access is available Because if frontier access is not available, how would you even build up those kind of businesses? Similarly, it’s true for definitely the research, though India is still a tad behind in research behind many of the countries.

But definitely it does have some impact, but at the same time, I won’t say it’s the end of the world because the way I look at things is listening from what policymakers are saying or what the industry is also saying in India, the focus rather than having the most frontier model or the cutting edge, the focus has been more around deploying that AI, what is available in good shape, deploying in different critical areas and trying to get the benefit out of it.

So that’s been the focus rather than getting into a competition to have the latest and the greatest frontier available. Probably true for any other technology in history. I think in that sense it’s not very different, this idea of frontier versus deployment, right?

Pranav Manie: Just a couple of last questions. If I’m not wrong, you started your career in TCS.

Do you ever think back, oh, the times were simpler? How do you view the last two decades of your career and think about the moment that we are sitting in now?

Arpit Tandon: Yeah, having spent close to 15 years now in the industry, I’ve seen two or three critical shifts happening, Pranav, especially that have had big impacts on the services industry.

One was definitely cloud, and the other was SaaS, and now comes the AI. What every time it does is it changes not the pecking order or this thing, but the kind of work that folks are able to do. So for example, when SaaS came, people obviously say that despite SaaS tech services revenue grew at a very fast pace, which is true.

It grew. But the kind of work that they were doing earlier and the kind of work or the kind of talent they had now after SaaS gradually was very different.

Similarly, I see that shift happening for AI when people say AI would finish this industry or whatever. The way I see it typically is the kind of work that was happening earlier, the kind of work that will be happening later, that will be very different.

Now obviously every company’s up to them how to adapt and so on, but these are some of the pivot points, SaaS, maybe cloud, and then finally the AI that had really pivotal changes in the tech services industry.

Pranav Manie: So I think the comparison for Indian IT, often both it could be right or it could be wrong, but the comparison is often cloud, right?

And the wave that it heralded for Indian IT, right? AI is a different, no one denies that. But do you have any distilled first principles from what you experienced in the cloud and the SaaS waves that you use even while figuring out how to adapt to the AI age?

Arpit Tandon: One principle that always helps, if I’m solving a client’s problem, if I’m solving any kind of business problem, and that’s what services firms do, will having access to better technology help solve it better or will it impede it?

I think that’s the fundamental question to ask that we often do in our AI deployments. Okay, fine, you’re solving this problem today. You have access to maybe GPT 5.5. Tomorrow, what if GPT 6 is there? Will it hurt whatever you are building, or will it help it become better? If it helps it become better, then you are on the right track.

I think similar was true for whether SaaS or cloud. If you’re solving any kind of, if you are building a software for HR workflows, if SaaS helped it better, then SaaS is great. If it didn’t help it build it better or if there are further challenges, then you have to look what you have available on-premise.

So I think that’s the way to look at it, whether technology’s complementing the kind of problem that you’re solving or not.

Pranav Manie: And with this philosophy of making use of what you have, right? Which could be anything, like it could even be scrap, right? Like, what are some skills that you’ve figured out that, oh, these are things that’ll become important regardless of what LLM you use, that you can teach to, say, a junior who’s entering this industry.

And the future of juniors in this industry is obviously in deep question.

Arpit Tandon: Yeah. I would say the most important skill that I’ve mentioned many times in some of my posts and blogs as well is around systems thinking. So for a lot of the time tech services has been built on narrow skills.

Okay, fine, you know Java, you know in this industry, on this tech stack, and so on. While that is important, but with AI, unless and until you have an understanding of the full system, the full solution, the full application that you are working on, the impact it can have and so on, it’s very, very hard to deploy AI or use AI in a more efficient way.

So I would say the most important skill in my view that’s becoming very important and that we have had relatively less of is around systems thinking.

The second point that you mentioned, and I have a comment to make on the question around the future of junior talent in the tech industry.

I have a slightly optimistic view around that. So when you look at every technology shift typically, the junior talent comes into play for the new kind of new age roles or new age skills. Now, roles like somebody who’s managing the LLM, the different LLM models, who’s managing, who’s seeing the cost of different LLM models, somebody who’s evaluating the output of different LLM models and routing the models to something else and so on, those kind of roles have not become mainstream, but they will.

Somebody who’s orchestrating those models, who’s looking at day in, day out, watching at a dashboard and seeing which model performed better, which model is not performing well for this kind of data and so on, these roles are yet to evolve. Yes, there are a few, one or two roles here and there, but when these become mainstream, that is where I see the future junior talent coming into these roles, taking it up, learning, and growing into a very different industry.

Pranav Manie: That is an optimistic answer. One last question is something I’m going to end with which might sound pessimistic, right? I think in your previous blog post you had mentioned there was a consensus in the industry that the organisational structure of AI might move towards a diamond model, so to speak, away from the pyramid model, right?

But I think over the last few months, what’s also becoming clear is that the middle layer of Indian IT, if not in as much danger as the junior talent, it is still in quite considerable amounts of danger, right? How do you look at that conversation right now?

Arpit Tandon: Yeah. That shift towards talent was basically diamond was basically when your middle expert layer could expand, and they would be able to review the AI outputs and steer it and so on.

That still holds true. So those are not two contradictory situations. That still holds true that you need more experts, you need more domain expertise, you need more tech expertise at the middle layer to steer AI. However, what is disappearing is a lot of the roles which involve primarily coordination, administrative tasks, purely project management activities and so on, without really understanding the business implications.

I think some of those roles are definitely declining. So on the prima facie it looks like, “Hey, the middle layer is declining.” But no, the middle layer is still expanding, but it is expanding from less of coordination and administrative tasks towards more of domain-based, tech-based expertise, understanding of the business and so on.

Pranav Manie: Got it. Yeah. At least we are seeing the coordination roles definitely cut but yeah, I think we’re yet to see... We’re starting to see, but we’re yet to see it blow up where system architect, like the hiring of those people increases manifold. With that, thank you so much, Arpit, for doing this.

I hope you had a good time answering the somewhat stupid questions that I had around this industry. I think for us, we keep tracking this industry and trying to understand everything that happens. And we’re very glad that you were able to help us demystify some of it.

Arpit Tandon: Thank you, Pranav, and really good interacting with you and especially the work that you’re doing at Zerodha.

The benefit is you look at across industries, so you kind of bring in the similarities, the challenges from different industries and help us expand our knowledge as well. So really glad to be a part of this, and thank you, and wish you all the best.