Onboarding outsourced developers – how to effectively share knowledge with partner’s teams

Let’s assume that you’ve already defined your needs, chose the fitting software development partner, and ensured that your external team would be built around A-Players. So, can you just jump straight into the work, and rest assured that you covered every vital step of the way? Well, no.

In this rundown, we intentionally omitted one part about which this article is – onboarding external development teams. Studies show that a strong onboarding process improves the productivity of new hires by over 70%, and although most companies strive to do their best when hiring internal employees, this part is sometimes overlooked when launching cooperation with a software development partner. Yet one should build the same solid foundations in this scenario either, to ensure the effectiveness of the cooperation with chosen software development partner. Keep reading to see what must be covered during the process of onboarding external development teams to facilitate the following work.

Before we move to the details of onboarding outsourced developers, let’s start with clarifying at what stage of cooperation launch it should happen with a short timeline. Since the first step we covered in our eBook and already wrote a post or two on communication, this article would be focused on the onboarding milestone – the knowledge transfer (which by the way is usually exactly what people think of when using the term “onboarding”). The goal of the process should be obtaining an in-depth understanding of both business goals and technical aspects while establishing a relationship and trust between external development teams and your internal specialists.

For the sake of simplicity, we would divide the knowledge sharing process into 2 main parts as in the graph above and describe them in such order, adding a few additional recommendations at the end of this article. Yet before we move forward, we shall recap who should be involved in all these steps. As illustrated, the process demands engagement from both parties, which level is changing throughout onboarding. While creating this graph we assumed a scenario in which the external development teams are to broaden your development capability, yet if you don’t have any internal IT specialists, and choose to completely rely on your software development partner it still can be applied. Simply transfer the IT-related roles from the client to the vendor and ensure that your business-related representatives are ready to take part in the workshops and share all the necessary knowledge. Yet in both scenarios, this engagement is a key element of building a solid foundation upon which effective cooperation might be established since no one knows your goals and challenges better than yourself.

Part 1. Business workshops

The first step of the onboarding should be sharing knowledge about the business environment in which the team would be working. Although the general information is shared during the preboarding stage, once all the arrangements are done and come the time to start the work you have to dive much deeper allowing your software development partner to see the whole picture. Start with your company presentation, including your mission, values, and structure. Wonder why this is important for external teams? According to Conway’s law, the software you develop is influenced by your goals, values, vision, and organizational culture, so it’s essential to be on the same page with the external team to ensure the created solution will feel like your own. What’s more, knowing not only what they have to do but also why allows the partner’s teams to not only handle the task that you assign to them but also act proactively and suggest what might be improved to get you closer to your goals. That’s makes sharing the business context critical if you want to make the utmost out of delegating software development.

Later comes the time to carefully analyze your business domain. Even if you followed our advice and select a partner experienced with it, there are no two identical companies that work in exactly the same way. It’s also the right time to start introducing ubiquitous language – being careful about the terminology you’re using from the very beginning will save you from misunderstandings at latter stages. Once your software development partner is familiar with your company, business environment, and main challenges it’s time to drill-down and focus on the core – the system to be developed, starting with user/business perspective, later moving into technological intricacies. In case your product is to be created from scratch that’s the time when you can start ideation workshops using methodologies like event storming as we did in this case.

Part 2 – Technical workshops

Having the business-related part discussed inside out, it’s time to get through all the technical intricacies of the work to be done. This we usually divide into 2 parts – starting with the architectural view and focusing on the low-level on the following stage.

2a- Architectural view

At first, you should discuss the system architecture, system data, data flows, integrations and communication between components and devices, followed by key aspects and the business logic of the app. Later move downwards, to more “mundane” parts like the terms used within the code, share the lessons you learned while working over this app (making mistakes once is normal, making the same one again is what you should avoid ?) and challenges in regard to the current technology.

This stage is the right moment to discuss the software development and deployment processes you use, definitions of done and the whole software development methodology utilized in the project. The goal of this part is to ensure that once the works start, we will be on the same foot when it comes to approach to development. It’s also an opportunity to ask the external development specialist if they see any fields of potential improvement to the Software Development Process. They should have not only extensive experience but also an unbiased view on the way you work, thus may detect potential fields for improvement. Employing a software development partner to not only work on the product but also be a “breeze of fresh air” in your company is battle-tested practice and like in this example can highly boost the effectiveness within not only the project you’re working on but even among your whole organization.

2b – Low-level view

Next comes the time to “let developers talk to developers” (yep, we know there are talking from the very beginning, that’s just jargon ;)) Being aware of your business and its environment, having the general look at the system from both creator and user perspective, and knowing the software development process they should dive deep into the code, to land on the same page when it comes to terms used within and best practices applied by the internal team. This will shorten the time needed to start the work and allow to operate accordingly to established rules from the very beginning. Clearly, you should prepare a list of topics that must be discussed with the external team yet remember to leave them a space for unplanned discussion, since there may always be something that seems insignificant, but will require an analyze. At the same time, don’t stress about leaving something out. If you’ve chosen an experienced partner, their representatives know what have to be discussed at this stage and will certainly have their own list of topics to fill in any potential gaps.

Ensure that all accesses are granted, and your external team knows who is responsible for what

At this stage, your partner should know everything necessary to finally jump into work and do what you want them to do. But even all the knowledge alone is not enough to ensure the effectiveness of the cooperation. What still can slow down your external partner’s work are technical problems with accesses and the work environment. Common matters that should be discussed are VPNs, accounts, and login information to all the tools that are used, and the organization of the work environment. These mundane issues can either boost the effectiveness of your partner’s work or slow it down if they would have to struggle with accessing the resources. Although some additional questions and problems are inevitable, yet the better you prepare the sooner real work starts. In order to cope with the unexpected, it is best to prepare and establish communication channels and persons responsible for particular aspects of cooperation at the very beginning too. Thanks to this, in the case of any unforeseen problems, your external developers will know who and how to approach in order to receive the necessary help and thus deal with all the obstacles at the rate of knots. What’s more, securing everything for your external team is a great way to make a good first impression and helps to establish positive relationships.

Informal relations matter

Apart from the so-called “formal” part described above it can’t be stressed enough how important are the informal talks happening in the proverbial kitchen during the breaks or even after hours. These are on the one hand a chance for your new team members to discuss all the technical matters even deeper but on the other are a great chance to bond. When onboarding an outsourced team of experts, you shouldn’t ever omit these parts. If the onboarding is happening onsite it might be easier since people usually do it unaffectedly yet ensure to leave them a space for such conversations. And how about remote onboarding? Just like we stated in our text about launching the cooperation without meeting in person that not only can be done but also isn’t as difficult as it sounds. You can use one of many available tools that allow simulating an office kitchen where all the participants would be able to casually talk about not only work-related stuff, or simply have a pint together once the workshops are done. If you’re not convinced that this is worth the time – trust us, that would undoubtedly pay off with the time.

Don’t leave them on their own

Preparing to and hosting the onboarding workshops is best what you do to shorten the time needed for your external team to work at full capacity, yet you can’t prepare for everything. There always that one issue that comes out over time and needs to be dealt with, there are almost always singular, unexpected, problems with accesses – you can’t prevent this. That’s why during the first few weeks of cooperation you should be ready to give a helping hand in such situations. Looking back at the bonding process – most of these issues can be handled on the “low-level” so if the teams managed to bond their members would be supporting each other on their own. And if you followed our tips carefully, the external team will know exactly who and how to reach in case of any more serious obstacles. After some time, everything should be working seamlessly, allowing you to get where you want to be.

Get a running start!

Meticulously onboarding external software developers is a great way to boost the effectiveness of the cooperation, get closer to your goals, and run ahead of your competition. Even if you haven’t had a chance to host such a process, you can always reach your partner’s experience. If you managed to choose an experienced partner they surely participated in such processes before and should be willing to help you make the utmost out of it. And if you want to discuss the onboarding of outsourced software developers or a particular step of this process more precisely use the contact form below – we’re eager to share our experience.