Different types of outsourcing

IT outsourcing is very popular nowadays due to the fact that it has a lot of pros from a business perspective. There are a couple of blog posts written on this topic. You can take a look at one of them  here. This post is about showing what makes an outsourcing partnership tempting for a developer – and at the end of they day it is a win-win situation when both you and your developers are happy.

You can divide IT outsourcing into separate categories based on distance (offshore, nearshore, onshore – you can read more about them here), on your strategy (Tactical, Strategic or Transformational – more on this here), or how many people are being outsourced to the development team and how they are used – my blog post will show the differences from this point of view.

‍

The three categories are the following:

• you get full responsibility over development and maintenance,
• you offer a dedicated team just for the development tasks, or
• you offer a couple of experts to complete the development team (team augmentation)

Full responsibility, in most cases, is similar to an in-house development project – the only difference is that the outsourcer company defines the goals and features.

‍

Common thoughts

Assessing a developer’s workload  is critical to both working in a partnership with team augmentation or in a dedicated team being outsourced – from both ends as well. It is not convenient when you are over or understaffed: being understaffed needs no explanation, but it is embarrassing when you need to turn over to the lead developer for new tasks every couple of hours or days. It is even worse when you do not have anything for them to work on for a longer period. So, from an outsourcer company’s perspective, you need to be careful about assessing  your resources – not just their number, but also their skill level and areas of expertise tailored to the project they are working on.

Team augmentation

Team augmentation is a flexible outsourcing service, where an outsourcing company provides technical experts to your team either temporarily or permanently. From a developer’s perspective, it can be either very efficient or a nightmare for everyone. Much also depends on the developer’s attitude and needs. But as a dedicated developer, you probably want to contribute at a deeper level. You probably want to share your ideas, and be involved in the planning as well.

Naturally, this will not happen from day one. Trust needs to be established with your newly assigned team, and you may have to learn the project that you are working on if you are not working on a project that is just about to start. Going forwards, it all depends on how the team treats you – you can be the developer who gets the tickets that they need to implement, and that is it.

I am pretty sure there are many developers who are satisfied with this, but in most cases you want to be involved in the planning of the features that you are about to implement. If your team recognizes you as a full team member and does not treat you as a development resource, it is most likely the ideal solution for both parties. From the team’s perspective, they get a member who they can rely on for other responsibilities besides development. And, most likely they will stay longer because they feel part of the team.

On the other side of the coin, the team should not forget that some of their members are not their employees. So they should not rely on them exclusively regarding the operations and maintenance ’to-do’s’. The agreement can expire or the technical expert can be allocated to a different project, and this gives overhead to the development process because you might need to transfer a lot of knowledge back to where it should normally sit.

Dedicated team

Let’s define a scenario that you and your team, within the same company, are responsible for the development, but you need to hand over the code to the outsourcer company. And they are responsible for the infrastructure and operations.

This setup can be very tricky because responsibilities and roles need to be defined accurately, otherwise the team might need to deal with issues that should be an operational thing, and vice versa. For example, on one of our recent projects we faced an issue that Amazon Cognito’s default emails sent for the „forgot password?” function got filtered by multiple spam filters. A possible solution would have been to change the email address in Cognito and not to use its default, but the outsourcer company decided to implement a feature in the application to have its own Forgot password function using Cognito’s API. This was due to a lack of resources on the operations team. The result was that we had two ways to reset a user’s password, but for some users only one of them is working properly.

The outsourcer company might also have internal company policies that maybe hard to follow and the team needs to learn and adapt to these rules. You can imagine anything starting from quality assurance to code review, release management or just simply handling the JIRA board. As an example, some companies are using JIRA to do ad-hoc requests between different teams, and if you need something from the operations team, you need to submit a ticket. If you do not have insights to these processes, you will need some help from the company to know what kind of information you need to provide on the ticket, which board you need to use, who to assign the ticket to, etc.

There might be cases when you need to integrate your application to other applications of the outsourcer’s company. This collaboration might not be efficient from day one, because a project gets to be outsourced due to the fact that the company does not have enough resources to implement it by themselves. If you need to integrate to other customly built applications within the company, there is a high chance that they will struggle with resources if they need to support custom development.

It is also important to recognize that, even though you are outsourcing the development, you should have shared responsibility with the development team from a maintenance and operations perspective. Particularly if it is the responsibility of the outsourcer company.

Conclusion

The bottom line is that regardless of which type of outsourcing partnership you are working with, the key thing is how you and your team are recognized within the environment – if you are treated as a team member fully, then it is the best from a developers perspective.

Do you need some new team members to your new project?

‍Get in touch with us then!

‍