Work with external developers! Seriously?

[5 minutes reading]

We are in a very fast technological world, where we need to surf over the waves all the time. As companies, we need to give more and more added value to customers, not to beat the competitors, but to help customers with better solutions, that also help them to be better productive companies.

To do so, many companies only look at their internal resources and try to do everything on their own, instead of looking for other companies or freelancers to help them. This usually happens due to some incorrect assumptions:

• Our product is "secret” so my intellectual property is at risk if I use external developers. WRONG!
• No one understands our products except our employees. WRONG!
• The cost of working with external developers is too high. WRONG!
• I will later have dependencies on external developers for maintenance. WRONG!
• …and many other

Some others think in the opposite way, but sometimes with wrong considerations:

• Incorporating external professional resources will give as fast results in a short time. WRONG!

The reality is as follows:

• In many cases, companies do not have the capacity to overcome all the developments needed, and therefore, or they delay deliveries, or lose market opportunities.
• In most cases, it is possible to fragment developments in parts, modules, or services, so internal people could focus on the core "secret intellectual property" parts and external developers could work on the rest.
• You have to focus on doing well what you do well. If you want to be on everything you will lose focus and opportunities
• Using good external developers, even being more costly than internal resources, in the end, could be less costly because you may use your internal resources for other more valuable developments and external resources, in the long run could do the work faster.
• Working with external developers as part of a team helps your internal resources to learn from the external developers and do a smooth technology transfer while development is done, so no dependencies will later exist from external developers.

So, externalizing development is a good option, but you need to have some extremely important considerations, especially when you start working for the first time in this way:

• The external development service most of the time requires very clear requirements, usually more detailed than the ones you might use internally, because they do not know many internal assumptions you usually have, due to your knowledge of your products. So consider it will take time from your side. 
• Set clear short-time deliverables, in an agile manner. This will allow getting results and integrating them into your product soon.
• Set weekly meetings with the external developers, to follow up on progress. This meeting is not to make pressure, but to help the external service to have a clear common understanding during development.
• Encourage your team to work frequently with your external developers during the development process and involve them in the testing phases. This is an investment of time from your resources that will give you two things: a) smooth knowledge transfer of the guts of the development for future maintenance, b) help your team to learn from other professionals.
  
  
  
• But there is probably one of the most important things you have to consider: Having external development services is an investment, not a one-time work. The first time you work with an external service, it will take you time, effort, and money just to help them understand your projects, your standards, your methods, your products, and learn to work together as a team, so do not expect fast and cheap results in the first work. But, this investment in time, money, and effort will greatly help you in subsequent works asked for the same development service. They will work with you like one, already knowing your team, your expectations, your product, your culture, your standards, processes, and methodologies. This is when you really start getting the fast and good delivery, worthing the effort, time and money spent in the past. This is what the graph at the beginning explains.

In the end, it is more a strategic decision than a quick-fix solution for internal capacity problems. Working with external developers, before you have serious capacity problems will help to be prepared for the peaks and valleys that will come.