I have already touched recently on the topic of outsourcing software development for new, innovative products. My experience tells me that many companies do that and reap all the benefits, though at the same time, many, especially start-ups, are cautious in following this path. And I can understand the reasons: You worry about how having the knowledge about the product concentrated primarily on the provider’s side could affect your exit strategy and investors’ trust. Besides, you don’t hear much about success cases—it’s almost always under strict NDAs, probably for exactly the same reason: Nobody sees outsourcing as a factor that increases the value of a company, and so most prefer to keep it under wraps, away from the press and analysts.
I wish that at some point outsourcing would be seen as a value-adding factor. After all, your provider usually gives you a team with a proven track record, a sound methodology, technological advice, and experience in building and managing engineering teams. Isn’t that the investor’s paradise? Needing to worry only about how good the idea is, not how good the (software engineering part of the) execution will be? There are always risks, but there are ways to deal with them, if you know what you’re doing. Below, I’ll try to give some advice on what to keep in mind when considering outsourcing work on innovative software and hardware products.
Selecting the Right Service
One should never confuse outsourcing with outstaffing, especially when dealing with building remote teams. Outstaffing brings you individual engineers, and it’s up to you to give them guidance on all aspects of their work: from processes and day-to-day office management to technologies and tools to use. Especially in new software development, communications between all members of the team is an integral and essential part of the software development process. The current trend toward agile and constant micro-communications inside the team is for a reason. But, as I’m sure you are well aware, software developers as a group were never known for their excellent intrapersonal skills.
You have probably picked the engineer for his/her experience with a specific technology and business domain, and the team leader likely built his career by demonstrating excellent software design skills, not necessarily mentorship abilities or a deep knowledge of psychology. Do you really want that team leader to remotely micro-manage the work of that engineer? Throw in the time zone difference and the fact that English is not the engineer’s first language. Do you see them easily clicking in working on the same project?
Does that mean that remote outsourcing is not compatible with new software development? Not necessarily. But you’d have to use remote outsourcing instead of remote outstaffing. The reason is that rather than dealing with a bunch of individuals, you’d be dealing with an organization that provides resources and skills to establish that strong connection at the team level. That also means you can’t efficiently micro-manage a remote team—and I’ve already provided my thoughts on that subject.
And that also means that you’d have to compartmentalize to a certain degree. Your in-house team (if you have one) and the remote teams should work on the parts of the projects that don’t intersect to the extent that they require constant real-time communications. That doesn’t mean a distributed team can’t work on the same product or the same project. However, if, for example, your production process is organized in such a way that a small change made by an engineer (say, modifying a database structure) can seriously affect the work of other team members, but you don’t have a mechanism to track those changes, map them to the author (and the reason), and rollback and reapply them as necessary, you’d better keep your remote team on some peripheral work that is less likely to depend on those changes. So, ideally, you should have some boundaries inside the product source code that your in-house and remote teams rarely cross.
Picking the Right Time
Those specifics of the outsourcing service naturally determine the times when it makes more sense to consider outsourcing. Some do it from day one, and it’s not a bad time if you can afford outsourcing from the start. In fact, we have clients for whom we, a service provider, are the only software engineering force in their company or working on a specific product family. They can have their own product management or hardware engineering force, but at least for software engineering, the compartmentalization is not an issue: All that work is done on the provider’s side. In those cases, the key outsourcing value is the ability to jump-start the new initiative quickly: Get the team of seasoned professionals, use the right methodology, etc. That’s especially useful for those who have deep expertise in the business domain but not necessarily in software development.
Another good moment is when your initiative is mature enough that it requires you to quickly add resources to scale up. This is the moment when outsourcing is one of the few viable options to sustain growth: Growing the internal team is often too complex, takes too long, and sometimes doesn’t have business sense (when the future workload in a specific technology is unpredictable). Usually, at this point, it is already possible to break the product/project into components and assign some of them to the remote team and some to the in-house team.
Using the Right Model
My last piece of advice is less important in my mind, but you should be aware that there is a family of models that further decreases the dependency on the provider. I’m talking about Build-Operate-Transfer (BOT). The provider is tasked to build an engineering team, operate it for some time, and then transfer it to the client on request. Typically, there is a one-time price for executing the ‘T’ (Transfer) part that decreases with time to guarantee that the provider is compensated for the initial investment in absorbing the costs of starting up the new team.
In reality, the clients don’t hurry with executing the ‘T’ option. Usually, the provider can do a better job of efficiently managing and optimizing the costs of keeping an engineering team, and the clients just don’t need all the headaches associated with maintaining a remote captive center. Still, using this model may make the whole enterprise look more stable—you always have the option of bringing all the knowledge that the engineering team accumulates into your organization—so some companies follow the BOT path.
In conclusion, I want to reiterate that outsourcing highly innovative software development is possible and often beneficial. What’s more, many successful companies, from big to small, already do it. But, as in every business, you need to understand your needs and know the best practices in addressing them to be successful.
