Hi there. My name is Ali. On Craft Theorys I write about being ambitiously slow: building boring, profitable businesses with big goals, at a pace that leaves room for the rest of your life. Subscribe if that sounds like you. And if you’re in a B2B business, apply to The Boring Business Club, my private WhatsApp group.

This is the third piece in a series on reinventing IT services firms, about as boring and profitable as businesses get. The first explains why the growth ceiling is gone. The second argues that reinvention starts with learning to sell. This one is about what to sell.

If you run an IT services firm in India and you’ve followed this series, you’ve reached a harder question: what do you actually sell?

Most Indian services founders I know try to answer it the same way. They open the portfolio.

It’s a reasonable instinct. A firm that has spent years on custom work has done a bit of everything: mobile apps, web platforms, ERP integrations, a data migration, a few engineers placed with a client who needed them in a hurry. The answer must be somewhere in that pile.

So the client work goes into a spreadsheet. Which clients paid the most. Which industry shows up most often. Which tech stack the firm keeps getting hired for. Out comes a pie chart, and then a decision. “We’re strongest in BFSI, let’s focus there.” “Most of our revenue is React, let’s be the React shop.”

Spreadsheets, however, do not tell you why someone bought your services. Without that, you don’t know what to sell, and you’ll keep guessing and keep investing in “supply” (if you don’t know what supply means, read the first piece).

Product companies have a name for the state where buyers come looking for you. They call it product-market fit. A services firm needs its own version. Call it service-market fit.

What is service-market fit?

Start with how a product differs from a service. When someone buys a product, they take it and work out how to use it themselves. They might need help now and then, but getting value out of it is their job. A service is delivered. The output comes from people and a process working together on the client’s problem.

So here’s the definition.

Service-market fit is when buyers who don’t know you keep coming to you with the same to-do, and you get it done for each of them the same way, with people plus a process. You’ll know you have it when your case studies start to look alike.

Demand comes first. The process gets built behind it, and the case studies come out of the process. Ten case studies about ten different projects show you can do a bit of everything. Ten that tell the same story show you’ve found something.

A firm with service-market fit can answer three questions:

1. What do buyers come to you for?

2. Who needs it urgently, with budget?

3. When do they come looking for you?

Once you can answer all three, every channel starts working. Ads, webinars, LinkedIn, newsletters, a WhatsApp group, for all I care. You know who you’re talking to and what to say to them.

Most IT services firms in India can’t answer any of the three with confidence. They have a long list of work they’ve done and no idea when a buyer would go looking for them. Work arrives through referrals, which means someone else decided who the firm is for.

Fit comes in degrees. You might find it first with a small group: twenty manufacturers who all need the same integration built on the same ERP. Then you widen the group. The firm gets bigger, the problem doesn’t change.

Why your portfolio won’t find it

Go back to that pie chart. Each slice is a client, and behind each client is a reason they picked up the phone. Ask yourself whether you know what that reason was.

For most firms I’ve seen, the honest answer is no. The client came through a referral, or through a salesperson who has since left, or through someone the founder knew years ago. The reason they bought was never written down. So the gap gets filled with a story, and the stories usually come in two shapes.

The first is about technology. “We’ve done a lot of React, so we’re a React shop.” A buyer hires you to get something done by a date. React happened to be how it got done. They’d have taken Fortran if it shipped on time. Specialising in a stack also puts you in the most crowded part of Indian IT services, next to the thousands of firms that already say the same thing.

The second is about industry. “Most of our revenue is BFSI, so we’re a BFSI firm.” Look closer and those BFSI clients often came for different reasons. One needed ten engineers in a hurry. One had a vendor who stopped picking up the phone. Same industry, two different needs, two different processes. Their case studies won’t look alike, so by the definition above, there’s no fit there yet.

So where do you look instead?

Two places to start

Where you start depends on one thing: whether buyers who don’t know you are booking calls with you.

The first state is zero. Every client is custom work, almost all of it came through referrals, and in a typical week no stranger books a call. There’s nothing to go back and study, because there was never a call to study.

The second state is some. A handful of people find you on their own, through your website, a post, an ad, a directory listing, and book time with you. Some of those calls were recorded, or someone took notes. That’s raw material.

Be honest about which one you’re in. Calls with existing clients don’t count. Referral calls can still help, as long as you can work out why the person agreed to talk. Most founders I’ve met sit in the first state and believe they’re in the second.

The two states start differently and end in the same place. In the first, you guess what buyers need and go sell it. In the second, you dig it out of the calls you already have. Either way, you end up selling and listening.

When nobody is calling

The hardest part of the first state is your ego. You have a team, clients and revenue, so acting like it’s day zero feels absurd. Do it anyway. Your clients don’t need to know you’re starting over. They’ll assume you’re busy. The firm you’ve built can’t find this for you.

Start from a clean slate. A first to-do usually comes from one of three places:

1. Pain on the job: what went wrong while you delivered. Mine was not knowing how every project was doing without being in every room.

2. Pain from your own life: something outside work you’d have paid to fix. Say, getting your family’s clinic to take bookings online.

3. Prospecting: no pain of your own, so you guess one. Say, manufacturers whose ERP doesn’t talk to their warehouse system.

Write your guess down in the shape from the first piece:

We need to ______
by ______.
We’ve already tried ______,
and it didn’t work because ______.
We can’t do it ourselves because ______.

Then sell it, one-on-one, with you on the call. Pick twenty people who should have that problem. If the guess is right, they move towards a start date without you pushing. If you’re explaining what you do more than once, it’s wrong. Rewrite it and go again.

If you think outbound is dead, that’s bullshit. You just haven’t found the right to-do: one people need help with and have no other option for.

Once a guess pulls, people start booking calls with you. You’re in the second state.

When people are calling

If buyers already book time with you, the answer is sitting in those calls. Go back through the recordings and transcripts with one question: why did this person take time out of their day to talk to us?

Nobody wakes up wanting to buy services from an IT firm in India. They’re busy. If they booked a call, something on their list made them do it, and these days most people will tell you what it is. It sounds like this:

• “We bought an ERP and need custom integrations on top. Finance is waiting.”

• “Our website needs an update. Our engineers are busy and marketing’s backlog keeps growing.”

• “Demand is outpacing what we can hire for. We need offshore engineers within budget.”

If you’re on the calls yourself, talk less and ask more. Here are five questions that do all the work:

1. Why did you take time out to talk to us?

2. When does this need to be done?

3. Who else are you talking to?

4. If you’re still talking to us, what’s missing from those options?

5. What does success look like for you?

If there’s no project or no date, they aren’t buying yet. Move on.

Watch for tourists. “We’re talking to multiple vendors” usually means they’re talking to nobody. “We have a few quotes in” means they’re serious. That’s when you ask: “We usually charge $X. Is that in the ballpark of what you’re seeing?” Watch their face as much as their answer.

Let AI read the calls

You don’t need to fill in a spreadsheet, and you don’t need to have been on every call. Most call recorders give you a transcript now. Put every transcript from buyers who found you on their own in one place, and ask an AI to read them. Something like:

For each call, tell me why the buyer booked it, what they need done, by when, what they’ve already tried, and why it didn’t work. Then group the calls by what they need and tell me which ones come up most.

You’re looking for the same to-do from people who don’t know each other, with a similar deadline and a similar failed option behind it. When several calls say roughly the same thing, you have a guess worth selling to more people.

AI is good, but it can’t summarise a question you never asked.

If every call says something different, either you haven’t had enough calls yet, or the people calling don’t share a problem. Go back to guessing one and selling it.

Sell it to more people

One buyer with a pressing need and no good options is a start. It might also be just that buyer. Their situation might be unusual, or the options they turned down might suit someone else fine. The only way to find out is to sell the same thing to more people who should need it.

Go where those people already are:

• Outbound: short, plain messages that name the problem. “Is finance still waiting on those ERP integrations? We build them in 2 weeks.”

• Ads aimed at people who look like the buyers who called you.

• Reddit and the other communities where they ask for help.

• Content about the problem: posts, a newsletter, a webinar. The call to action does the qualifying.

Use the words your callers used. The transcripts already tell you how buyers describe the problem, so you don’t have to invent a pitch.

What you want is buyers pulling this out of your hands.

How you know it’s working

Count one number: calls booked each week by buyers who don’t know you, about this one problem. Calls from existing clients don’t count, and neither do calls about something else.

Then watch how fast it grows. Starting from zero, 10% compounded monthly is a strong rate. That roughly triples your calls in a year. Further along, the bar moves, but the line should keep going up.

If the number flattens, either the guess is wrong or the people you’re reaching are. Change one and go again.

Then cut everything else

Once one to-do pulls, do just that. Everything else gets a no: the custom project from an old client, the referral for something you used to do, the new service line a competitor just launched.

This is the hard part, especially for firms doing fine. Every custom project pulls people off the process you’re building. Your case studies stop looking alike. Delivery stops being repeatable, and the demand you found starts to slip.

So once you’ve found it, tell the rest of the work to f*** off, and do this one thing.

Where this leaves you

If you run an IT services firm in India, you’ve probably spent years getting very good at delivery. Clients stay, the work is solid, and the business pays for itself. What most of us never learned is how to find the work worth repeating.

Service-market fit is that work. One to-do, buyers who come looking for it, and a process that gets it done the same way every time. Find it, and growth stops depending on how fast you can hire.

It also makes the firm calmer to run. Fewer projects you don’t fully understand, fewer late nights rescuing them, fewer Sundays spent on a proposal for something you’ll never do again. You can chase 100% growth and still be home for dinner. That’s what I mean by ambitiously slow.

More is coming in this series.

Modern business advice gives you frameworks to help you reinvent your business. Unfortunately, these didn't work for me, and I don't think they work for Indian IT service providers. How do I know? I’ve read everything under the sun, implemented these frameworks, and had no results.

To be clear, I’ve spent a large part of my life in India providing IT services, but my guess is this holds for any geography and any line of business that has vintage and competition. Take the Indian IT services industry. It is nearly six decades old (TCS was founded in 1968), it is a $283 billion industry with over 3,200 member companies in Nasscom alone, and most of its founders are technical people who specialise in the supply side of the business. They don’t know how to generate demand, and they never had to.

Note: Read this piece if you haven’t. It explains how IT services companies can grow at VC speed.

Why now?

I don't want to state the obvious so let me try and answer this in another way. You’ll feel the need to reinvent right now if:

• Revenue is shrinking. Gross revenue is going down.

• Demand you don’t control has stopped arriving. Referrals have dried up and inbound has slowed.

• Clients no longer think they’re buying craft. They still need you, just a different version of you. They know you’re using AI, so what they’re paying for is the output or the outcome, not the hours or the skill behind it.

• You have nothing to sell twice. Everything so far has been bespoke, and you can’t see what to build next without starting from zero.

• You want more. You have an insane drive and dream of exponential growth.

If you haven't guessed, the turning point is AI, in both directions. It removed the scaling limits services firms had, and it gave buyers more choice than they've ever had.

Reinvent. But how?

If you’re like me, you’ve approached this methodically. Founders of IT services companies are a hardworking bunch. They’ve bootstrapped, most have no debt on their books, and they’re profitable. Rare traits these days.

So you read books. You join business consortiums. You seek out mentors, ask founders who are a few steps ahead, and more often than not, hire a consultant. I’ve done all of it. The results were zero. Not “slow to show.” Zero. I have a shelf of books, a folder of decks, and the same business I started with.

I’ll go one step further. I’ve tried every framework you’ll find in the literature. A few, for your amusement:

• Business Model Canvas. Nine boxes. Under “customer segments” I wrote “anyone who calls.”

• Blue Ocean Strategy. Found an uncontested market. Nobody in it had a budget.

• Three Horizons. Horizon 1 paid salaries. Horizon 2 was a deck. Horizon 3 was a feeling.

• Jobs To Be Done. I know the job. I still can’t get the interview.

• Several others with equally confident names.

You get the drift.

Why don’t they work?

They do. They just don’t work for the founder I’m describing. Most frameworks assume the different parts of the business already exist. They’re built for a company that can generate demand, can fulfil it, and simply needs to point that engine in a new direction.

Most bespoke IT services firms don’t have those parts. They have little to no demand generation muscle. (If demand and supply are fuzzy terms for you, read my previous article here.) If you don’t know how to sell, there’s no point spending time figuring out what to sell. You only find out whether something works by trying to sell it. If it doesn’t sell, you pivot and try something else.

For this founder, reinvention doesn't start with a new offering. It starts with demand.

Sell? But what, and how?

Ask any founder who has made it big in this industry and you’ll get the same advice. Go where the buyer is. Most often that means the United States of America or some other part of the developed world. Meet the buyer, show them your portfolio, and sell.

This advice made sense when the industry wasn’t crowded. Vendors were scarce, and a buyer would take an in-person meeting on the strength of a well-written cold email and a decent website.

That world is gone. Going to the market where your buyer is still makes sense. Going without a strategy doesn’t.

So if the buyer isn’t going to meet you, you need a sales strategy where they come to you. There is exactly one method that does this today, and that is CONTENT.

I’m not going to cover what content to create. That’s an article of its own. What I will say is this: people in their twenties, selling something as commoditised as LinkedIn posts, are running seven-figure agencies off nothing but their own content. Tommy Clark started posting as a college student in 2018 and now runs an agency doing over a million a year. Nicolas Cole built a ghostwriting shop with 80 clients on the books and several million in annual revenue, all under other people’s names. The list goes on.

Every Indian IT services founder I know solves problems far more complex than that. They just can’t generate demand for it. Here’s how you fix that.

The playbook

1. Go broad on content, narrow on the offer. Build a social media strategy around your expertise, but let it touch a wide spectrum of subjects. If you provide app development, you could post the same message on repeat (”if you have an app team, I can cut your cost by X”), or you could talk about hiring, product decisions, AI tooling, shipping speed, all of it tracing back to app development. Do the second.

2. Entertain and go viral. Fuck the cringe. People are on social media for themselves, not for you. Learn to be entertaining and learn the mechanics of going viral. Both are skills.

3. Qualify through the CTA. Broad content brings everyone in. The CTA sorts them. It is the most powerful qualification tool you will come across, so write it to attract exactly the person suited to your offer. If you sell engineering, the CTA is “Cut your engineering spend by 40% in 90 days,” followed by a form that asks for current team size and monthly spend.

4. Experiment with the CTA. If you offer a bouquet of services and don’t know what to sell, keep changing the CTA. An AI readiness audit. A legacy code review. A fixed-price MVP in six weeks. Whatever. You can only sell to people once they show interest, and the CTA is where interest shows.

5. Reverse engineer a productised service. Once a CTA converts, build the delivery mechanish behind it. A productised service is one where the process that produces the output matters more than the person running it. The audit follows the same checklist for every client. The MVP uses the same stack and the same six-week plan. Same input, same output, every time, whether it’s one-off, monthly, or a retainer.

6. Scale. A team of 30 can now serve 300 to 400 customers. Fixed price, fixed output, and no single client large enough to hurt you if they leave. Your rate per customer will be lower than what you charge for bespoke work today. Your revenue won’t be.

Where this leaves you

There’s a line I heard from a YouTuber that I keep coming back to: “Learn new skills and make more money.”

I wrote this piece because I think the Indian services entrepreneur is one of the hardest working people in business. They compete for talent with venture-funded companies, put their own sweat and blood into the work, and care deeply about their clients. So deeply that I’ve seen services firms retain the same client for years. That kind of retention is unheard of.

If only they learned how to sell in today’s age. That one skill takes the business to a different scale.

So it’s time. Time to learn new skills and stop hiding behind “client work is keeping me busy.” Stop pouring everything into the supply side of the equation.

Remember the parts of the business you avoid are the hardest ones, and they’re the ones that pay off when you do them well.

It's time... So crush it.

New here? My name is Ali and I write about the art of building digital products, transforming your business with AI, and outsourced IT services. Subscribe if these subjects interest you. Ooo also if you’re interested in b2b businesses join my community.

I started Wednesday in 2019. If you don’t know Wednesday at the time was in the business of outsourced product engineering. That’s a fancy way of saying, we helped onshore digital businesses with product strategy, design, and engineering at an affordable rate.

Thousands of firms in India alone offered the exact same services. Globally the number is far bigger, and it gets more crowded every month.

Over the years in this business I’ve built a small circle of friends. Some have exited, some are still building, each at a different phase. What follows comes from my own experience, checked against theirs. So here goes.

Services scale worse than software per unit of capital. It’s a slow business. People based, referral based, hard to grow. Every services founder has heard this, and most of us have said it. Hell I have said this multiple times. I no longer believe it.

Indian IT services was built on headcount. Revenue was engineers multiplied by a billing rate, so growth meant hiring, and hiring was the hard part. We faced this ourselves. Finding good people and getting work out the door was the bottleneck for years.

That bottleneck is gone. Wednesday, for example, now runs a fleet of agents per project and delivers the same customer experience with a third of the people a project used to need. Enough has been written about what an AI-native services business looks like, so I won’t repeat it. What I want to write about is growth, because removing the constraint changes what you can aim for.

A venture-backed startup is expected to double (or more) every year. I think an IT services firm can now grow at that rate. The rest of this piece is about why most won’t, and what to do about it.

Elements of demand & supply

Every services firm has a supply side and a demand side, and growth depends on the two matching. So it’s worth being precise about what each one is made of.

Supply is everything your firm puts out into the world. It includes:

• Your website, which says what you do and for whom

• Case studies, which show what you’ve done before

• Testimonials, which say someone was happy with it

• Services and offers, which say how you package the work and what it costs

• Socials and the founder’s LinkedIn, which show what you think about

Each of these is a signal to a buyer about what they’d get if they hired you. Put together, they are the shape of your firm as seen from the outside.

Demand is simpler. It’s a to-do on the buyer’s list. It’s near the top, they cannot avoid doing it, and they’ve tried the obvious options and none have worked.

It looks like this:

• They hired a chief AI officer a year ago. Operating cost hasn’t moved and nobody can point to a process that runs differently. The internal team has no experience with this, every POC has stalled, and the board wants results in 2 months. They’re now looking for someone who has done an AI transformation before.

• They ran paid ads for six months and got leads the sales team couldn’t close. The founder has a following on LinkedIn but no system behind it. They need pipeline this quarter, and they’re looking for someone who can turn the founder’s brand into a lead channel.

• They need twenty engineers by March for a contract they’ve already signed. Their two staffing vendors have sent them forty CVs and no one worth hiring. They’re looking for a team that can start in weeks.

• Their core platform was built by a vendor who no longer picks up the phone. An audit is due in six months and the stack won’t pass. Their team can keep it running but can’t rebuild it. They’re looking for someone who can get them compliant without a rewrite.

Every one of these has three things: a date, something that already failed, and a gap the buyer can’t close alone. When all three are present, the buyer is looking for you. When any one is missing, they aren’t, and nothing you put on your website will change that.

Growth

Growth happens when your supply is the shape of somebody’s demand. Think of it as a puzzle piece. The demand has a shape. Your job is to find it and cut your supply to match. Most firms do it the other way round. They cut a piece, then go looking for a hole.

This is what it looked like for Wednesday before AI. A founder has raised a seed round and has twelve months of runway. The investors want a product in market by month six. The founder has tried hiring and found that senior engineers won’t join a company with no product, and the two freelancers she found have built a prototype that can’t be extended without starting again. That’s the demand: a date, a failed option, and a gap she can’t close herself.

Our supply at the time was: “We take you from idea to MVP in twelve weeks with a team that stays on for the next iteration.” Same shape. She didn’t need us to explain what we did. It was easy to sell and fulfil the todo.

That match is what growth is made of.

Can services have exponential growth?

Yes. The constraint on a services firm was always people. Every new project needed new hires, and hiring was slow, expensive, and hard to get right. That put a ceiling on how fast you could grow no matter how much demand you found. The ceiling is gone. A team of three with agents can deliver what a team of ten did two years ago, and it can take on the next project without waiting for the next hire.

And yet the average digital agency grew 7.5% last year. Nobody is doubling. A business that has lost its bottleneck is growing at the same pace as when it had one.

The reason is where the money goes. When a services firm decides to grow, it spends on supply. A new website, a new deck, a rebrand, a video for the case studies page, a fresh set of service lines. I did all of this. What almost nobody does is go and find out what demand looks like right now, who has a to-do, what they’ve already tried, why it failed. Which is a strange choice, because supply is the part you control and demand is the part that decides whether you get hired.

Fixing this is a mindset change more than anything else. Six things have to move, and I'll take them one at a time.

1. Rate of growth matters more than growth

Most services founders plan for growth. Twenty percent this year, thirty if a big client lands. That was a sane target when every new project meant new hires. It’s a low one now.

Rate of growth is a different question: how fast can this compound, and what would have to be true for it to double. A venture-backed startup is judged on that rate and plans backwards from it. Services founders have never had to ask the question, because the answer was always headcount. It isn’t anymore. Set the target at 100% and work out what has to change to get there. The target moves first. The strategy follows it.

2. Competition matters less than you think

Almost every services founder I’ve spoken to, from the two-partner shop to the firm with a thousand people, makes the big decisions the same way. Which service lines to add, which markets to target, what offers to run, what kind of customer to go after. They look at what competitors are doing and do a version of that.

Demand for the category was already proven, and the constraint was supply. Whatever you did, you were going to grow ten or twenty percent, because that’s how many people you could hire and bill. So the sensible move was to copy a working model, do the work well, and grow a little faster than the market. That’s the whole strategy, and for two decades it was enough.

The bottleneck has moved. Supply is no longer the thing that caps you, demand is. Consider what that means by looking at a product company. If it wants venture backing, it has to grow fast, and there is only one way a product company grows fast: it finds a to-do that buyers are desperate to get done, that they cannot put off, and that nobody has a good answer for yet. Everything else, the roadmap, the pricing, the marketing, comes after that. The to-do comes first, because without it there’s nothing to grow.

Services firms have never worked this way, and most have never needed to. Finding an unmet to-do is a muscle the industry never built, and the Indian firms I’ve seen are the weakest at it, because the model here was cost arbitrage on proven demand for so long. But the reason the muscle didn’t matter is gone. You are no longer supply-constrained, which means the thing that let product companies grow fast is now available to you.

The fix is simple to state: stop looking at competitors at all. The only thing worth studying is the buyer’s todo list.

3. Find the new to-do

Buyers’ lists change. Two years ago few small firms had “run the operation with fewer handoffs” or “answer every customer in under a minute” near the top of theirs. Now they do. Upwork’s Q1 2026 survey of SMB leaders (10 to 99 employees) found efficiency is the most anticipated outcome from AI agents over the next two years, cited by 68%, and customer service is where the most pilots are running, at 40%. One in three call AI agents mission-critical to company strategy.

What makes this demand, is that the first attempts haven’t worked. 74% say AI has improved productivity, but for most the gain is under 25%. The to-do is at the top of the list, the pilots have run, and the result is a modest gain and no clear return.

In another two years the to-do will be something none of us can name yet. Fast growth comes from spotting it while it’s still new, before it has a category name, before there’s a rate card, before there’s a competitor doing it whose website you could copy.

4. Sell before you build supply

When a services firm decides to reposition, it does the responsible thing. It runs user research, reviews the competition, writes a new ICP, defines the pain points, builds an offer. Six weeks later there’s a document. The document becomes a new website, a new deck, a new set of case study videos. Then the firm waits for the phone to ring.

I’ve done this. It produces excellent material and no growth, because every one of those artefacts was built from what the firm thought demand looked like, not from what it heard a buyer say.

There’s a faster way to find out, and it’s cheaper. SELL. I’m not asking you to hire a salesperson. I’m talking to you the founder or someone in the executive team. Get on calls with people you think have the to-do and try to sell them the outcome. Every call tells you whether the to-do is real, whether it’s urgent, and what they’ve already tried. Ten calls teach you more about demand than a research project does, and you might close one.

If you’re stuck and want the mechanics, here they are. I’ll write a separate post on each.

1. Find the to-do, or guess it. If you have a year of sales calls, mine them. Listen for the same sentence coming from different people, and write it down in this shape: “We need to ______ by ______. We’ve already tried ______ and it didn’t work because ______. We can’t do it ourselves because ______.” If you don’t have calls, you don’t get to skip this step. Fill the blanks yourself, as a hypothesis, and go sell it. The sprint will tell you whether you guessed right. Either way, the last two blanks are what you’re selling.

2. Run a sales sprint. Pick a cohort of twenty people who should have that to-do, reach out, and try to sell them the outcome. Do it every day for a week. Then change the cohort, or change the to-do, and run it again. The point is speed of learning, not close rate.

3. Look for pull. After each sprint, listen to the calls. You’re looking for the person who didn’t need convincing. They had the to-do, they’d already tried something, and they moved the conversation toward a start date without you pushing. If you had to explain what you do more than once, it’s a red flag.

4. Then scale. Once one cohort is pulling, and only then, put the supply behind it. Website, deck, paid, webinars, events. You now know what they say, so you know what to write.

5. Say no to referrals

This one is hard, and it’s hardest for the firms that are doing fine. If you have customers, a team to keep busy, and a reputation that brings work to your door, saying no to that work feels wrong. Every instinct you’ve built over ten years says take it.

Most services firms run on exactly this. Haus Advisors’ 2025 benchmark of development agencies found 82% rely on referrals and word of mouth as their primary source of new business. In a supply-constrained world that’s the whole model: the network produces a project, the firm staffs it, the client refers the next one.

6. Be something to someone

Open the website of any large services firm and try to answer two questions: what do they do, and for whom. You won’t be able to. They do everything, for everyone.

This is what happens when a firm grows on referrals for long enough. Each new client adds a service line. The result is a menu. A buyer with a burning to-do doesn’t want a menu. They want the one firm that has done their exact thing before.

The data on this is unusually clear. Promethean’s 2026 agency benchmark found agencies that reduced their services grew fastest, at 13%, while those that expanded grew 9.8% and those that held steady 5.7%. The firms that narrowed also posted 30% net margins against an industry average of 13%. Cutting what you offer made firms grow faster and earn more.

So be something to someone. Pick the to-do that pulled in your sprints, and let that be what the website says, and what the case studies show.

Where this leaves you

I wrote this for the founder who is sitting on a firm that works, that grows a bit every year, and who has a feeling it could be a very different business now. You’re right, it can. The thing that stopped services firms from growing fast was hiring, and hiring isn’t the bottleneck anymore.

So set the target at 100%. Heck a 1000%. Change your mindset.

One night, unable to settle, he did the thing that had always steadied him, which was to put it down in writing. If he could name exactly what he needed to know, he thought, and then go and find the answers, the unease would have nowhere left to sit. He wrote three questions, one under the other.

He looked at them a long while. They seemed, on the page, to be the whole of it. Answer these three, and a man would know where to stand, whatever came. He had been good at his work for nine years, good enough that other teams called him when something broke in a way no one could explain. Surely the answers were findable. He folded the paper away, and still he could not sleep.

So he began to ask. He asked a senior he trusted, who told him the fundamentals never change and he should go deeper into them. He asked a friend who had moved to Berlin, who told him the opposite, that the fundamentals were the cheap part now and he should learn the new things first, before the others did. He listened to people who spoke with great confidence in public. One said the years ahead belonged to those who went broad. The next said they belonged to those who went narrow. At night he would open the profile of a man he had never met, senior to him by a great distance, and read it slowly, watching the man’s title for some sign of where a person ought to stand.

All the answers were different. He agreed with none of them, and kept his questions, and slept badly.

In April he was sent to sit at a bank. Four days a week he was to sit at their operations desk and write down how the work was done, before anyone proposed changing any of it. He read the instruction twice. To sit and write down. To build nothing. He thought this was the quiet corner they kept for men on their way out. He replied that it sounded good.

He was put beside a man named D’Souza, who had been at the bank thirty-one years. D’Souza did a slow and exact kind of work that Sandeep had believed no one still did by hand. He kept a register in his own writing. He knew which payment would fail before it failed, the way an old man knows rain is coming, because he had watched that same file behave that same way a thousand times. Sandeep’s task was to write down what D’Souza knew. He found it dull past description. He had been among the best at his own work, and here he sat, taking down the knowledge of a man with a register.

He took it down anyway, there being nothing else to do. And some days he did not think of his three questions at all, because writing down what D’Souza carried took the whole of his attention, and what D’Souza carried had no bottom to it. A week went by, and then another. He learned the names of the people at the desk, and which of them took sugar.

There was a manager at the bank named Rao who had not wanted Sandeep’s people there, and said so, in the courteous way that leaves no doubt. He believed outside men came in, drew their diagrams, charged for them, and went away, and that D’Souza and his register were worth more than the lot of them. Sandeep, who privately thought Rao was right, found it hard to sit near him.

On a Thursday near the end of the month a cheque did not clear. It was small by the bank’s reckoning, but it was the wages of forty men who worked for one contractor, due on the first. The cheque had stuck somewhere in the gap between the bank and the clearing house. D’Souza had stepped out. Rao stood over the desk, pale, for the contractor was on the telephone and the cut-off was 40 minutes away.

Sandeep sat down at the screen. He traced the cheque, and he asked the desk the things that only they could know, the small local truths written down in no manual, and between what he could read and what they could tell him, they found where it had stuck and put the cheque through. The forty men would be paid on the first.

Rao said little. He laid his hand on Sandeep’s shoulder a moment, and left it there, and went to make his call.

On the cab home that evening his phone lit in his hand. It was the hour he usually lost to it, putting off sleep, scrolling the news, reading one more thread about what was ending and what was coming, and feeling the unease climb the more he read. His thumb had found the phone before he had decided anything. But tonight he looked at it and felt nothing.

He turned the phone face down on his knee, and the three questions he had written in came back to him. This time he had the answers.

It had all been in front of him the whole time.

The cab crossed the river. He watched the water go by and did not reach for the phone again.

When the rate of change is fast, the mind runs only one way, which is forward. What will happen? What am I supposed to do?

But the speed is the only new thing. Slow it down, and what is left was always there. The future was never knowable. We believed otherwise only because, for a long while, it changed slowly enough to ignore.

The future has always been uncertain.

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

1. Gopalakrishnan, S., Dayasindhu, N., Narayanan, K. Against All Odds: The IT Story of India. Penguin, 2022.

2. Infosys Limited. Annual Report 1993–94. Bangalore: Infosys, 1994.

3. Gopalakrishnan et al., Against All Odds, 2022. (Quotes from Srini Rajam, Sridhar Mitta, Diju Raha.)

4. Sharma, Dinesh C. The Outsourcer: The Story of India’s IT Revolution. MIT Press, 2015.

5. Sharma, The Outsourcer, 2015. (Y2K remediation volume and salary comparisons.)

6. Infosys Limited. Annual Reports, 1998 and 2000.

7. NASSCOM. Strategic Review 2001. New Delhi: NASSCOM, 2001.

8. TCS, Infosys, and Wipro Annual Reports, 1999 and 2010.

9. NASSCOM. Technology Sector in India: Strategic Review 2025. New Delhi: NASSCOM, 2025.

10. NASSCOM. GCC Landscape Report 2024. New Delhi: NASSCOM, 2024.

11. India Brand Equity Foundation. IT & ITeS Industry Report. IBEF, 2024. (GCC workforce projection of 3.46 million by 2030.)

12. Company disclosures and press statements, 2023–2024. (JP Morgan and Microsoft India headcount figures.)

13. Staffing Industry Analysts. Largest Staffing Firms in India 2025. SIA, 2025.

14. National Science Foundation. Science and Engineering Indicators 2024. Washington, DC: NSF, 2024.

In the highlands, where clouds split against ancient stone, there stood a mountain known as the Aethros.

For a thousand generations, the people of the valley below were the Carriers. They learned the way of the burden: how to balance impossible weight, how to breathe thin air, how to place each foot on paths where one slip meant death.

The Aethros was merciless. Ice storms could blind you in moments. The air so thin that men would collapse, their lungs burning, their vision narrowing before darkness took them.

And yet, the people climbed.

Every day, merchants arrived with goods that needed to cross the mountain. The path around took thirty days. Over it, if you survived, took seven. The Carriers made this journey, hoisting massive loads onto their backs and beginning the ascent.

Children would watch their fathers leave at sunrise, counting days until their return. Sometimes, they returned. Sometimes, they did not.

This was the way. This was who they were.

The Carriers took pride in their suffering.

In the longhouses at night, veterans would show their scars: the twisted knee, the blackened fingers lost to frostbite, the burns from volcanic vents. These scars were holy. Proof of worth.

Young men would brag about weight carried. The merchants paid well, not for what reached the other side, but for the attempt. One stone carried paid for one day’s food. The more you carried, the more you earned.

Some had made fifty crossings. Living legends, their bodies broken but their status unquestioned. They were revered.

No one questioned why this was necessary. The mountain was simply there. Crossing it was what Carriers did. It was their identity, their economy, their entire world.

Then, in the span of a single generation, the world shifted beneath their feet.

The mightly Aethros began to collapse, its frozen heart giving way to change.

It began with small tremors. Routes that had been stable for centuries suddenly collapsing. The elders dismissed it. Mountains shift, they said.

But it didn’t pass. Within a few years, great sections of the Aethros began to crumble. The snow line dropped. Ice bridges melted. And most impossibly, the mountain itself seemed to be sinking.

Passes that had taken days now took hours. Slopes that had killed countless Carriers became gentle inclines that even children could walk. The thin air grew thicker. The bitter cold became merely cool.

At first, the Carriers celebrated. “The gods favor us! The mountain grows merciful!”

But then the merchants stopped coming.

A Carrier named Kael returned from what should have been a seven-day crossing. It had taken her two.

She found her merchant settling accounts. “You did excellent work,” the merchant said. “But this will be our last contract.”

Kael stared. “The crossing is easier now. We can carry more, move faster...”

“That’s exactly the problem,” the merchant said, not unkindly. “Anyone can make that crossing now. My own children could do it. I don’t need Carriers anymore. I need someone to tell me why my goods aren’t selling on the other side. I need someone to help me understand which goods to carry in the first place.”

She paused. “The carrying itself? That’s no longer the hard part.”

Kael walked back to her village in silence. The ropes on her shoulders, once badges of honor, suddenly felt like chains.

The village council convened that night.

“We must train harder!” the elder Carriers shouted. “Lower our prices! Carry more for less!”

But Kael stood and spoke: “The mountain is dying. And we are dying with it.”

The longhouse fell silent.

“For a thousand years, we’ve told ourselves that our suffering made us valuable. That our scars were holy. But we were wrong. We weren’t valuable because we could suffer. We were valuable because the mountain was impossible to cross any other way.”

“Now the mountain is possible. Soon it will be easy. And when any child can walk across it... what are we?”

An old Carrier spat on the floor. “We are Carriers. That is what we are.”

“No,” Kael said quietly. “We carried because people needed things moved from here to there. But that was never the real problem. The merchants don’t lie awake worrying about how goods cross the mountain. They worry about which goods to move. Where to sell them. Why no one’s buying what they have.”

“Those are not our problems to solve,” the elder said.

“Then whose are they?” Kael asked. “Because if we don’t solve them, someone else will. And we’ll be left here, practicing our rope knots while the world moves on without us.”

The village split.

Some Carriers continued as they always had, carrying lighter loads over an ever-gentler mountain, earning less and less, telling themselves the mountain would grow fierce again.

Their numbers dwindled.

Others, like Kael, made a more painful transformation. They went to merchants asking not “what should we carry?” but “what problems keep you awake at night?”

They learned that merchants struggled to predict demand. That timing mattered more than carrying capacity. That the real value wasn’t in the crossing. It was in knowing what to cross with, and when, and why.

These transformed Carriers were no longer paid for their suffering, but for their insight. Sometimes their advice was wrong, and they earned nothing. But when they were right, when they helped a merchant succeed, they earned more than any crossing had ever paid.

It was terrifying. The old way had been clear: carry weight, endure pain, get paid. This new way meant thinking, questioning, and sometimes failing.

But slowly, these new merchants-who-had-been-Carriers began to thrive.

Years passed. The mountain continued to shrink.

Years passed. The mountain continued to shrink.

One evening, Kael stood at the base of what had once been the dreaded Aethros. Children played on slopes that had once killed their grandparents. Flowers grew at heights where nothing had grown before.

An old Carrier sat nearby, one of the last who still practiced the ancient forms, loading stones onto his back, climbing for no purpose except that climbing was what Carriers did.

He saw Kael and spat. “You betrayed us. You abandoned the way.”

Kael sat beside him. “When I close my eyes, I still feel the ropes cutting into my shoulders. I still taste blood from breathing thin air. Those things were real. Our strength was real. Our courage was real.”

The old Carrier nodded, vindicated.

“But they were never the point,” Kael continued. “We thought the suffering itself was sacred. We became so focused on being strong enough to climb the mountain that we forgot to ask why we were climbing it at all.”

She gestured toward the children. “The mountain made us necessary. And then it didn’t. And we had to choose: spend our lives mourning what we used to be necessary for, or find new ways to be necessary.”

“I am a Carrier,” the old man said stubbornly.

“No,” Kael said gently. “You were someone who solved the problem of crossing an impossible mountain. The mountain stopped being impossible. The problem changed. And we have to change with it.”