The “my startup’s software is too important to outsource” fallacy
A common objection for startups to outsourcing their software development is that “my software is too important to outsource”. I believe this to be a fallacy. Here’s why.
First, a disclaimer: at dzango tech accelerator where I work, we provide managed software outsourcing solutions, so I am admittedly biased. Nevertheless, in my 20 odd years in IT, I have been far longer a consumer of IT services than I’ve been a provider. Below are some lessons from the customer side of the fence.
Startups routinely outsource critical functions, either through lack of capital, lack of expertise, or both. As an example, I know a startup that provides a marketplace for food producers and restaurants. Early on, they decided deliveries was too important to be left to individual producers and had to be under their control. Yet they didn’t build a warehouse, buy trucks and hire drivers. Instead, they outsourced their operations to an expert logistics outfit.
Like logistics, managing a software project and development team requires specialised skills. Like logistics, it’s not rocket science, but you need to know what you are doing, and you get better at it with experience.
If you don’t have these skills and cannot afford a CTO, having your team in-house won’t magically resolve things. In fact, it might make them worse: since in-house is more expensive, if you fail you’ll lose more.
If you do have these skills, outsourcing opens up a number of options with significant benefits for a cash-strapped startup. In a tight labour market, it broadens your talent pool. It’s generally cheaper, a lot more flexible, and with lower exit costs than direct hires.
I have seen many startups succeed with a non-tech founder, no CTO and an in-house team. In most cases it’s because they chanced upon an exceptional individual developer, who had outstanding maturity despite being relatively junior. But I’ve seen an equal number of cases where that exceptional developer was a freelancer!
The quoted statement implies that by outsourcing you lose control. If that’s the case you are doing it very badly (or you are not talking to the right providers). You likely have a misguided view of what outsourcing should be. I also suspect that this derives from a misguided view of how a software team/project should be managed. This means that you are likely to make the same mistakes with an in-house team.
I’ve seen 2 reasons why software projects fail in startups: First, too much control is delegated to the dev team, and you lose control. Second, not enough control is given to the dev team, which ends up being micro-managed by a non-tech person, with disastrous results. Finding the right balance is not a matter of where the team is located.
Another rationale sometimes put forward is that the dev team’s motivations should be aligned with the company’s success, ie via equity. In the case of a CTO and senior devs, this financial motivation is real, legitimate, and should be tapped. But it is disingenuous to claim that it can only be achieved through direct employment. Plenty of alternatives exist, and if you want to tie an external team’s reward to your company’s performance, there is nothing stopping you.
At lower seniority levels, the financial motivation is far less important, and for good reasons. Developers are motivated primarily by intellectual curiosity, and junior or not-so-senior developers should care first about learning the skills of their trade. To join a startup as the only dev, or in a very small team, with no technical leadership, all in a gamble on the startup’s success, is a terrible career move.
A related fallacy is that developers should be close to the users. Developers have very peculiar work rhythms. They need frequent periods of utmost concentration, when they should not be disturbed. Seating the devs among end-users creates far too many temptations for the latter to disturb the devs. In fact, most dev teams quickly end up relegated to a separate room or floor. Devs also lack the skills required to engage in a meaningful (professional) discussion with end-users. The skills required are those of an analyst. Analysts should indeed remain close to end-users. You may occasionnally find a developer who happens also to be a good analyst. So by all means employ him as a part-time analyst. But do reserve him a desk away from the users, among his peers, for his part-time as a developer.
Ultimately, if software is important to your startup, you owe it to yourself — and to your stakeholders — to do it right. This includes accepting a realistic assessment of your skills in managing a software development team/project and evaluating all available options.
