top of page
  • Writer's pictureKen Shaw

Building Award-winning Software Offshore — Part 1: Culture & People


A survival guide for entrepreneurs, investors, and product/engineering leaders who want to use offshore teams.

Audience: Founders, CEOs, product & engineering leaders, investors.


1. Introduction & Overview A lot has been written about offshoring, but not much here on Medium, and little about the specific considerations that apply to its adoption by software startups vs. established companies. Having spent most of my career using offshore teams, and doing so with success, I thought I’d weigh in.


This series is a deep-dive for small and mid-sized companies (up to ~$100M ARR). If you’re a large company, much of this is applicable, but there are a whole slew of additional complexities that aren’t covered here.

Figure 1: Comparing Onshore vs Offshore for developing great product


And here’s a summary of patterns & anti-patterns:

Figure 2: some do’s and don’ts for quick reference1.1 Who this material is and isn’t for

This material is written for folks that haven’t done a lot of offshoring and are considering it either for their new venture or product, or as a cost reduction strategy in an established software company. This post is probably of most use to CEOs, investors, or product and engineering leaders who are facing challenges around 1) product & engineering OpEx; or 2) talent acquisition and retention issues derived from using in-market resources (contract or permanent).

It’s not an exhaustive dissertation by any measure, and if you’re a sophisticated practitioner I’d welcome your take, but this might be reductive for you. A lot of my viewpoints are also antithetical to the positions of global outsourcing/offshoring companies (think Accenture, Wipro, TCS, Infosys, etc). That’s deliberate; I have a low opinion of them. Use them if your company is rich, lazy, or scared. Big traditional enterprises are often all three. The lens I’m looking at this topic through is that of building category-leading software products for paying customers, which is an inherently difficult task that offshoring can either greatly assist with, or greatly confound.

1.2 Who am I to have an opinion? Why should you listen to what I’ve got to say on this topic? Well, I’ve got 15 years of hands-on experience. I’ve wasted a lot of money by making mistakes in offshoring, and maybe you can learn from my painful and expensive lessons. Conversely, I’ve had success with offshoring. In my first company, I built an offshore team, and we built a world-class B2C product that won 7 x PC Magazine Editors’ Choice awards (back when PC Mag was big and powerful and very hard to impress).

In my second company, I also built offshore teams. We built a world-class B2B Disaster Recovery product for enterprises (lest you think offshoring doesn’t lend itself to serious or big complex products). That product was awarded the Gartner “Cool Vendor”, “Visionary” and “Leader” distinctions, as well as coming 2nd on their “Critical Capabilities” report. 2nd only to IBM, which is pretty incredible given their multi-billion-dollar revenue machine around DR. Being named Gartner Leader is a bit like being nominated for an academy award for B2B software. At least that’s how we felt.

We also had success delivering support and product management out of Eastern Europe. Our engineering bill was less than a third of our competitors as a % of OpEx despite the fact we had a higher % of headcount in prod/eng. We also had a tremendous sales & marketing team out of India that delivered leads at a price that was 80% less than what we were able to do through onshore biz dev teams. We had an inside sales team transacting $10k contracts with an LTV/CAC of 6+ on deals transacted there. In short, we achieved terrific quality in different domains at very low costs.

1.3 Structure of the content When I sat down to write this it was meant to be a short post, but it ballooned up into more than 10,000 words, so I’ve broken it up into a series of discussions as follows:

  • Part 1: Building Great Product Offshore — Culture & People; (this article)

  • Part 2: Building Great Product Offshore — Recruiting & Team Work;

  • Part 3: Building Great Product Offshore — Process Issues (prod and proj mgmt etc);

  • Part 4: Building great Product Offshore — Considerations for Start-ups vs Established Companies;

I’ll update these links as I publish. Let’s dig in!

2. Culture & People Issues in Building Great Product Offshore

Whether you’re a startup or an established company, there are some rules that apply to building great product offshore regardless of your company’s stage. Here are some of them:

2.1 The world is flat & talent is abundant In Thomas Friedman’s book The World is Flat he makes many points about globalization but one that is super-relevant here: we now operate in a “flat” global market of talent for knowledge workers.

  • There are ~4.5M developers in the US today;

  • In India there are at least 5M developers today and Github thinks there’ll be 10M by 2023;

  • IbisWorld says there are 6M developers in China (I’m suspicious of this number, but it doesn’t matter for the purposes of this discussion);

  • There are ~500k developers in Russia;

  • There are ~850k developers in Eastern Europe (with 200k in Ukraine, 250k in Poland, 125k in Turkey, 100k in Romania, 100k in the Czech Republic, 80k in Hungary);

Populations: It’s already the case that there are (many) more developers outside of the US than in it, and given the state of STEM education in the States the number of onshore developers is not going to grow in any remarkable sort of way, whilst the demand for developers is growing quickly and consistently. Maybe the low-code/no-code movement will move the needle, or the emergence of AI-based technologies like Github Co-pilot could improve productivity so much that there isn’t a talent crunch, but those seem like developments that will trim around the edges rather than fundamentally change the supply and demand calculus.

Multi-part equation: Volume is only part of the equation; the second part is cost. Depending on which market you’re talking about the cost of paying a wage for a developer is 60%-80% less than it is in the US. This ratio is likely to continue to improve in favor of offshore markets as the demand for talent in the US is going up, and rich companies are getting richer which is driving up prices. On the supply side of the equation, the US just isn’t churning out many new developers whereas China and India are doing it like its their job (and in a really literal sense, it is their job).

Real life numbers: To give you a real-life example based on the markets I’ve worked in, the cost of a senior .NET or Java engineer in Chennai, India is about $20,000 per year; in Kiev, Ukraine about $30,000 per year and in the US it varies by city but $150,000 is about right. Unless you’re in Northern California.

There’s gold in them thar hills: If you’re still wondering about whether or not this is worth the effort (either of reading all of this, or embarking on an offshoring journey), let me paint an economic picture. Dropbox spends 35% of revenue on R&D ($740M per yr). They’re valued at about 35 x EBITDA. A quick inspection of a random sampling of engineers on LinkedIn indicates that most are based in the Western markets. Let’s say they moved 30% of their budget to low-cost markets, and only achieved a modest 60% reduction in spend, they’d unlock $4.7 billion dollars in enterprise value. They’re currently only valued at $12.5 billion. So we’re talking about massive value creation here (+37%). Drew Houston might want to think about that. (Of course there are other considerations around risk and politics, but those are separate issues).

Rules apply: It’s pretty clear that there are compelling economic reasons to go shopping for talent in these developing markets. The obvious question is whether or not the quality is as good? That’s the third part of the equation and the answer here is that it definitely can be, you’ve just got to be careful and follow some basic rules. This series is going to cover a lot of them.

2.2 You’ve got to own it

Offshoring != outsourcing: The first and most important rule is that you’ve got to own your offshore operation. Folks approach offshoring as if it’s synonymous with outsourcing, and that often locks in failure right from the outset of the endeavor. It’s the number one reason for failure. Offshoring is about moving labor to another location other than your primary market. It’s NOT about delegating control to someone else and putting an intermediary between you and your value creators (engineers, sellers, marketers, designers).

It's risky: Building software products is an inherently risky business and if the yardstick is building a great software product, then most efforts fail statistically speaking. With offshoring, you’re introducing a whole new slew of complex variables into your working environment (time, language, culture to name a few). The last thing you want to do is put another company between you and your knowledge workers. Most people do, and that’s a big reason why most companies suck at offshoring.

I think about it like this: 1. Chance of building a great software product in general == low; 2. Chance of succeeding with offshoring in general == low; 3. Chance of succeeding with outsourcing in general == low;

So you have: Low x Low x Low == really stinky odds. If you’re reading that and thinking “well, maybe I should just focus on #1 and avoid #2 and #3” you wouldn’t be wrong. Outsourcers reading this will balk at my viewpoint and argue that their skill set actually increases the chances of succeeding at #1 and #2. That might be true of a few elites, but not the overwhelming majority.

Mitigate your risk: To improve your odds of success (and that’s all we’re doing here… nothing is guaranteed) you need to own your offshore operation “down to the ground”. I don’t mean literally own the building you’re operating from, but I do mean owning the people as FTEs, owning the processes, owning the HR department, owning the tools that are used, owning your own employer brand in your target market, owning the IT infrastructure etcetera. Why? Because if you own these things, you can optimize them; if you don’t have 100% visibility into them they’ll probably be crummy. And not in a small way… in a really bad way.

Here’s a list of things that you should own in descending order of importance:

  • The HR function and an internal recruiter;

  • A rockstar local manager (I call this the “Country Manager”, but use whatever title you like);

  • The technical leadership team (if it’s a software product, the architect and team leader; if it’s a sales team the team leader and the trainer);

  • The tools and technology being used;

If you don’t own these things, particularly the higher-order functions, you’re increasing your risk of failure geometrically.

Control: What do I mean by “own”? i.e., you can’t own a person and I’ve enumerated a bunch of humans in my list. With respect to the humans, I mean you need to have: 1) found them; 2) developed them; 3) they must be controlled by you directly; 4) they must be dedicated to you (not shared services); 5) they must be completely trustworthy and trusted. If you can achieve those 5 things, then you’re on your way to success. If you compromise on these things you’re amping up your risk. Now my position against outsourcing should be clearer. In an outsourced environment usually, the same list of five factors looks like this: 1) the outsourcer finds the talent; 2) the outsourcer is responsible for professional development; 3) the outsourcer is their true employer and that’s where their real loyalties lie; 4) they’re often shared service employees serving at least one other customer; 5) they might be trustworthy, but their split loyalties muddy the waters.

Proceed with caution: “But that’s just not feasible”, I hear you thinking. OK, well you’ve got a couple of options in that case. Firstly, you can compromise and use shared services or have management in place that either you don’t own or who isn’t a rockstar. This is dangerous and should only be done if it’s temporary and you’ve got a clear pathway to achieving full ownership. Your second option if achieving this degree of control isn’t possible is to move forward aware of the risks. Make sure you brief your stakeholders (boss/investor/etc) on the risk. Only proceed like this if the project isn’t mission-critical and you can afford to write off the entire thing as an experiment. Neither of those conditions is true for a startup building its maiden product.

It's hard: This whole section probably isn’t being received well by the start-up founders among you reading this who think that offshoring is a silver bullet for costs (which it really can be), but it’s the poorly understood truth. Similarly, if you’re an executive in a more established business who is reading this, you might be thinking “geez, that sounds like a heavy lift for my project”, and you’d be right. If you don’t have the time, money, or stomach to make these investments, keep your project onshore.

BOTS: if you don’t know where to start in building your offshore operation, there are outsourcing companies that provide what’s called BOT services, which stands for Build, Operate, Transfer. This is the exception to the “don’t use outsourcers” rule, as the result of their effort is that you do own your team, talent, and technology. These providers help you de-risk across multiple vectors and are definitely worth looking into.

2.3 Beware of cultural traps

This is a non-obvious issue that can really bite you in the behind.

Culture matters: The basic thought here is simple: be aware of the fact that you’re hiring folks that come from a very different cultural background than you and your onshore team, and that hidden cultural differences can be really impactful. In other words, culture problems cost you money.

Indians can be shy: The classic example of this is the Indian engineer who shies away from conflict. It’s an offensive stereotype to Indians, and I’ve worked with plenty of Indian execs who buck this mold, but there is a real-world phenomenon that junior (and not-so-junior) engineers/professionals from India are often conflict-averse and will “go along” with decisions made by their onshore counterparts without challenging them even when they know them to be bad. If you’re hearing “yes” to everything this is a culture-problem smell. By contrast, getting Ukrainian engineers to say yes to anything can be a challenge! When you’re building a software product, like most difficult professional endeavors, you want creative tension between teams and between team members. You want the best thinking you can get from everyone. That’s what you’re paying for. So conflict avoidance is antithetical to building great product.

Americans can be brash: This is going to be an unpopular thing for me to express, but problems also go the other way. If you ask an engineer from Russia, Eastern Europe, India or China what they think of their American teammates, you’ll get an eye-opening array of descriptors if they’ve got their guard down (hard to achieve in formal settings). I’ve heard that Americans are brash, rude, impatient, bad listeners, imperialistic in their views, and completely ignorant of the cultural norms of the country the person is from.

Combinations matter: As a leader, you’ve got to guard against this in both directions. You need to understand the nuances of the culture of the market that your offshore resources exist in, you need to understand the way your own country culture is perceived, and then you’ve got to look at the interaction between the two. If you’ve got an “arrogant American” working with a “shy Indian” engineer, bad things are going to happen.

Learn: How do you learn the culture? Go there. Read books. Bring them to you. Spend time outside of office hours with the folks you’re working with. Really get them to open up (however you want to achieve that — in Kiev, vodka works well). Really listen to them. Probe them on what they really think and feel, not what they think you want to hear. Challenge their positions and see how they react. Ask them to poke holes in your ideas and see what they say. There’s no short-cut to this process. It takes time and patience and commitment. Yet another reason why you shouldn’t just embrace offshoring and think it’s going to be a quick solution to your talent or cost problems.

At this point, you probably think I’m against offshoring, which is 100% incorrect. But I’m trying to give an unvarnished look at the issues you’re going to face if you adopt it as an approach.

2.4 Don’t run two cultures

The idea of not running two cultures is a natural flow-on from the previous point. It’s tempting to just let the two country cultures continue to exist without integration or change, but this is an anti-pattern and should be avoided.

Transplant awesomeness: I can hear politically sensitive people cringing at this idea, with their knee-jerk reaction being “you can’t and shouldn’t change someone’s culture”, but that’s just not true. You can build one company culture that transcends local country culture. In fact, that’s vital to high-performing teams. Just like you internationalize a product through abstraction and then customize it for a market in your localization process, apply the same concepts to your company culture. Take the things that make your local team unique and awesome, distill them into their essence, and then figure out how to deploy that same culture in both countries. That sounds like hard work, and it is. So how do you do it and why should you do it?

Why bother? You need to build one culture because it’ll really slow you down if you don’t. Company culture being different between two offices is going to happen but needs to be minimized. It’s like technical (or commercial) debt: it gets much worse over time. If this concept is too touchy-feely for you, let me translate this into a financial point: running two cultures will cost you money because it wastes time, increases misunderstandings, leads to a lack of motivation, creates staff retention issues, and increases conflict that’s got to be resolved by someone.

So how do you do it? Crowdsourcing is one tried-and-true technique. Source your team values from your team, as a single global group. Then vote on the harvested ideas and come up with a set of values that everyone in the organization believes in regardless of geography. I call these meta-values.

This doesn’t have to be overly formal. But you want to get to a point where everyone on the team, regardless of location, knows what will be looked upon well by senior management and what will be frowned upon. Difficulty: Don’t get me wrong: this process is hard. At my company, I had multiple teams in India, Ukraine and the USA. Achieving one company culture was difficult, but we did have a set of meta-values that applied no-matter which country you sat in, and everyone knew what “good” and “bad” was in terms of behavior, and in turn, what would be rewarded and what would be looked on askance. I hate to say it, but Americans aren’t great at this. There’s an inherent assumption that the American approach is better, without any consideration for the other side of the equation. Try to be aware of that and try to combat it in yourself and in your direct reports (see commentary below about hidden biases).

Here’s a platform diagram for the techies among you:


2.5 Beware of hidden biases

This is an ugly topic, but you’ve got to be aware of it. Turns out, lots of people are still mildly racist (shocking right?). They may not say it explicitly, but it’s really common for execs in Western markets to look down on their offshore colleagues, and treat them poorly. This manifests in all sorts of subtle and not-so-subtle ways.

Respect lacking: I constantly had to push my onshore employees to respect the work of the offshore teams. Some were outright hostile. Many of them looked down on their foreign colleagues. Some were silly enough to gripe out loud to me that the work of our Ukrainian engineers was crap because it wasn’t done in the US (they were living in opposite-land… our Kiev teams were superior to our US team). Career limiting move that one.

C-suite: At the executive level, the bias was better hidden. Not many execs make it to the C-suite by being openly bigoted. Nevertheless, there was a clear bias against the offshore teams among some of my execs. This manifested in statements like “you can’t trust that data!”, or “India can’t do collections!”, or “we can’t let Team 5 work on this, this is actually important code!”. This was all complete rubbish. Our Indian and Ukrainian teams were just as competent as our onshore teams at the things we asked them to do. Where they were weak, it was because we had made bad hiring decisions or under-resourced a function. It had nothing to do with where the resources were located.

Disguise: The problem here is that hidden bias is just that: hidden. You’ve got to dig to find it. How? Listen to how folks interact with their offshore counterparts. Listen to how they talk about their offshore counterparts behind their back. Pay attention to whether your team naturally thinks about giving a project/task/responsibility to the offshore team or if their reflexive reaction is to do it onshore.

Timezone imperialism: Setting up meetings is a basic activity that is constantly a source of problems when working with offshore teams. Whilst setting meetings at inconvenient hours isn’t done with malice by onshore team members, it is a great example of blithely ignoring the cultural divides. I don’t know how many times I would hear one of my guys/gals reply to a request with “Um… that’s 11 pm for us… could we maybe do it earlier?”. It’s not so much just that you’ve suggested an inconvenient time; it’s that you didn’t think about it beforehand. An easy solution is to make everyone aware of “shared time”. I.e. the big chunks of the calendar that are convenient for both geos. Scheduling issues are bigger than they seem. It’s inconsiderate, sure. But how can you develop buy-in from people who are treated as secondary employees? They certainly won’t feel on equal footing. Such inconsideration makes people feel like outsiders — a poison that will spread quickly and weaken the organization from within. One of the key responsibilities of leadership is to serve the team — do what you can to make them more successful. Their success is critical to your own. You can’t do that without making people feel part of the mothership and equally tied to the mission.

Legislation: Solving hidden bias is hard. You can’t really hire for it; if you only hire team members with deep offshore experience you won’t hire many team members. You can however legislate against it. In my company I had a rule that for any initiative that an exec pitched me that needed resources, they had to justify to me why it shouldn’t be done in Ukraine or India. They didn’t like this… but tough biscuits; companies are not democracies (I was a democratic CEO by and large but this was something I had to be a hardass about).

Flip the lid: By flipping the equation and starting with the assumption that something would be done offshore, and they had to justify having it onshore, I got better results. If you’re a CEO you can make calls like that; if you’re an exec at someone else’s company it’s harder, but you can still simulate this approach. I.e. if someone is presenting you with a business plan or a budget request, just ask them “can we do this offshore cheaper without sacrificing the key bits?”.

Hold-outs happen: Despite the fact that I legislated an offshore-first approach, there were still hold-outs. I had highly paid execs with great technology pedigrees continue to amaze me with their short-sightedness on this topic. These were men and women who I consider generally enlightened but had a real blind spot when it came to using offshore teams. They often weren’t even aware of their bias. Having employed 20+ senior execs over 15 years across two companies in the US, as well as working with ~1,000 channel partners across North America and a bunch of strategic partners in the heart of Silicon Valley, my observation is that bias against offshore resources is strong and is the norm, not the exception. It’s worse in the red states for obvious reasons. But it’s alive-and-well in liberal California too.

2.6 Over-invest in local HR Given the last two points I’ve made, this one shouldn’t come as a surprise. I think the first and best investment you can make is in an HR capability that is in-market in your target geography. Don’t try to do your HR from afar, and don’t use 3rd party consultants (see my diatribe about ownership).

Recruiters rock: At my company, we hired an office manager who previously owned her own recruiting business and man-oh-man did that have powerful knock-on effects. This was serendipity not strategy, but the lesson took. Given that offshoring is all about people, I guess it should have been an obvious move to make, but it wasn’t obvious to me at the time. The power of having our own professional recruiter in-house was tremendous. She had the market wired and knew how to hunt down any sort of skill set that we wanted to bring into the team either contract or perm. She kept her finger on the pulse of the team and got ahead of issues before they became obvious to even the local managers (let alone those of us ensconced far away in our LA offices). We had a similarly great HR function in our Indian offices. We ended up with multiple HR professionals in both of the markets we were in and that was money well spent. This is what I mean by “over” invest: if you think you don’t need an HR resource at all, increment the value. If you think you need 1, increment again. HR++ if you’re a coder.

Your HR leader will probably be the second hire you make not the first, coming after you hire a country manager, but I think it’s just as important. If you think there’s going to be a delay between establishing your operations and being able to bring in a full-time HR professional, then make sure the country manager you hire has good HR chops.

1st hires: In the early days of an offshore operation, it’s all about acquiring the best talent that your brand and budget will allow you to attract. The impact of your early hires will reverberate down through time and have a huge impact long after the decisions are made. It’s like compound interest on crack. How is this any different than the importance of hiring people onshore you ask? Well, the negative impacts of hiring B players are magnified by distance, and subtle (and not so subtle) deficiencies can easily go undetected by managers sitting in your home market for a lot longer than they would be tolerated in on-shore team members. Having a great HR professional on the team is also going to help you with the cultural issues referenced herein. Big time. Given that the highest order consideration early on is talent acquisition, I’d lean towards getting someone with a recruitment background in as your HR leader rather than a HR generalist. Your country manager is going to be doing a lot of the heavy lifting on the cultural stuff anyway, so you can trade off a bit there in favor of getting yourself a great finder and buyer of talent.

2.7 Trust is everything — your country manager is make-or-break

I’ve had four country managers: two great and two seemingly great. The two great ones became personal friends of mine (like… they were at my wedding). The two seemingly great ones cost me a lot of money.

The country manager that you put in place is the CEO of your operation, whether they’ve got that title or not. They need the same skill sets. But usually, you’re not going to be actually hiring someone into the position that has experience as a CEO. If you are, that’s terrific, but it’s rare. So in most cases, you’re hiring someone with the same skills as a CEO that have the ability to operate like a CEO, but who hasn’t done it before and won’t have held that title.

Shopping list: Things I would prioritize in your country manager are:

  • Proven track record in hiring within the relevant domain (e.g. developers, sales reps, etc);

  • Strong discipline around firing;

  • Understands the legal/regulatory landscape of your offshore market (not common in engineers);

  • Really high EQ;

  • Decent IQ and hard skills related to software dev or the domain you’re tackling (e.g. sales);

  • Can create and operate according to a budget;

Test for evidence of these things when you’re recruiting.

When I say trust is everything, I’m highlighting the fact that you are giving this person a huge responsibility. They’re going to be the single biggest determinant of whether your endeavor succeeds or fails, and unlike an on-shore team leader you can’t monitor them closely, and you can’t swap them out easily if there are issues. Nor can you parachute in yourself and take over if that’s what’s called for.

2.8 Trust but verify A mate of mine uses this expression all the time in his marketing domain, and it applies 10x in offshoring.

Corruption: Unfortunately, in the markets that are common destinations for offshore teams (India, Eastern Europe, Central and Southern America, Southeast Asia) corruption is common and rule-of-law is weaker than it is in North America and Western Europe. This can have real-life consequences for you and can be a pretty alien concept if you’ve only worked in developed-world markets.

My experience with this was ugly. I had a country manager who was stealing from me, and it took me a long time to find out. He had set up shell companies to provide services to my offshore operation. Those companies were being paid for services that weren’t performed at all, or where services were actually delivered, they were crap and marked up exorbitantly. What’s the lesson here? Trust but verify.

The simplest approach to this is: 1) hire an external auditor to review the books at least annually; 2) hire an external law firm to do all the legal work. Make sure you find and hire those service providers yourself and don’t just rely on your country manager to do it. This isn’t going to guarantee you won’t get stung by shady operators, but it’s going to: 1) increase the chances you’ll catch dodgy behavior; and 2) dissuade the would-be shamster from behaving badly in the first place.

That's all for this part of the series. Thanks for reading. The next part of the series will stay with the People & Culture theme and will tackle Recruiting & Teamwork. Stay tuned.

Cheers,

Ken


About me: I’m a software engineer by training and a software leader by profession. I’ve led two SaaS companies as CEO. I’m passionate about product & believe product management is the highest leverage activity a CEO can participate in. I’m here on Medium writing mostly long-form posts on topics I’ve got experience in, mainly #SaaS, #Product, #Startups, #Offshoring. Thanks for reading!

25 views0 comments
bottom of page