Ramping up a high tech company in Silicon Valley requires nimbleness in decision-making and action that few in other industries can appreciate. That’s why we were looking forward to hearing advice from an MIT Club of Northern California panel of entrepreneurs about their experiences with outsourcing. After all, the general guidance says to take your time, put in a lot of planning, go through a careful RFP and vendor selection process, and so on. In start-up situations, time is rarely available, planning changes course by the day, and selecting a company that isn’t in your geographic location usually means holes in the information you need for a smooth selection process.
The discussion focused on product development, which also meant offshoring was a big part of the conversation. To cover the event, we sent entrepreneur, software engineer and some-time reporter Mark Streich.
As you’d expect, cost savings were the main motivation for outsourcing. In fact, Kelly Ireland, VP of engineering for Metreo, said in their case pressure actually came from the board of directors. Technical resources were limited in Palo Alto and offshoring would allow her company to shrink and grow as the business needs dictated.
Initially, in Metreo’s case, the service provider handled quality assurance. Going offshore, where labor was cheaper, meant the client could afford a higher ratio of QA people to engineers. Ms. Ireland had experience in offshoring QA, so she knew what to expect. She also knew it required good documentation and that her company could measure success in small projects with fixed-bid quotes. They put together a statement of work as part of initial negotiations. Now that the provider has proven itself, it’ll be building the next generation of the product.
Vineet Jain, VP of engineering for Valdero, cited scalability of personnel as a benefit as well. His company chose a provider in a “lower-tier” city in India. The result? Lower staff turnover (only three people in three years). Also, his company was a more important part of the provider’s business, which meant it received better service than if it were a small customer in a large provider’s client roster. However, he said, salaries are going up. Whereas the ratio started out at 4.5:1, now it’s closer to 2:1.
From the start, Valdero split development between in-house staff and provider staff. Were he to do it over, he’d start with internal staff then bring an outside provider in on the project. Since it was a true start-up, he doesn’t believe full specifications could be created for the whole product, since things change so rapidly.
Ted George, chief technology office for Blujacket and ForceField, said his company does the high-level architecture in the US and software development in India. He acknowledged that it means writing a lot of specifications. In his case, the architecture and product specifications were done here before the offshore team started. However, he found that while technical expenses went down, project management demands went up. He said to expect total costs for the project that is outsourced to be two times what you pay the service provider. However, it still paid off — in faster time to market for the product.
On the topic of specifications, Steve Mezak, CEO of Accelerance (a service provider itself), added that the specifications need to spell out how the product will be used and will need to define the user interface. What he advises against is providing specs to the level of the database schema. The reason: The engineers there are the same as here. They’ll want to do the “fun stuff.”
Ms. Ireland pointed out that offshoring required a “flex-time” philosophy in her company — so that people could work with teams in another time-zone. Also, Metreo grappled with the morale problems of having jobs move overseas. Her advice: Deal with it honestly. That meant explaining that both the company and the people needed to “move up the value chain.” In the end, she said, people who wanted to make it work did; those who didn’t want it to work ended up leaving.
She found the provider staff eager — like a group of junior engineers who were “excited not cynical.” That said, most of the offshore talent is “junior.” Finding somebody with even five years of experience is hard, which means you may find yourself setting up training that wouldn’t be necessary with more senior staff. In Bangalore, there’s high competition for talent and double-digit turnover, along with sharp wage spikes. In fact, for those reasons and because of the depreciating dollar, she eventually expects to see an end to the “labor arbitrage” Also, high turnover translates to lower quality. Plus, network bandwidth isn’t as good and is quite expensive. She’s seen obstacles to getting the hardware and source code controls set up. And there are challenges in making the remote team feel like a part of the whole team. The travel requirements — of bringing people to the US and sending them to India — added high travel expenses.
Mr. George said his firm assumed there would be communication problems, because of the time zone and language differences. But the single biggest issue was getting to know how well the offshore team worked together internally. There’s a lack of transparency in the team, he explained, which means you won’t find out about problems until later. Several panelists reiterated the need for short-term deliverables to avoid and overcome this problem. Also, because the India staff was more junior, they couldn’t understand the specifications.
Mr. Jain said he thought the biggest challenge would be finding the right skills. The reality: Offshore providers can be very hierarchical, regardless of skills. As our reporter paraphrased it: If the engineer is brilliant and the boss is an idiot, you still need to work through the boss. Another problem: The team would never report that something was late. Almost to the last day, he said, they would say the project was on time. This happened even with three-week projects. Nothing would be noted on the real progress of it until the last day. In other words, there’s no visibility into what’s really happening.
On the plus side, he pointed out, his company found “refreshing attitude and ethics.” Calling the “Valley” fat and happy and putting more stress on achieving a work-life balance, he said the India staff wanted to prove itself and did so by working hard. Eventually, his company rewarded their efforts by giving them more of the design work.
The topic of intellectual property came up, and a couple of the responses were surprising.
Mr. Jain said his company trusts in the relationship with the provider, but that he had the experience of the company sharing another client’s IP with him and not even thinking about it. Mr. Jain pointed out to them that they shouldn’t be revealing it.
Ms. Ireland believes in protecting “through obscurity.” The offshore team works on maintenance releases. The core stuff is still done here by using libraries that work with other parts of the system. Any tech “near and dear to our company” is kept in the US.
As her closing advice, she encouraged companies considering going offshore for its development work to hire management staff with experience specifically in doing that. Also, once the provider is selected, negotiate rate caps and have buyout options. Travel to the site and handpick the team members you’ll be working with.
Mr. Jain said to expect constant travel and to get used to constant work on the client side to ensure good interactions. A key, he said, was to treat the offshore staff as “equal employees” for both quality expectations and what work they’re given.
Mr. George suggested performing due diligence — right down to making sure your provider is compatible with your company and its business style. This requires face to face time. He said that someone at a previous company had come up with the term, “Half-life of trust.” That alluded, he explained, to how long the trust among separate teams lasts. While that big kick-off meeting may leave you feeling like everybody is on board, you may discover that three months later the separate groups don’t trust each other.
