What software development should you *not* outsource?

The answer is not what just jumped into your brain.

The other day, in an online group chat of software leaders, a topic came up that I can never leave alone. The question was about why some companies are against using outside help to write code or consult them on developing software.

Lots of people jumped into the discussion to answer. One person said they are skeptical of contract work because contractors are mercenaries for whom the grass is always greener at another (higher paying) gig. Another person said that the culture of some organizations includes something called “not invented here syndrome” which means they like to build everything themselves even when open source or commercial options are available.

We were well into the discussion, when someone wrote the sagely worded, tempered, canonical answer to this question. The common wisdom is that it’s “best to hire in-house for your core competencies and for the extraneous stuff, maybe you can outsource.”

I’ve heard this idea for 20 years. I’ve said this to people. If this is true, it would mean that your startup MVP should be developed by founders or employees. If your company is not a startup, it would also mean that you shouldn’t hire contractors to work on core systems. I’ve accepted it is as part of the bedrock. But why? Is it really true?

To understand why this is the common lore, lets first break it down and look at the arguments in favor.

---

Don’t stop reading here! This post will take an unexpected turn.

---

1. Greater control over the development process: When a company has its own employees working on its core competencies, it is able to dictate in fairly absolute terms how the work gets done, what computers are used, what hours are worked, where the work takes place, etc.

2. Improved communication and collaboration: When employees are in-house, it is often easier for them to communicate and collaborate with other team members. Managers can ensure that everyone is working towards the same goals and that the company is able to respond quickly to any challenges that may arise.

3. Increased flexibility: Having in-house employees who are responsible for core competencies can give a company more flexibility to adjust its resource allocation as needed. For example, if the company needs to ramp up development of a new product, it can easily reassign employees to work on that project.

4. Greater access to intellectual property: When a company has its own employees working on its core competencies, it has more control over the intellectual property that is generated. This can be especially important if the company is developing proprietary technology or if the core competencies are closely tied to the company's brand.

5. Enhanced security: In some cases, a company may have security concerns about sharing its core competencies with outside contractors. Having these employees in-house can help address these concerns and ensure that the company's critical information is kept secure.

This seems like a pretty solid list of reasons taken at face value. You can imagine a smart software manager with years of experience listing each one of them while counting them off on her fingers. And most people would be convinced.

---

Here’s where we take a sharp turn.

---

But let’s look at them again one at a time and figure out if there is anything substantive supporting them.

1. Greater control over the development process: I used to think that you can tell employees exactly how, when, and where to do their work and that you can’t do that to outsourced developers or firms. But this isn’t actually true. There’s no law that says you’re not allowed to control the manner and method of contractors’ work. There’s just a general tradition of not doing that.

   Before continuing I should give a quick nod to the fact that there’s a test called the “common law test” to determine whether workers should be classified as employees or contractors, and it includes the following factors to determine the level of control that a company has over the worker, including whether the company:

   1. Has the right to control how the work is done

   2. Provides training to the worker

   3. Requires the worker to follow specific procedures or processes

   4. Determines the order or sequence of the work

   This common law test is only one of the possible tests for making the employee or contractor determination, and it doesn’t really come into play when hiring an agency to do the work. It also wouldn’t come into play if a contractor specifically wants to be considered a contractor and has evidence (a contractor website, for example) that they prefer this type of working relationship.

   What I’m saying is that you can control the development process. Heck, you can even put specifics of how, when, and where the development should be done into a legally binding contract.

   I do think there’s one thing to consider that’s a little different between teams hired through a firm or agency and hiring individual contractors or employees. That is the ability to go into “hard core” mode as Elon Musk would say.

   Let’s say the business has decided that they need people to work 18 hour days 7 days a week, and they’re willing to take whatever risks that might entail to productivity and morale. If everyone has been individually hired (either as contractors or employees) then people who disagree with hard-core-mode might choose to resign. The manager might resign but leave the team to be managed by someone else, and a few of the individual team members might resign as well.

   However, if the team was hired from a firm as a unit, then the firm might refuse to go into hard-core-mode as a unit and look to exit the engagement entirely. Fortunately, this is probably not too much of a concern for most companies, because, as we have learned from Twitter, going into hard-core-mode is a horrible idea, and many people will leave (taking their institutional knowledge with them) no matter what their relationship to your company is.

   There’s one final little bit of nuance to consider on this development process point. If you’re hiring a team from a firm that has a long history of experience working together, then they’ll probably price their service in such a way as to bill for the value of that long experience. If you already have a development process at your company that is very effective at producing successful outcomes, and you want the outsourced team to use your proven process, the outsourced team will have to change from the way they are used to working to learn the new methods. You’ll be paying a premium price for that outsourced team because of the experience and development process they already use but won’t receive the benefit of it. For companies that already have a very effective development process, it’s probably better to hire individual contractors and in-house employees rather than an outsourced team.

2. Improved communication and collaboration: This is an easy one to refute. How do your employees already communicate with one another? Face-to-face in a building? On Slack channels and emails? What physical or process barriers does your company put in place that makes communicating with outside contractors or organizations different? I’m certain that all of those barriers are policies are not laws of government or physics. If you want to maximize your ability to work with an outsourced team, you just need to make it as easy for them to talk you your employees as it is for your employees to talk to each other. This doesn’t mean that you need to give a third party software development company access to the company directory. They just need to be able to easily communicate with people that are relevant to the project they’re working on.

   Communication barriers can just as easily be erected between in-house people. Your company’s Slack might have private channels for executives. There may be whole multi-billion dollar projects (VR at Apple?) that most employees don’t even know about.

   Bottom line, communication between outside developers and employees is only an issue if your company makes it an issue.

3. Increased flexibility: The idea—that you can move people around and have them work on different things as priorities change thus giving you more flexibility—seems true on the surface, but it isn’t actually true. The reason is that software developers aren’t fungible. I can’t think of many professions less easily replaceable than software developers other than, say, Hollywood actors in the middle of filming. Even a good surgeon could take over mid heart transplant for another, but software developers create a mental model of the code they’re working on that is very difficult and time consuming for another developer to come in and take over. There’s a significant cost involved in moving developers around. So, when you’re adding capacity to a project, it’s best if the you’re not taking that capacity away from another project. It doesn’t seem to matter whether the added capacity uses an employment relationship, and it’s probably easier and lower risk to add capacity through contractual relationships than with employee relationships. Removing capacity from a project is always difficult and may require difficult decisions about letting deep knowledge of the codebase go regardless of the type of working relationships you have with the developer.

4. Greater access to intellectual property: We’ve seen critical intellectual property leaked by employees—famously, the Gizmodo iPhone 4 leak of 2010, and in 2006, Coca-Cola faced a major leak of its secret formula when an employee shared a copy of the recipe with a journalist. So, trusting people with your company’s intellectual property does not boil down to the working relationship you have with them.

   Usually when talking about software development contractors and intellectual property, the thing that comes up is contractors bringing their own code—whether privately developed by the contracting company or open source—to a project. There’s a famous case involving the developers of a Unix toolkit called BusyBox suing a dozen companies that refused to publish their source code after including BusyBox in their product (publishing your source code is a requirement of the GPL license). Since that case, IP lawyers doing due diligence have been particularly nervous about developers using open source tools. That case really has nothing to do with whether the developers are contractors, but you can see how it would create a fog of intellectual property paranoia.

   Kelsus has its own story to refute that there are intellectual property issues that stem from using third party contractors. We built an entire product over the course of four years for a startup that, for contractual reasons, I cannot name. That product was purchased in an asset sale for an 8 figure sum. The revenue of the purchase went to company and ultimately its shareholders, while Kelsus was only paid for the development services rendered. The intellectual property transition was smooth, standing up to rigorous due diligence performed by a big five accounting firm.

   To summarize, your intellectual property and its safety have little to do with the technical working relationship you have with software developers, and more to do with having good working relationships with the people that build your products and careful legal review of the contracts you have in place with your in-house developers, contractors, and open source licensors.

5. Enhanced security: If you understand cybersecurity, you understand that information and networks don’t inherently behave differently depending on the employment status of people that have access to them. What I mean is that the bits flowing through the tubes are just bits. They don’t know who you really are—only who you’re logged in as. Your company may have added security policies to its systems to limit or enable access to certain systems based on the identity of the user accessing it, and it may have a database that segregates employees from contractors. If your company does have a different blanket security posture towards contractors than towards employees, then it’s probably more likely that a security problem will come the group whose blanket policy is less restrictive (the employees).

So that’s it! I’ve refuted five for five in the list of reasons that it’s better to not let outside vendors work on core competencies. The only concession I gave is that it’s better not to hire an experienced team as a unit and force them to change their method of development to match your preferred method of development because you’ll slow them down and waste one of the benefits you’re probably paying for.

We’re not quite done, though. Businesses are groups of people making decisions and they don’t run on absolute truths. I’ve made an argument that there is nothing inherently preventing outside developers from doing great work on core competencies for your business, but it could be worth looking at this from a different lens. If contractors generally are a poorer choice for working on core competencies because of the factors described above, then we should understand that and plan accordingly.

It turns out there’s some research on the matter. Professor Michael Steven of the University of Marburg did a study, published in Management Revue in 2010, on whether outsourcing in the prior 20 years had caused firms to lose their core competencies. His finding was that they had not, and that the knowledge boundaries of the firms had been decoupled from their production activities.

There’s also the matter of job security. This article in Harvard Business Review, suggests that historically, people felt they could rely on traditional employment to be a source of stability as they took other life risks like starting a family. Now, though, as the number of independent contractors rises and they learn how to navigate the market to easily secure multiple gigs, they believe that they are in a more financially secure spot than they were as traditional employees.

In a note of morbid levity, the takeaway from the article about what employers should do to avoid losing more and more talent to the freelance world is “Obviously, they need to make traditional full-time jobs more appealing, and more secure.” Whoops! Looks like no one has gotten the memo as we go through the largest tech layoff since 2001.

To conclude here, hopefully you can suspend your judgement about my bias long enough to conclude that it may be worth reevaluating any long held position you have about the type of work you’ll allow contractors and third party outsourcing firms to do. You may learn that some of the most talented and loyal developers you’ll ever work with aren’t the ones applying to your job postings but rather the ones that love being able to tackle different challenges across different companies and that may live far from the talent sucking vortex of Silicon Valley.

Thanks for reading!

—Jon Christensen