The preface to Karl Popper’s The Logic of Scientific Discovery has a very simple framework for thinking about knowledge. “The problem of epistemology may be approached from two sides: (1) as the problem of ordinary or common-sense knowledge, or (2) as the problem of scientific knowledge.” My summary of Popper’s distinction is that common-sense knowledge is knowledge that already exists (though it may not be universally or even widely known). Scientific knowledge is about the growth of knowledge — that is, the creation of new knowledge. Here is a link to the actual text.
It is important to understand the difference, as it is my belief that understanding the difference between “common-sense knowledge” and “scientific knowledge” holds the key to knowing whether or not to offshore.
A few years ago, everyone in Silicon Valley decided that every startup had to have an offshore strategy. Lower labor costs and an infinite labor pool in India, China, Russia, and elsewhere in Eastern Europe had joined forces with open source software to turn engineering into a commodity, the conventional wisdom held (and still holds in many quarters). “Take that overpaid Silicon Valley engineering talent,” said the bean counters. Whether you needed customer support or an agile team of algorithm black belts, offshoring was the answer.
Now people aren’t so sure.
So does offshoring make sense?
Back to our friend, Karl Popper. If you have a repetitive task which requires virtually no INNOVATION and which can operate relatively independently from other core groups, having that task separated geographically may work. In Popper’s terminology, common-sense knowledge projects are a natural fit for distributed work (offshoring, outsourcing, open source software). For example, if you decide that you want to have all support manuals scanned and uploaded into a system for universal access it may make sense to offshore that effort. Or if you have years to replicate an existing technology, having geographically distributed teams can work (e.g., many open source software projects are highly distributed).
However, if the focus of the function which you are thinking about offshoring requires the creation of new knowledge — scientific knowledge — you would be well served collocating all professionals and teams required to accomplish your objective. For example, having a management team, product management team, and your engineering architects in the US and offshoring coding work (to, let’s say India) is a very bad idea.
Innovation requires limited latency — anything that introduces latency decreases the probability of success. Offshoring introduces massive latency. And so do large teams, which often accompany offshoring because it’s “cheap.” If you are doing anything that requires innovation, working with large offshore groups is far from cheap.
Please note that I am not arguing that innovation can’t exist in traditional offshore destinations like India, China, and Eastern Europe. Rather, I am arguing that a U.S.-based business that wants innovation and has an engineering team in India, should move product, design, and management to India or move engineering to the US. The key is for the innovation team to be together — where that is matters less than having people together.
Update: June 5, 2008 2:48 GMT
I removed the two references (with strike-through text above) to open source software and distributed work. It’s a red herring, out of place, and consequently takes away from the point of the post.
7 Comments
June 5, 2008 at 7:33 am
As is usually the case - the reality often lies in between the extreme examples given (scanning docs or producing scientific innovation).
Firstly, in defense of open source - I think apache web server, linux, emacs, perl, ruby, spam assassin, asterisk are just few of the projects where innovation cannot be questioned. I was part of a similar set up in a commercial startup where we were 10 people spread over 7 cities in the world working round the clock, producing some pretty cool technology.
Secondly, the speed with which technology has moved has produced many cases where technology pieces are commoditized and the crux lies in business execution. So it makes sense for say a stop-loss SMS alert service on stocks to find an offshore dev partner. A young entrepreneur can then start with a lean team and focus on driving user base or roping in advertizers rather than be defocused in finding a tech co-founder, hiring a tech team - losing both time and money.
Frankly, I believe that this actually drops the cost of starting a new business. The case you have mentioned above I think makes sense for specialty cases like say designing the iPhone where I think co-location is the way.
June 5, 2008 at 12:35 pm
Totally agree. We’ve run teams in Russia (we’re in the States)… gave them the common sense stuff to do and in one case a very special piece of compression innovation. Apart from that keep the rest of the innovation team together. Ironically I’ve been with my current innovation parter for 12 years now - and we’ve only met 3 times. We’re separated by 1500 miles and yet with good communication we’ve achieved all of our goals. The key is execution, focus and lots of patience. Innovation (the complex stuff) doesn’t happen overnight.
Once it’s working - then find the best cost to production team you can and deliver great software to your customers.
June 5, 2008 at 2:59 pm
Excellent feedback Saurabh. I removed the references to open source as it was out of place. Open source software is great and I didn’t mean to belittle it or the efforts of those who create it.
My point is that latency is the enemy of innovation. Offshoring almost always adds significant latency to a project when the “management” is in one place and the “doers” are in another. Large teams are also the enemy of innovation — and the availability of “cheap” labor entices those who offshore to build large teams. So the result is time-based latency and large team based latency. Together these things increase the probability of failure if your project requires innovation. That was the crux of my point.
Peter, thanks for the comment. When you have a single partner and you know each other well, it makes sense to me that you can introduce space between the two of you and still be focused.
I’m sure that there are plenty of examples that prove me “wrong.” However, on a probability weighted basis, I would bet on a small collocated product/design/engineering/management team versus a “low-cost” US-based management with offshore-based engineering team nine times out of ten.
June 5, 2008 at 5:10 pm
Latency reduction and knowledge creation are key components of agile/lean development.
Latency is a type of waste — lean also identifies many other types of waste like extra movement and inventory.
June 6, 2008 at 6:00 am
Latency is just awful and should be avoided at all costs. I would only outsource the development of something that I already had well specified. It might also make sense to hire a separate team to check the first teams work.
June 10, 2008 at 8:02 pm
Latency is clearly bad. So what are the main causes of latency when it comes to offshoring?
Is it
- time zone differences (e.g. don’t get an answer back for 12 hours)
- cultural differences (though both sides usually speak a common language, but cultural differences can still be pronounced)
- physical separation (will telepresence ever replace being in the same room?)
- communication and organizational overhead (always hard to get stuff done with N people where N is large)
Maybe the lesson is that offshoring would be more effective if you reduced fixed as much of the above as possible. For example, hire a very small, super talented offshore team (e.g. instead of hiring guys at 1/10 the salary, hire foreign super-stars at 1/2 the salary), invest in uber-fancy Cisco Telepresence gear, outsource to the same timezone (e.g. if you’re in Boston, outsource to Costa Rica, instead of Bangalore), etc.
As a corollary, one may be able to gain some efficiency simply by better consolidating domestic operations so you get benefits of physical co-location, remove the coast-to-coast 3 hr time differences, etc.
June 23, 2008 at 6:03 pm
I completely agree. In fact, I think the idea you’ve presented here could be of far more general applicability.
The latest and greatest theories of why firms should integrate in legal academia don’t adequately account for the importance of “latency,” as you describe it.
Leave a Reply