outsourcing

Should Tech Startups Outsource Product Development?

Next Story

Daily Crunch: Decent Edition

When startups ask me whether they should outsource product development, I usually advise against it. If they’re desperate to save money, they should outsource some testing or ancillary-product development, not core products.  That’s because the developers of innovative technologies need to interact with each other and be close to customers and markets.  In my book, outsourcing is for corporate I.T. departments and for large companies with global operations, not for small tech companies.  I said this in my BusinessWeek column, three years ago.  I also cited research that showed that the tech industry has never constituted more than 15% of the outsourcing market (banking, finance, and insurance accounted for 40%; telecom, 17%; and manufacturing, 12%)—and this includes the product development that companies such as Microsoft, Adobe, and Cisco perform in their offshore locations.

When I wrote that BusinessWeek piece, Peter Harrison, CEO of outsourcing services provider GlobalLogic—who happens to be a good friend and someone I have mentored over the years—tore into me.  He insisted that I was wrong and offered to prove it by introducing me to his customers.  I ignored him (as I often do).  But Peter is persistent.  Last week, he roped me into his customer conference to have dinner with Mike Moritz of Sequoia Capital, who is a GlobalLogic investor.  Peter also had me meet some of his customers.

I wasn’t surprised at how bullish Moritz was on GlobalLogic and outsourcing. VCs always hype their investments and are known to put pressure on their portfolio companies to reduce development costs through outsourcing.  But I was a little surprised to hear small Valley firms rave about the productivity and cost savings they were achieving by doing R&D in places like Kiev, in the Ukraine, and Bangalore, India.  And I was very surprised to learn how rapidly GlobalLogic was growing despite the dismal economy. The company employs 3000 software developers world wide and has just received a mezzanine investment from a top investment bank (which usually means that the company is one step away from an IPO).

Despite this, I remain unconvinced that outsourcing core development is a good strategy for startups.  During my tech days, I outsourced R&D to St. Petersburg and Novosibirsk, Russia.  But as you can read in this FastCompany article, my technology was conceived there, and that’s where my entire development team was located (and I was able to hire brilliant ex-KGB mathematicians who had skills I couldn’t find anywhere else). Having development teams working on a single product but being in different locations makes innovation much harder to achieve (yes, I know this is how open source works, but that’s different).  I’m going to detail my reasons and let GlobalLogic CTO, Jim Walsh, tell us all why he thinks I’m wrong.

Here are the reasons I’ve cited for outsourcing not making sense:

1) Communications and customer needs. Developing a product requires a deep understanding of customer needs, and extensive user interaction.  Locating R&D personnel away from customers limits the ability to develop innovative products that meet market needs.

2) Components must fit together. Complex software is more like a Swiss Army knife than a meat cleaver.  The blade, bottle opener, and screwdriver have to work in an elegant manner and can’t be developed independently.  In a similar way, members of a software-development team need to work closely together.

3) Management bandwidth. It is a lot more challenging to manage diverse teams at multiple locations and in different time zones than to manage them together.  Additional layers of management are often required.

4) Fewer developers can often produce more. In the tech world, scaling up development teams doesn’t always lead to greater productivity.  Small teams are often the most innovative and productive.

5) Skills scarcity. The specialized skill and mindset that tech companies look for are hard to find.  For example, India doesn’t have programmers who have grown up to understand the intricacies of computer-game development, because few can afford the high-speed Internet connections needed.  In India, the best developers gravitate to prestigious companies like Infosys and Wipro, not to small startups.

6) Intellectual-property protection. This is a particularly strong concern in China, where it is almost impossible to protect trade secrets and where piracy is rampant.  Employees often leave to start ventures that compete directly with their foreign employers, and the laws provide little protection, because they aren’t enforced.

Here is Jim Walsh’s response.  I must warn you that this may read like an ad for his company, but I need to be fair, because I’ve just trashed GlobalLogic’s entire business model.  So take this for what it’s worth:

If  by “outsource” you mean throwing stuff over the wall to a third party, then I’d never advocate this for core development. If, on the other hand, you mean collaborating with a firm that possess specialized skills that you lack, are hard to find or very expensive and aligning your goals around a common outcome, then clearly I’m a fan. Firms that fail at globalizing R&D do so because they either because they pick the wrong partner (i.e., one that lacks the R&D DNA and does not specialize in the firm’s domain) or because they throw stuff over the wall and don’t invest in the intimate collaboration and goal alignment that true R&D requires. Most IT services firms make poor product development partners because they focus on compliance and optimization, which suppresses innovation. By contrast, GlobalLogic has created a network of global innovation hubs that are made up of some of the brightest and most innovative software minds. Our software professionals are connected by a platform that supports Agile collaboration and that is designed exclusively for the purpose of accelerating breakthrough products to market. We are doing this successfully for a “who’s who” of the technology sector, from the very tiny to the very large. That said, let me respond to each of your points in turn.

1) Communication: I completely agree that building great products calls for a deep understanding of customer needs and great communication.  We believe in creating small agile teams where the product owner is an integral member.  If this team is distributed, then it’s essential that you either (a) separate the scrums and have product owners in each location or (b) have the product owner overlap with the engineering team for several hours every day to review deliverables and provide constant feedback.  Although in the old days this was hard to do, modern communication and development platforms have made collaborating across distance easier.  In some cases, they can improve the quality of communication over co-located teams.

2) Integration: While building tightly integrated products with distributed team members might have been hard in the past, modern development tools and architectures have made it increasingly straightforward for even the most complex products to be built by distributed teams.  Most open-source projects are living proof of this progression.

3) Management: Managers who have distributed teams do need to learn new skills; however, once proficient, a manager with a distributed team can often outperform a centralized one. Take for example the opportunity to follow the sun by developing during the day and testing the same code line at night (i.e., daytime in a second location).  Or consider the opportunity to leverage specialized skills that you simply don’t have in one place or to have a larger or more skilled team than one could assemble otherwise.  If you’re struggling to overlap enough hours a day, one can always leverage teams in Latin America that work in US time zones.

4) Talent: I’m well aware that one great developer can often outperform many mediocre ones. That’s why I’d never compromise on the quality of team members – particularly for new product development. However, it’s possible today to get developers in Argentina, China, Eastern Europe and India (i.e., locations where we have innovation hubs) who are just as talented—and in some cases just as experienced and innovative—as those in Silicon Valley.  The key is to set your bar high and hand-pick your team in the same way that you would if you were doing the development right here at home.

5) Skills: While there was a time when specialized skills were hard to find abroad, this is simply no longer the case.  When I started in this industry 25 years ago, the skills in the U.K. were about 10 years behind those of the U.S.  Today, there is no longer any skill lag.  Indeed, it’s possible to get skills in cities like Bangalore and Kiev that are in advance of what you can find in many U.S. cities.

6) Intellectual Property: For all but a handful of products, IP risk is a red herring thrown out by firms to defend the status quo.  In our history of building more than 1000 products for more than 200 product companies, we’ve never had an incident of IP theft.  There is simply too much at stake for our firm and our employees for this to be a meaningful risk.  Finally, many firms have concluded that the only true defense for their IP is moving faster than the competition, and we can certainly help them do that.

Lastly, we would argue that the day has come when even a startup needs to think globally (i.e., become a micro-multinational) and seize the opportunity to create products that can be used around the world.  Therefore, it’s not enough to focus only on what American consumers want.  Having a global team is a great way to ensure that you’re creating a product that can address global needs.

The last part, on globalization, is exactly what Mike Moritz said in his talk.  I agree with this.  But Jim hasn’t convinced me about the other issues.  It could be, though, that things have changed from the time when I was a CTO and CEO, and that my information is dated.  So I look forward to reading your comments on what has and what hasn’t worked for you, and what you think about this topic.

Editor’s note: Guest writer Vivek Wadhwa is an entrepreneur turned academic. He is a Visiting Scholar at UC-Berkeley, Senior Research Associate at Harvard Law School and Director of Research at the Center for Entrepreneurship and Research Commercialization at Duke University. Follow him on Twitter at @vwadhwa.

blog comments powered by Disqus