Distributed teams and outsourced developers
I am consistently asked how I view distributed teams and outsourced developers. Unfortunately, there’s no clear answer. It works in some cases, and may be a massive detriment in others. I’ll try to lay out some of the pros and cons so that you can make your own informed decision as to what’s best for your company.
I think it’s important to start by debunking a common myth: that a distributed team will hurt when you’re looking at an acquisition. If you’ve got a killer business, there will be acquisition interest at the right point, regardless of your team’s geography. The only time that geography could hurt is in an aquihire situation. The days of Google paying 7 figures for a few talented developers, however, seems to have passed, so meaningful aquihires are few and far between, not frequent enough for you to worry about when building your team.
There are reasons not to build a distributed team — for sure. It’s harder to build the right culture and morale when everyone’s not “in the trenches” together. At a startup, you usually only have your culture and energy as recruiting tools, and without those, you’re at a disadvantage from a talent attraction and retention standpoint. Additionally, it takes a very specific type of person to have the discipline to work remotely. If you hire remote employers without the right work ethic, you risk having dramatically lower productivity.
On the flip side, there are two major benefits that can accrue from building a distributed or remote team. The biggest benefit is the ability to recruit top talent. Regardless of location (yes even in the Bay Area), it’s hard to find the right talent in the right quantity for your startup in a specific market. By hiring remotely, a company can find the best talent for the job without limiting based on a specific geography. The second advantage is cost. Even within the US, cost of living varies greatly throughout the country, as does the wage rate for the same job. So if your company can function well with a distributed team, you could recruit from a more talented, larger pool with a lower cost structure.
One final note on offshoring. Offshoring development is often a strong siren song — far more cost effective than developing in-house. But it’s not as much of a no brainer as it may seem. Offshoring has two disadvantages. Your company loses a key edge in ability to innovate product — it becomes something anyone could build. If your tech isn’t your advantage (it’s your execution or business model) this may be fine — but for companies with novel tech, outsourced development shops simply can’t create proprietary products the way you can in house. Secondly, while the cost would be lower, the product is often not exactly as you envision. Since it’s not your team building to a common vision, there’s a much greater “lost in translation” factor (and I don’t mean on the basis of language) that requires rework and cause deadlines to slip. While the cost saving is extreme and those who hit on it really benefit, offshoring development tends to cause more difficulty than benefit, from the experiences I’ve seen.