The Founders Who Proved India Could Build
The story behind a $283 billion industry that started with borrowed money, floppy disks, and a bet nobody else was willing to make.
A Moment of Decision
In 1984, Azim Premji faced a problem. Wipro’s hardware division was losing money. The company had built minicomputers and systems through the late 1970s and early 1980s under India’s protectionist trade policies. Then the government changed course. They liberalized computer imports. Foreign machines from IBM, HP, and Sun flooded the market at prices Wipro couldn’t match.
The hardware business was dead. Premji had 200 engineers on staff with no clear work ahead. They knew embedded systems, chip design, and UNIX internals. Skills that were valuable somewhere, but not in India anymore.
He had two options. Shut down the R&D division entirely or find something else for those engineers to do. Premji chose the second path. “We were left with two options,” he said later. “Either completely close the R&D, or provide competencies in the form of R&D services to the international market. We chose the latter.”
Nobody had proven this could work. American companies didn’t give product development work to Indian firms. Code traveled on floppy disks via courier with turnaround times measured in weeks. Real-time collaboration across twelve time zones was impossible. The infrastructure didn’t exist. The trust didn’t exist.
Premji’s decision was a bet without data. He believed Western companies needed the skills his engineers had. He believed they would pay for remote work if the quality was high enough. He believed India could do more than low-cost back office processing.
Other Indian companies faced the same crisis. HCL had built India’s first indigenous minicomputer in 1978. Their hardware division was dying too. Smaller companies that had thrived under protectionist policies suddenly had no path forward. The question every founder in this moment faced was the same: what do you do with a workforce trained to build things for a market that no longer wants what they know how to build?
Scarcity as Forge
To understand why the founders made these bets, you have to understand what India looked like in 1984.
The country had been independent for less than four decades. The economy was tightly controlled. Import licenses, foreign exchange restrictions, and public sector dominance shaped every industry. Starting a business meant navigating a bureaucracy that could take years to grant a phone connection. Foreign companies that wanted to operate in India had to hand over majority equity to Indian partners. IBM, rather than comply with the 1973 equity restriction, chose to exit the country entirely in 1977.
The result was a domestic technology industry that built in isolation. Companies like HCL, Wipro, and DCM Data Products made computers from locally sourced components under trade protection. The machines were expensive and often obsolete by global standards, but they existed. India had engineers who could design hardware, write operating system code, and build systems from scratch.
That isolation turned out to matter.
Because imports were expensive and restricted, Indian companies couldn’t afford new systems. Universities ran on old machines. Engineers learned on hardware that American companies had moved on from. They became experts in COBOL, FORTRAN, and assembly languages because those were the languages running on the equipment they had access to. They wrote device drivers, built compilers, and worked close to the hardware in ways that engineers with newer, more abstracted tools didn’t need to.
This was not a planned advantage. It was a byproduct of scarcity. The same protectionism that killed the hardware industry when it ended also produced a generation of engineers with exactly the skills that would prove valuable when the Y2K crisis emerged a decade later.
The pattern of proving capability through constraint rather than abundance had precedent in India. In 1962, the country started its space program with a handful of scientists and no domestic infrastructure. Early rockets were transported on bicycles and bullock carts. Assembly happened in a church repurposed as a laboratory in Thumba, Kerala. The scientists working there were trained, many of them abroad, and had returned to India to build something from nothing.
ISRO’s early years were defined by the gap between ambition and resources. Vikram Sarabhai, who founded the program, wanted India to apply space technology to the country’s real problems: communications, weather forecasting, remote sensing for agriculture. The goal was never to compete with NASA on prestige. It was to build capability that served a practical purpose. They worked with what they had, sourced what they couldn’t make domestically, and built expertise by doing the work rather than waiting for conditions to improve.
By the 1980s, ISRO had launched India’s first satellite, Aryabhata, developed indigenous launch vehicles, and established a reputation for doing complex work at a fraction of what Western space agencies spent. The organization didn’t have more resources than its counterparts. It had a specific kind of focus that came from having fewer options.
The IT founders were operating in that same tradition. The question was not whether constraints existed, and they did, at every step. The question was whether those constraints would define what was possible or just slow down what was inevitable.
The Founders and Their Theses
The companies that built India’s product engineering industry were not started by people with resources. They were started by people with a specific conviction: that India had engineering talent the world needed, and that building an organization to deliver it was worth the difficulty of building in India at that time.
That conviction took different forms across different founders. Each brought a different background, a different set of constraints, and a different thesis about how to make it work.
F.C. Kohli and TCS
Faqir Chand Kohli studied electrical engineering at Queen’s University in Canada and the Massachusetts Institute of Technology before returning to India to join the Tata Electric Companies in the 1950s. He worked on power systems and eventually moved to Tata Consultancy Services, becoming its first general manager when it was formally established in 1968.
TCS began not as a software company but as a services arm that happened to work on computers. Early work was operational: payroll processing, inventory management, data processing for clients. The margins were thin and the work was not glamorous. What Kohli understood was that the work was foundational. Companies needed people who could work with computers. India had those people. The question was how to organize them into something systematic.
His approach was methodical. He invested in training, in process, in the mechanics of how software projects should run. TCS developed structured methodologies for software delivery long before that was standard practice. Kohli was not a salesman. He was an engineer who believed that if you built the capability, the work would follow.
The Tata name mattered more than most founders acknowledged publicly. In India in the 1960s and 1970s, the Tata Group carried institutional credibility that no startup could claim. Clients who might have hesitated to trust a new software company from India would give TCS a chance because the Tata name was attached to it. That credibility gave TCS time to build, to fail at some things quietly, and to develop the processes Kohli knew were necessary.
TCS went public in 2004 at a valuation that made it India’s largest company by market capitalization at the time. By then Kohli had already retired, but the organization he shaped, its training culture, its process discipline, and its insistence on delivery quality, remained the operating model.
Shiv Nadar and HCL
Shiv Nadar founded HCL in 1976 with colleagues who had worked together at DCM Data Products. They had a specific goal: build India’s first indigenous microcomputer. In 1978, they did it, beating IBM’s PC to market in India by three years.
That achievement was real but its commercial value was constrained by the same protectionist policies that enabled it. HCL could build computers but couldn’t easily export them, couldn’t easily import components, and competed in a market where every large customer was a government institution with its own procurement processes.
When import liberalization came in 1984 and foreign hardware became cheap, the advantage disappeared. Nadar’s response was different from Premji’s in execution but identical in logic. He looked at what HCL actually had: engineers who understood systems at a deep level, who had built computers from components, who knew how to make hardware and software work together.
Nadar pursued partnerships with foreign companies. HCL and Hewlett-Packard formed a joint venture. The partnership gave HCL access to HP’s technology and HP access to HCL’s engineering capacity. But Nadar was clear about what the long-term goal was. The joint venture was a means to build capability and relationships, not the end state. The end state was an Indian company competing globally on its own terms.
He thought about scale earlier than most of his contemporaries. Where others were solving the immediate problem of finding work for their current engineers, Nadar was thinking about what HCL could become if the model worked. He invested in international offices early, opened operations in the United States in the 1980s, and built client relationships that weren’t dependent on a single project or a single contact.
Azim Premji and Wipro
Premji did not plan to be a technology entrepreneur. He was studying electrical engineering at Stanford when his father died in 1966. He was 21. He returned to India to take over the family business, which manufactured cooking oil and soap under the Wipro brand. Technology came later, in the late 1970s, as Premji diversified the company into calculators and then computers.
His 1984 decision was more consequential than it might have appeared at the time. He didn’t just pivot to software services. He made a specific bet on R&D services, specifically on providing engineering capability to companies building products. His first clients were the technology partners Wipro already had relationships with from the hardware days: Intel, Tandem, Sun, Novell. These were product companies that needed engineering work done. Wipro’s engineers could do it.
The infrastructure investments that followed required capital commitment without revenue guarantee. Installing a satellite earth station at Wipro’s offices cost millions. The equipment required structural changes to the building. The link, once established, would only generate returns if clients trusted Wipro enough to give it product work. That trust had to be built project by project.
What distinguished Premji as an operator was his attention to the mechanics of delivery. Wipro invested in quality certifications, in process documentation, in training programs. Not because clients demanded it initially, but because Premji understood that the only way to change the perception of what Indian companies could deliver was to consistently deliver more than expected.
By FY2001, Wipro’s R&D services division represented 50 percent of the company’s global IT services revenue, reaching $382 million.¹ That number was built over seventeen years of project delivery, client relationship management, and infrastructure investment that preceded the revenue it generated.
Narayana Murthy and the Infosys Founders
The founding of Infosys in 1981 was an act of collective conviction. Narayana Murthy and six colleagues, all of whom had been working at Patni Computer Systems, decided to build something of their own. Murthy’s wife, Sudha, lent them ten thousand rupees, roughly two hundred and fifty dollars, as seed capital. That was how the company started.
The early years were operationally difficult in ways that are hard to convey now. The founders worked out of Murthy’s apartment in Pune. Getting an import license for a computer took three years. Getting a phone line required bureaucratic effort that consumed time the company couldn’t spare. They had to convince the government to allow dollar-denominated contracts before they could get paid in foreign currency for their work.
What the founders chose to emphasize, given that they couldn’t compete on infrastructure or capital, was something else: values, transparency, and the way the company treated its people. Murthy was specific about this from the beginning. Infosys would be a company where merit determined advancement, where equity was shared with employees rather than concentrated at the top, where the relationship between the company and the people who built it was explicit and fair.
This was not common in Indian business in 1981. Family-owned conglomerates dominated Indian industry. Professional management on transparent, meritocratic principles was not the model. Murthy and his co-founders built a company structured more like they imagined a global technology firm should be than like the Indian business context around them suggested it should be.
When Infosys competed for international clients, that governance structure was legible to those clients. American companies doing business in India in the 1980s and 1990s had legitimate concerns about transparency and accountability. Infosys’s willingness to operate openly, to publish accounts clearly, to maintain governance standards that Western clients recognized, was a competitive differentiator.
Infosys went public in 1993 as the first Indian software company to list on a US exchange through an American Depositary Receipt, raising $36 million.² Less notable for the amount than for what it represented: this company operates to international standards, invites international scrutiny, and is willing to be judged by those standards. Murthy was building the argument in public.
The Infrastructure Bet
The founders had the engineers. They had the thesis. What they didn’t have was the infrastructure to connect Indian engineering capacity to clients twelve time zones away.
In the mid-1980s, the communication problem was not a minor inconvenience. It was a fundamental constraint on what work could be done remotely. Code traveled on floppy disks via international courier. A client in the United States who found a bug in code written in Bangalore would wait three weeks for a fix. The work Indian companies could win was structurally limited by how long it took information to travel.
Texas Instruments Sets the Model
In 1985, Texas Instruments ran a twelve-month selection process across multiple countries in Asia, evaluating each against criteria that included engineering talent quality, proximity to research institutions, and the ability to establish reliable communication infrastructure. They chose Bangalore. The city had the Indian Institute of Science, a government-funded research ecosystem, and a concentration of engineering graduates that other candidate cities couldn’t match.
The work TI planned to do in Bangalore was not peripheral. It was VLSI chip design, among the most technically demanding work in the semiconductor industry. Srini Rajam, who led TI’s India operations in the early years, was clear about the standard he was trying to meet: “The R&D centre in India had to be equal to any R&D centre around the world in terms of infrastructure, capabilities. The only way was a dedicated communication system providing the same bandwidth.”³
TI installed a dedicated satellite earth station at their offices on Millers Road. The equipment weighed several tons and required structural work to the building. The Indian government stationed a Department of Telecom officer at the facility full-time to monitor what was transmitted over the link. The satellite dish made Newsweek. For the founders of Indian IT companies watching this, it was evidence that the infrastructure problem was solvable and that international clients would invest in solving it if the capability was there.
TI’s response to other multinationals asking about their India experience was equally significant. Rather than treating the model as proprietary, TI shared what they had learned. “TI thought this was something you did to build a multinational R&D community in India, which would help everybody,” Rajam said.³ HP, Motorola, and others followed, using TI’s experience as a reference.
Indian Companies Build Their Own
By 1989, VSNL had established commercial satellite links that Indian companies could access. Wipro, TCS, and Infosys installed their own earth stations, committing capital before the revenue flow could justify it.
Sridhar Mitta, who ran the engineering division at Wipro and managed an Offshore Development Center for Tandem Computers, described what setting up one of these facilities actually involved. The equipment was American-manufactured and heavy. “Machines so heavy no crane in Bangalore could lift them. Had to break walls,” he said. The generator required to run the facility produced enough noise that neighbors complained. Mitta’s team built an acoustic enclosure to contain the sound. “Everything was a problem,” he said. “Lot of fun.”³
The VSNL link, once available, transformed what was possible. Engineers described it as “a completely new way of functioning.”³ Code that previously traveled by courier could move in hours. Problems that required weeks of back-and-forth could be resolved in a day. The physical distance between Bangalore and Boston stopped being a barrier to real-time work.
Nortel and the ODC Model
While Indian companies were building communication infrastructure, Nortel Networks was working on the organizational model that would define how offshore product development operated for the next two decades.
Nortel had a problem common to technology companies in the late 1980s: more engineering work than they could staff with engineers available in North America. Diju Raha, a senior Nortel executive, came across a television program called Computer Chronicle featuring a segment on Indian software capabilities. He tracked down the producer, Stewart Cheifet, and bought thirty hours of raw footage. “Went through the material,” Raha said, “and became an instant expert on the possibilities in India.”³
What Raha designed was the Offshore Development Center model. It was different from contracting arrangements that had existed before in one specific way: the ODC was designed to function as an internal Nortel team rather than as an outside vendor.
The details mattered. Indian engineers in the centers received Nortel ID badges identical to the ones Nortel employees in Canada carried, granting access to any Nortel facility worldwide. The centers were physically designed to match Nortel’s own lab environments. Nortel conducted employee satisfaction surveys in the ODCs, the same surveys it ran internally. The company called its Indian partners partners, not vendors. It worked with both governments to manage visa and travel processes for engineers moving between locations.
Nortel set up ODCs with three Indian companies: TCS, Wipro, and Infosys. The choice was deliberate. These were the companies with the process discipline and engineering depth to operate at the standard Nortel required.
The ODC model addressed the trust deficit that was the real barrier to serious offshore work. The risk clients faced was not only about quality. It was about alignment. Would an offshore team understand the product deeply enough to make good decisions? Would they flag problems early or wait to be asked? Nortel’s answer was to make the Indian team structurally identical to an internal team. If the team was treated like insiders, they would operate like insiders.
Other clients followed variations of this approach. The ODC became the standard form for serious offshore product work through the 1990s. Indian companies that could demonstrate the process maturity to operate a client’s ODC at the required standard won long-term relationships. Indian companies that couldn’t lost the work.
Building Teams That Deliver
Winning the first contract was one problem. Delivering on it was another. And delivering consistently, across dozens of clients and hundreds of projects simultaneously, at a quality standard that would convince skeptical Western companies to give Indian firms more work, was a different problem entirely.
The founders understood that the business model required something that didn’t yet exist in India at scale: an organization that could absorb large numbers of engineers and turn them into consistent performers on complex technical work.
The Training Machine
Infosys built its training center at Mysore into what became the largest corporate training facility in the world. The campus could accommodate fourteen thousand people simultaneously. Newly hired engineers spent between three and six months there before being assigned to any client work.
The logic was specific. Infosys hired from a wide range of engineering colleges across India, not just the IITs and NITs. Graduates arrived with strong theoretical foundations but varying levels of exposure to professional software development practices. The Mysore program standardized what they knew before they touched client work: programming practices, communication standards, project management fundamentals, how code gets reviewed and documented in a professional setting. Engineers who went through the program came out with a common baseline that Infosys could rely on when staffing projects.
This was expensive. Months of training before a single billable hour represented significant investment per engineer, and the training campus itself required continuous capital investment to maintain. Murthy and his co-founders made those investments on the belief that consistent delivery quality would compound over time.
TCS built similar infrastructure, investing in knowledge management systems that preserved what was learned on one project and made it available to teams on subsequent ones. The intellectual property of delivery, the processes and practices that made teams effective, was treated as an asset worth maintaining.
Wipro’s approach reflected its hardware engineering roots. The company invested heavily in process documentation and methodology: how projects were scoped, how teams were structured, how progress was measured, how problems were escalated. This was more procedural than the culture-first approach at Infosys, but it produced the same outcome: a delivery system that could be replicated across clients and geographies.
The Quality Certification Race
In the early 1990s, TCS became the first Indian software company to achieve SEI CMM Level 5 certification. CMM, the Capability Maturity Model developed by Carnegie Mellon’s Software Engineering Institute, rated software development organizations on a five-level scale based on the sophistication of their processes. Level 5 represented optimized processes, meaning the organization not only had rigorous processes but systematically improved them based on data.
The founders pursued these certifications for a reason that was as much commercial as operational. Western clients evaluating Indian vendors in the 1990s had a legitimate concern: how do we know the delivery will be consistent? A company might deliver well on the first project because it sent its best team. The second project might get different results. CMM certification was a credible answer to that concern. It meant the delivery process was documented and measurable, not dependent on which engineers happened to be assigned.
Wipro and Infosys followed TCS in pursuing CMM and ISO certifications. By the late 1990s, India had more CMM Level 5 certified software organizations than any other country.⁴ The certification effort was not coordinated across companies. Each one independently reached the same conclusion: that demonstrating process maturity to Western clients was worth the investment required to achieve and maintain it.
The certifications changed the conversation. Instead of Indian companies having to argue that they could deliver at the required standard, they could point to independent verification that their processes met an international benchmark. It shifted the discussion from trust based on reputation to trust based on evidence.
The Employment Compact
In the scarcity economy of 1980s and 1990s India, a job at TCS, Wipro, or Infosys meant stable income, professional development, and work on problems that were technically interesting. It meant brand association that carried weight, and for engineers on international projects, exposure to global clients and practices.
Each company had a different draw. The Tata name behind TCS carried institutional credibility that newer companies couldn’t match. Engineers joining TCS were joining an organization with over a hundred years of history in Indian industry, which was not trivial in an economy where most employment was insecure and the private sector was thin.
Infosys offered something different: the prospect of genuine wealth creation through employee stock ownership. Murthy’s conviction that equity should be shared broadly with the people who built the company was unusual in Indian business. The 1993 IPO and subsequent stock appreciation made Infosys employees wealthy in a way that had no precedent in Indian corporate history. That outcome attracted engineers willing to bet on the company’s growth in exchange for equity participation.
Wipro’s draw was the nature of the work itself. The R&D services model meant engineers were working on product problems, embedded systems and chip design for Intel and Tandem, not maintenance or data processing. The quality of the problems mattered to the quality of the people the company could attract.
The result was retention. Engineers stayed at Indian services companies in significant numbers even as MNCs began establishing a presence and could theoretically offer higher salaries. The retention gave the founders something to deliver on: a stable engineering workforce that could develop deep client relationships over time rather than cycling through new teams on every project. Clients who worked with the same team over multiple years got better outcomes. The team knew the client’s systems, the history of decisions made on previous projects. That continuity was a form of quality that didn’t appear on any certification scorecard but was visible in the delivery.
The Validation
The Y2K problem was, at its core, a staffing problem.
When companies began seriously assessing their exposure in the mid-1990s, the scale of what needed to be done became clear. Millions of lines of code, written over decades, contained date calculations that assumed years would always begin with 19. When the calendar turned to 2000, systems handling banking transactions, insurance claims, power grid management, airline reservations, and government records would either fail or produce garbage data unless every affected line of code was found, fixed, and tested.
An insurance company with twenty to thirty million lines of code might have a hundred thousand individual date calculations requiring correction. Each fix had to be verified, and each verification tested against related systems to confirm nothing else broke in the process. A hundred thousand changes at one working day each required five hundred programmers for a year, and that was for one company’s systems. Large organizations had multiple systems. Financial institutions had dozens.
The American technology industry did not have five hundred spare programmers per large company. The dot-com boom was absorbing every engineer who graduated from a US university. The Y2K remediation work required COBOL and FORTRAN expertise, skills that the American engineering workforce had largely moved past. The languages still ran critical systems, but the people who knew them well were retiring, not entering the workforce.
India had both the engineers and the skills.
The Accidental Expertise
The connection between India’s import barriers and its Y2K advantage was not planned. Because computers had been expensive and imports restricted through the 1970s and 1980s, Indian universities and companies ran on older hardware far longer than their counterparts in the United States. Engineers trained on systems that American institutions had replaced years earlier. They became fluent in technologies that the global market had largely treated as legacy precisely because those were the technologies available to them.
When Y2K arrived and the global market needed exactly those skills at scale, the engineers most capable of providing them were disproportionately in India. The economic handicap of the 1980s had become a technical advantage in the late 1990s.
The founders recognized the opportunity early. TCS, Wipro, and Infosys built dedicated Y2K practices, trained engineers on the specific requirements of date field remediation, and pursued contracts systematically. The cost argument was straightforward: a US programmer in 1997 cost between $60,000 and $95,000 annually. An Indian engineer working onsite in the US cost between $32,000 and $42,000. An Indian engineer working offshore cost between $16,000 and $24,000.⁵ The savings were sixty to seventy percent.
But the argument required proof as much as arithmetic. Clients trusting Indian companies with systems that processed payroll for hundreds of thousands of employees, or managed loan portfolios worth billions, needed confidence that the work would be done correctly. The certifications, the training programs, and the ODC models that the founders had built through the previous decade were the answer to that question. They were not built for Y2K. But they made Y2K possible.
The Scale of Delivery
India processed over 700 million lines of code as part of the global Y2K remediation effort, approximately thirty percent of all Y2K work done worldwide.⁵ TCS alone generated over a billion dollars in Y2K revenue. Infosys grew from $121 million in revenue in 1998 to $203 million in 2000.⁶ Wipro’s technology services revenue doubled over the same period.
The delivery required coordination across time zones, clients, and systems that had not been designed to work together. Indian companies set up command centers, built testing environments that replicated client systems, and managed multiple simultaneous engagements each with its own timeline and requirements. The founders’ investment in process frameworks was the only reason the operational complexity was manageable.
The engineers who did the work were methodical. The tasks were not technically sophisticated in the way that designing a new system is sophisticated. They were exhausting in a different way: searching through millions of lines of code for specific patterns, verifying each fix, documenting each change, maintaining the chain of evidence that clients would need to audit what had been done. The delivery culture that Indian companies had spent a decade building was precisely suited to what Y2K required.
What the Proof Cost
The Y2K opportunity came with a risk that was rarely discussed publicly. Indian companies were working on systems where failure would be catastrophic and attributable. If those systems had failed, the work Indian companies had done would have been scrutinized. The credibility the founders had built over fifteen years would have been evaluated under the worst possible conditions.
The founders accepted that risk. They could have limited their exposure by taking smaller or less critical projects. They didn’t. They took the work that was available, at the scale it was available, and delivered.
That willingness to take on consequential work and be accountable for the outcome was itself a statement. It was the argument the founders had been making since 1984, expressed not in words but in the decision to accept responsibility for systems the world depended on.
The systems held. That fact settled the argument.
The Evolution
After Y2K, the work changed.
The clients who stayed in relationships with Indian companies after the remediation work was done began offering different kinds of engagement. Instead of a defined project with a specific deliverable, they offered ongoing access. Engineers who had spent eighteen months inside a client’s systems, learning how they were structured and why decisions had been made the way they had, became valuable in ways that were hard to replace quickly.
Moving Up the Work
The shift from project delivery to ongoing partnership changed what Indian engineers were doing. Maintenance and testing remained part of the work, but a growing share involved earlier stages of the product development cycle: architecture decisions, feature scoping, technical design. Work that had previously happened entirely within the client’s engineering teams began to involve Indian counterparts.
This happened incrementally. A client would give a well-performing offshore team a slightly more complex problem. The team would deliver. The client would give them something more complex again. Over several years, the nature of the engagement transformed from executing plans to contributing to them.
The revenue mix reflected this. In the mid-1990s, roughly seventy-five percent of Indian IT services revenue came from onsite work, engineers embedded at client locations in the United States and Europe.⁷ By 2005, that had shifted to closer to fifty-fifty. By 2010, offshore represented the majority of most engagements. Each percentage point moving offshore represented a corresponding increase in how much the client trusted the Indian team to work without direct supervision. Billing rates increased with the trust. Maintenance work billed at a lower rate than development, development at a lower rate than architecture. As the work moved up the value chain, revenue per engineer increased.
Building the Delivery Machine at Scale
The decade between 2000 and 2010 produced employee growth at Indian IT companies that had no parallel in the history of Indian industry.
TCS went from ten thousand employees in 1999 to a hundred and ninety-eight thousand in 2010. Infosys went from five thousand four hundred to a hundred and thirteen thousand. Wipro’s technology division went from eight thousand five hundred to over a hundred thousand.⁸ These were not incremental expansions. They were the construction of large organizations within a single decade, absorbing engineering graduates at the pace the Indian university system was producing them.
The absorption required the systems the founders had built. The Infosys training campus at Mysore processed thousands of engineers annually. TCS ran its own training infrastructure across multiple facilities. Wipro invested in onboarding programs that turned freshers into billable resources within months. The process worked because it had been built over years before the scale required it.
Hiring at this scale also required expanding the hiring pool beyond the IITs and NITs. The companies went to regional engineering colleges, state universities, and smaller institutions across India. The training programs existed precisely to bridge the gap between what those institutions produced and what client work required.
The International Presence
Delivery happened in India but sales and client management happened where clients were. Through the 2000s, TCS, Infosys, and Wipro built substantial international operations. These were not engineering centers but client-facing operations: account managers, delivery coordinators, sales teams, and leadership who could sit in rooms with client executives and have conversations about strategy.
The companies learned that offshore delivery worked best when there was a strong onshore presence managing the relationship. They also learned that serving clients in Germany required German business context, and serving clients in Japan required Japanese language and cultural fluency. Companies that had been built by and for Indian engineers had to become multinational employers in a practical sense, not just in name. That transition took years and required building local leadership in international markets while maintaining the delivery model centered in India.
The Present
Companies do not debate whether to put serious engineering work in India. They debate how to structure it.
What followed is, by any measure, large.
India’s technology industry generated $283 billion in revenue in FY2025, with exports accounting for $224 billion of that.⁹ The industry employs 5.4 million people directly.⁹ The services companies the founders built are a significant part of that, but they are no longer the only part, and they are no longer the dominant story.
India now has over 1,750 Global Capability Centers, captive operations owned and managed directly by the companies they serve, with no intermediary, no vendor margin, and intellectual property that belongs entirely to the company funding the work.¹⁰ GCCs employ 1.9 million people in India and generate $64.6 billion in annual revenue. They are projected to employ 3.46 million people by 2030.¹¹ JP Morgan employs 55,000 people in India. Microsoft has 18,000 in Hyderabad alone.¹²
The services companies, TCS, Infosys, Wipro, HCL, Tech Mahindra, LTIMindtree, Mphasis, Persistent, Coforge, and several hundred others listed and unlisted across BSE and NSE, compete for engineering talent alongside those GCCs. So do the staffing companies. India’s IT staffing market is itself a substantial industry: the top 30 staffing firms generated $5 billion in revenue in 2024, accounting for 37 percent of the total staffing market.¹³ Quess Corp, the largest, has over 450,000 employees on its rolls. TeamLease has placed over 3 million individuals across its history. Randstad, Adecco, ManpowerGroup, Collabera, Allegis, Kelly Services, and dozens of smaller firms compete in the same market.
Services companies, GCCs, and staffing firms are all drawing from the same pool. India produces 2.5 million science and engineering graduates annually.¹⁴ The United States produces 900,000. That ratio has not changed and is not projected to change.
Sources
Gopalakrishnan, S., Dayasindhu, N., Narayanan, K. Against All Odds: The IT Story of India. Penguin, 2022.
Infosys Limited. Annual Report 1993–94. Bangalore: Infosys, 1994.
Gopalakrishnan et al., Against All Odds, 2022. (Quotes from Srini Rajam, Sridhar Mitta, Diju Raha.)
Sharma, Dinesh C. The Outsourcer: The Story of India’s IT Revolution. MIT Press, 2015.
Sharma, The Outsourcer, 2015. (Y2K remediation volume and salary comparisons.)
Infosys Limited. Annual Reports, 1998 and 2000.
NASSCOM. Strategic Review 2001. New Delhi: NASSCOM, 2001.
TCS, Infosys, and Wipro Annual Reports, 1999 and 2010.
NASSCOM. Technology Sector in India: Strategic Review 2025. New Delhi: NASSCOM, 2025.
NASSCOM. GCC Landscape Report 2024. New Delhi: NASSCOM, 2024.
India Brand Equity Foundation. IT & ITeS Industry Report. IBEF, 2024. (GCC workforce projection of 3.46 million by 2030.)
Company disclosures and press statements, 2023–2024. (JP Morgan and Microsoft India headcount figures.)
Staffing Industry Analysts. Largest Staffing Firms in India 2025. SIA, 2025.
National Science Foundation. Science and Engineering Indicators 2024. Washington, DC: NSF, 2024.