Part IV — Outsourcing

Common Pitfalls

Part IV in my series on Advice for Non-Technical Founders

In this article, we will define outsourcing as software development outsourcing. If you are building a physical product, you’ll have an entirely different set of outsourcing challenges, but for now, let’s think about outsourcing as it relates to computer code and app development.

Journalism should strive to be objective while advice columns are, by definition, biased. So let me preface this part by acknowledging that I will generally lean against outsourcing technical development for startups. There are exceptions, which I’ll discuss later, and there are ways to do it right regardless. I also hope readers will share positive and negative experiences with outsourcing and offer advice to the rest of the community. If you had a good experience, share it, tell us what you did to make it work. If you had a poor experience, let us know what you could have done differently.

When done properly, for the right reasons and with the right support, outsourcing software development is a great way to scale your team’s knowledge and throughput. But how do we make that happen? What can we avoid?

There are 3 common pitfalls when outsourcing software and technical development:

1. Scope creep which leads to cost and time overruns
2. Loss of control which leads to security or IP risks
3. Low-quality code or over-engineered code (paradoxically this it true) which inhibits growth.

Even though I’m usually against outsourcing for startups, these pitfalls are often not the fault of the outsourcing firm, typically these pitfalls are caused by the startup. The good news is that they can be easily avoided. Let’s go through each pitfall and then I’ll offer what I call the Six Rules for Outsourcing.

Scope Creep

Score Creep happens in all software projects, but it’s much more common and costly when it happens via an outsourced relationship. There are 2 reasons for this:

1. The startup has trouble documenting and conveying scope at this early stage. Things change quickly and it becomes very difficult, if not impossible, to keep the outsourced team appraised. Don’t blame your outsourcing partner when your startup evolves and changes, this is natural, but your decision to outsource will make it harder to convey changes and control costs. An outsourced software development team creates several additional layers of communication. Different people, different offices, different countries, and additional management all act as barriers to effective communication.
2. Compensation for time and materials encourages the outsourcing firm to expand the scope. I’m not going to go as far as to say this is flat out fraud (though certainly less reputable firms milk billable hours), but this is how they make money and finding more work is what they are in business for. Solid dev shops help the startup refine the scope and strive to deliver on time and on budget, but often times they don’t. The outsourcing firm should take the blame for this one and consider fixed bids and incremental delivery of work product as a method to mitigate cost overruns and build trust.

Loss of Control

This one should scare you. It scares me and I try to scare startups who don’t get this. Securing the legal rights to your code is somewhat obvious, but many startups are still lacking in NDA’s and work product agreements with vendors, but what is more common, and more worrisome, is the lack of physical possession and control of the code base. Do you know where your code is? Who has access to it? How to compile it? How to deploy it? Or are you at the mercy of a 3rd party?

This is particularly relevant for entrepreneurs creating a product in a highly regulated or secure industry like FinTech or Healthcare. Outsourcing the development of your core IP is inadvisable in these industries, but if you are, you must assume full control of your code, the data, and secure the rights to ownership of the end product. If not done correctly and with rigor, this will be a major red flag for investors and acquirers.

Code Quality

Most code suffers from sausage making syndrome. Even the best programmers make sausage and, if it tastes good, you really don’t want to know how it is made. The key here is that someone on your team needs to know how the sausage is made. In an outsourced relationship, you often end up inheriting or supporting a codebase you didn’t make. This can become very problematic for the long-term viability of your product. A common scenario occurs when it comes time to insource the codebase. Your team is now accountable for someone else’s mess and this will cause friction on your team for the lifespan of your product.

Your team will never take accountability for bugs, scalability, and maintainability of code they inherited. It will be a source of resentment and, what’s worse, it is impossible to take pride in inherited sausage. Every software developer I know has said the following: “I don’t know what happened, I didn’t write it, this code is a piece of shit.” ← No one says this about their own code.

Paradoxically, the exact opposite of low quality code is outsourced code that is over-engineered and over-designed. This comes from a lack of experience working with startups. Firms that do a lot of work for corporations and have made a business supporting larger Fortune 500 companies will take a solid approach to software development albeit an approach not suited for startups.

The good news here is that these 3 pitfalls can be avoided if you have a technical lead running point on your team. We covered tech leads in Part II and since so many companies outsource software development it is imperative that you have secured a technical lead before you make the decision to outsource.

If I were teaching this as a course, I would make all entrepreneurs sign the The Six Rules for Outsourcing:

1. I will not outsource without first securing a technical lead.
2. I will not outsource highly sensitive or secure data.
3. I will not outsource core IP.
4. I will own my companies code and keep it safe and secure.
5. I will only use reputable software development shops.
6. I will immediately insource technical leadership of any outsourced software that I’ve inherited, purchased, or acquired.

Let’s briefly examine #6. Immediately insource inherited, acquired, or purchased software. Your job as a leader is to know what parts you have on the shelf, how they work, and will they last. If and when you find yourself in a position where a 3rd party created a product that you are selling, it is your responsibility to get that product under your technical leadership immediately. Get your tech lead familiar with the sausage making. The earlier the better.

People who have worked with me for any amount of time areaware of my love for analogies. So I’ll conclude with a home building analogy. Ask anyone who has built a home who is the most important person on the project. Is it the architect? The craftsmen? The banker? Nope. It’s the general contractor.

Your tech lead is your general contractor and they must be in place before you build a house. The labor can be outsourced, but the general contractor needs to be on your team, only then will the home get built properly.

Topic for a future post: Outsourcing vs. Offshoring. I didn’t have room to fit it in this article, but offshoring development opens up an entirely new set of pitfalls. I’ll try to get to this next week.

Again, if you have a good experience, let’s hear it! If you want to provide a warning or lessons learned, please leave it in the comments.

Cheers,

Mike