Stephan Schmidt

How to Outsource Development Successfully

What and how to outsource - challenges, pitfalls and success stories


Sooner or later CTOs and founders will come into contact with outsourcing. Outsourcing means giving development jobs to an external company in your country or another country at the other side of the earth. For founders, it’s one of their early questions: Should I hire someone or outsource development of the MVP? Should I find a technical cofounder? For CTOs it comes in the request for cheaper and faster development: Why don’t we outsource?

I came into contact with outsourcing many times during my career as technical manager or CTO and want to tackle some questions here. Why to outsource? What to outsource? What not to outsource? How to successfully outsource development? What are the biggest pitfalls and challenges?

We start with the “why”. Why would someone want to outsource software development? There are three main reasons to outsource development. First if development needs to start immediately, and you do not have enough developers, outsourcing can provide developers on short notice. Second outsourcing gives some flexibility. If you start with a project and don’t know if it is feasible, it is easier to close the contract with the outsourcing company than laying off developers. Third, the most often cited but least important, is cost-cutting. Outsourcing is perceived as being cheaper. Keep in mind that hired developers add to the value of the company, all IP outsourced isn’t something investors like.

Next to the “what”. What should we outsource? Beside the obvious things like MVPs (but check out zero code, you might not need a coder for an MVP), it is less clear and random what companies outsource. Often it just depends on the preferences of managers.

Simon Wardley developed Wardley Maps to draw a map of IT systems and services in a company. The two dimensions are value on the y-axis and evolution on the x-axis. Value means customer value, how much the customer gets direct value from a system. A customer gets a lot of value from the website, but not much value from the database powering it, although of course the database is needed. Each system and service depends on other systems and services. These dependencies are drawn as lines.

On the x-axis we have evolution. Every technology goes through different stages of evolution. It starts with Genesis. Someone invents a computer and builds one for themselves. Like the Zuse Z4. Next is custom build. The inventor or entrepreneur builds computers for others on demand. The next evolutionary phase is product. One can go to a shop and buy a computer. Last is commodity. You no longer buy a computer but get it on demand in the cloud, just like power (the quintessential utility). Technologies over time move through these phases, be it electricity or cars.

Every system is now placed on the map depending on its evolutionary state and the value it provides to the customer. Let’s look at an hypothetical island-renting SaaS company. At the top are the customers at the bottom right with the least value and the highest commodity factor is the power that powers the data centers where the cloud computers are running.

Example Wardley Map Value Map to decide what to outsource

This map gives a clear indication of what to outsource and what to develop inhouse. Everything to the left (and top) which is innovative and has the highest value for the customer needs to be developed inhouse. Products and commodities with less value are outsourced. Landing pages, reporting and the CRM system are commodities and outsourced. The realtime reservation system has high value and is in the Genesis phase of evolution, it should be developed inhouse. This also roughly maps to the view of a core business. Core business systems that give you a USP need to be kept inhouse - with their IP and knowledge! - while peripheral systems can be outsourced.

Too often do I see coachees pressured by business to outsource core IP, never do that, your companies loses a lot of value.

Wardley Map with inhouse versus outsource

Now that we have established why to outsource development and what to outsource, lets take a look at the challenges of outsourcing, and there are many challenges to make outsourcing work.

The biggest challenge is alignment. Your company and the outsourcing company are not aligned, you both have very different goals. And while your departments are also not aligned, this is on a whole different level. You want to have a cheap, smooth project with quality delivery. The outsourcing company wants to make as much money as possible with you. While this might be obvious, it leads to some conclusions. First if the outsourcing company has bad developers which take longer to write code, the outsourcing company gets more money if the contract has no fixed cost - and you get bad quality otherwise. Unless it is too bad and you cancel the contract and move on. But even then another company will replace yours. They are not interested in good quality either, whenever another company took over outsourced code, or insourced that code, most often a full rewrite was necessary from my experience. Keep that in mind and make sure the code is in a state - use an independent consultant to make sure and write it in the contract - that can easily be taken over by different developers. “Start on Monday” is the strength of outsourcing. But this also means that if the outsourcing company does not have the right developers, they will hire all they can get ASAP without a good interview process, or no process at all. If heard outsources claim if they would interview people, those would work for another outsourcing company! Never take the first developers they offer you, always interview outsourced developers, demand better ones and iterate until you have gotten the best 20% developers of the outsourcing company. Because you will start with the bottom 20% - all the developers that have been removed from other projects whom nobody wanted.

The outsourcing company cares about your money, not about your company or product. If you pay for bugs fixed, they will create more bugs, and you pay more for fixing them, profit! Otherwise, they will offer you QA services you pay for, profit! If managing the fixing of bugs and features under time pressure on your side takes too much time (they create these problems mostly), they will offer you a project manager, profit!

In general many outsourcing projects I have witnessed have a high management overhead, with high costs for the project manager. With quality problems and time pressure, management overhead grows. The other mistake is not to manage outsourcing projects and think the outsourcing company is aligned (it is not), and be hands-off. Too often I have seen meetings with outsourcing companies being a mere tea party. This easily spins out of control, outsourcing projects are not fire and forget, they need to be tightly managed to be successful - for you, they are always successful for the outsourcing company.

Other challenges are with developers. Beside them not being the best, there often is high turnover. Developers in many outsourcing companies want to get out. Either leaving the country or joining a more high profile software company. Working in an outsourcing company is not their first choice. High turnover leads to onboarding over and over again, with high hidden costs. They do not identify with the product and will only do the bare minimum. It is difficult to extend your internal engineering culture to the outsourced developers. Different code reviews, different security understanding, different architecture understanding, different or no tests and testing for done. Making everyone feel like being on the same team is a tough job. More than once I have seen internal disgruntled developers (who leave), because the outsourced developers have a different or even no engineering culture (driven by the company not by those developers).

Other challenges include a possible time zone difference. When you are used to short turn around times in hours, often with developers in a far off time zone, turn around will become daily.

What to do about outsourcing as CTO if other departments do it, for example marketing? It’s important to explain to the responsible manager the alignment issue and to actively manage the outsourcing project. Have some integration documentation ready and make sure the contract contains some paragraphs about security. For example put OWASP security standards and checklists into the contract. Make sure there are clear responsibilities and make sure everyone understands what your responsibilities as CTO are - and what aren’t.

There are success stories. A coachee of mine has an excellent outsourcing team in Poland. I successfully outsourced mobile app development. We did not have a mobile team, recruiting mobile developers takes time, so we decided to outsource development of our core app. To make this successful, I’ve interviewed developers and iterated over team members until the team was great. We also put it in the contract, that we could hire members of the team - with compensation - later for insourcing. So developers were incentivized to write good code as they might be the ones who need to maintain it. We had weekly meetings with the CTO of the outsourcing company and a senior developer attended the daily Scrums of the outsourcing team. We also took a look at the code to make sure it’s of good quality.

Outsourcing can work, but everyone needs to be aware of the challenges and pitfalls and actively manage the outsourcing company.

Join the AMAZING CTO newsletter!
By signing up I agree to receive your newsletters and accept the terms and conditions and data protection

More Stuff from Stephan

Other interesting articles for CTOs

Best books for CTOThe CTO BookExperienced CTO CoachEngineering Manager CoachingCTO MentorCTO MentoringCTO NewsletterHow many developers do you need?Postgres for Everything Product Roadmaps for CTOsHow to become a CTO in a company - a career path

Other Articles

What Startups and Managers can learn from Brexit About Pay Rises And Customers

Goals are a Spectrum not a Number

Tests Are Bad For Developers

CTO vs CEO - how cooperation can work

Just Use Postgres for Everything