Why I won’t touch a company that doesn’t have in-house development
The headline might sound like a bit of an exaggeration but in the last 8 years of my life working on and with startups, I’ve found plenty of examples why fully outsourced IT has failed but no good example of when it has worked out as planned. Sure, there will be bias in my analysis but, ceteris paribus, it is a recipe for disaster.
I’m not going to preach or try to give logically reasoned arguments. I like to tell stories so that is the approach I am going to take. I may fudge details slightly to hide identities but I have first hand experience with the anecdote below.
Hear me out:
First Story:
I was looking at a company for a potential investment and we all agreed that the market was sufficiently large and that it appeared, at least on the surface, that the company had a minimum viable product. They had some people with domain expertise which to us, seemed like a critical factor. So far, so good.
Then they drop a bombshell. “We have outsourced our software development.” Let me see – they are selling a software product and do not actually engineer it. But it gets better. “We don’t currently own the exclusive rights to the code.” Okay, now, not only has this company invested time and money in to developing the software, they don’t explicitly own it.
It is true that the work-for-hire principles will provide them some protection but they are missing one key element – EXCLUSIVE rights to it. In other words, they are fucked. Based on their contract, the development firm has as many rights to use the code as the company we were looking at. The development firm can rebrand the product, use the same code base, and sell a competing product.
To make matters worse – the development firm was “negotiating” with the company that we were looking at for the exclusive rights to the code. You don’t need to do a Porter’s Five Forces analysis to see who has the upper hand here.
PASS
Second Story
This event takes place a few years before story one but this happened to me. I was developing an advertising platform (Rovrr) and we did not have the funds to hire an in house developer. We did not have the sex appeal of Facebook so we couldn’t attract developers that way.
After much debate, we decided to go with a software firm that would end up taking an equity stake in our company in addition to cash payment as we received funding. We though that the equity stake would align our interests and ensure that the software firm would be working with us.
Again, big fucking mistake. The abridged version is that as we were raising funds, the software firm was worried that we would dilute them and they weren’t happy with our payments to date. They knew the risks of the venture and yet they wanted an investment with a low Beta and a high return. It doesn’t work like that.
So what did this firm do? They held our code hostage. That’s right. They locked us out of Subversion and threatened to take our servers offline. I personally walked over to the firm unannounced and convinced the moron in charge that turning off the hosting was a bad idea. That solved the immediate problem but the long term problem was that they were asserting ownership over the code.
Believe it or not, VCs are somewhat risk averse. They want to minimize risk as much as possible and a company where ownership of the intellectual property and assets are disputed is, not shockingly, unattractive.
The development firm’s halted our institutional funding and eventually killed the company.
Final Story
I was working at a company where the substantial portion of the IT was outsourced and no one was ever happy with the work we received. The majority of my time was spend overseeing and reviewing their work and creating painfully explicit documents with pixel-level precision to prevent any unintended interpretation of my instructions.
I used still screen captures, screen recordings, videos, audio notes, thick decks with notes and diagrams on every page. I tried writing out long Word documents explain what we were doing. I had nightly phone calls with the developers to make sure that they were on track. And in the end – things still weren’t right.
This wasn’t specific to any one firm; it happened with everyone we hired. It was a huge waste of time and, sadly, on two occasions we decided to kill projects instead of finishing them because of the cost overruns. The budgets were always exceeded because the developers never got anything right the first, second…. or thirtieth time. They kept accruing billable hours and taking their sweet time.
We tried mitigating the issue by instituting milestones and checkpoints. We would review the developers work with the head of the firm and still, the problems kept happening. We could never (with any firm) get a fixed price per project to mitigate our risk and even with the signoff procedures in place, things still look longer than we could afford. Launching a product a year late is not a great start to any business or new product.
Epilogue
Outsourced developers serve a purpose and not all teams are equal. Some are intuitive and produce great work the first time. Other firms need 500 revisions to get anything usable.
The problem stems from misaligned incentives. When you have someone who gets paid by the hour – you are paying them to make mistakes and paying them to fix this mistakes they created. There isn’t the same level of accountability that there is with internal employees.
I want to clarify that this is NOT a rant against developers. It is about misaligned incentives. For brevity I omitted many of the things that I tried to do to address problems. I have had positive relationships with some development firms but by central argument that a firm should not wholly depend on third party developers still stands.
Lastly, if you do outsource your IT, you – and no one else – must own and control the software version control and the hosting. You don’t want to be taken hostage so don’t give anyone else that power.
[...] Read Part 1 [...]