Our onboarding process

Our onboarding process

The onboarding process depends on many factors, and it's up to Shinetech project managers to understand its intricate details.
Picture of  Shinetech Editorial Group
Shinetech Editorial Group
6 minutes read

How the onboarding process works in Shinetech

Our onboarding process is straightforward so that we can make sure the project is the right fit for the developer and that the developer is the right fit for the existing team.

We look into the developer’s technical skillset, previous experience, and personality traits. Here is how we make sure the fit between the team, the developer, and the project is satisfactory. The process always includes consulting with HR teams; we will explain how below.

How the onboarding process starts

The onboarding process starts when there is an identified need for a new developer to join the project due to changes in requirements or the team itself. We send a request to our HR team – the team goes through the pool of developers to find the best fit. The HR pays attention to the technical capabilities, but they also have more data on each candidate – their success from previous projects, customer feedback, and feedback from previous teams. The HR teams can also provide more data about what the candidate has been working on, such as preparing for certification, attending courses, or any other way they worked to improve their expertise. Also, an important note – the HR team provides a breakdown of the candidate’s personality traits so that the PM can ensure the candidate has both the technical and interpersonal experience required for the project. As Shinetech is an international company, we also pay attention to the candidate’s language skills – English as a second language is a must. Still, if the candidate speaks other languages, relying on such a resource is important.

Once the most suitable candidates have been found, the HR team delivers CVs with additional information to the PM. The PM then arranges semi-formal discussions between the team and the candidates who make the shortlist.

The first meeting

In the true essence of Agile principles, our onboarding process is based on open communication and oral knowledge transfer. The PM arranges a meeting between the team and the candidate who made it to the shortlist.

The PM starts the discussion by providing an overview of the project. We need to ensure not to overwhelm the new developer with the information. Also, the primary mode of knowledge transfer is discussion; the documentation is there to facilitate the onboarding process further.

The team needs to be present during the initial meeting since they will all work closely together soon. The team takes the chance to understand the new developer’s technical skills and their way of communication. In a dynamic and Agile environment, people need to be understood without impediments. An Agile environment requires momentum, which is gained from people having a deep understanding of each other and a deep appreciation of each other’s work. That is why personality traits within a team need to complement each other and work together in order to achieve harmony.

We are also looking for the team to experience as few disruptions as possible; the PM knows precisely how the project runs. For example, if the project follows Agile methodology, we need someone with the technical skills and an understanding of how different methodologies work, specifically Agile. It is essential for the developers also to be comfortable with the current processes and how the project is set up so that we achieve a common understanding. If, for example, the newcomer is unhappy with the process, they will have trouble understanding why the rest of the team is working this way and why we can’t choose another way that might seem better on the surface. This thinking can create gaps in our collaboration, leading to further disruptions. Many people are involved in this process because the potential pitfalls are very challenging and need to be addressed properly.

Impressions after the meeting

After the initial meeting with the candidates, the PM and the team discuss the impressions. If the candidates leave a good impression, we proceed with onboarding. The first important information we share with the new developer is the scope of their work and the responsibilities their work carries.

What is important to note is that knowledge sharing is an ongoing process – you cannot just share them in one day. The new developer needs time to fully understand all the intricate details of the project – the quality, the requirements, and the expectations. There is a thin line between having a detailed onboarding process and not overwhelming the person with as much information as possible.

Another critical detail is managing expectations. The team and the customer may have different expectations from the new developer, so we need to communicate these expectations properly. The main expectations are regarding productivity, efficiency, and quality. The adaptation goes both ways – the existing team members are open to sharing more details with the new developer. The new developer needs to understand the intricate processes and how they can balance their time to meet the expectations.

One of the things with Agile is that the developers need to ‘pick up’ the ideas and processes as they go and combine them with previous knowledge they are bringing. Too much documentation slows down the whole team because, in an Agile environment, the documents need to be maintained regularly so that work takes away from the team’s productivity.

Why is it important for the code to be up to standard</span?

We are discussing an ideal onboarding process and the perfect situation – the customer requires more people for their project, and Shinetech can deliver. But what happens when things don’t go the ideal way? What if a team member leaves and a gap needs to be filled?

PMs face different situations when onboarding a new developer, which may not be only for growing. Apart from bringing the new developer up to speed, they may be expected to continue developing code for the customer.

One of the main principles that Shinetech developers embody is being self-sufficient and independent. As such, they are expected to learn about the project and the customer when we start the onboarding process. The PM’s role is to share the information as we go through the onboarding process, but it’s up to the developer to do their research too. This proactive approach is what characterises Shinetech developers and our work with customers.

During the onboarding process, the new developer needs to understand what challenges they will face and if they are confident in taking this particular role in the development process. We also discuss the potential issues they may think of so that we all proactively work on removing them.

Of course, looking for the right balance between sharing the information and allowing the new developer to dive deep into the work they need to do is essential. Sometimes, sharing too much information with the new developer may seem redundant, especially if the developer deeply understands the processes because of their prior experience with a similar project or technology.

Meeting the customer

Once the internal processes are completed, we introduce the new developer to the customer. The customer may require another separate meeting to discuss the details with the developer, but often our customers trust us that we have their best interests in mind and that we have already found the right fit.

Once both the team and the customer are certain the new developer fits the project from the technical and cultural aspects, we set up accounts and communication channels with them.

Following up with the developer after the initial onboarding process is essential; PMs discuss whether the developer can access the required tools and have the necessary access to accounts. We can always prepare more information based on the initial conversation with the new developer. Following Agile principles, the focus of everyone involved is primarily to build the software that our customers need; documenting the processes comes after and is of a lower priority. But of course, the documentation depends on the customer’s focus – if they need all processes documented, we can prioritise frequently updating the documentation to address the customer’s needs.

Contact us

Please fill require field.
Please fill a valid Email.
Please fill require field.
Please fill require field.
Please fill require field.

[Visual] The developer onboarding process at a glance

  1. A need for expanding the team appears
  2. The PM and the team discuss requirements, responsibilities, and expectations with the customer
  3. The PM sends a detailed list of requirements to the HR
  4. The HR looks for a fitting candidate in their resource pool and send CVs to the lead developer/PM
  5. The lead dev/PM review CVs to understand the candidate’s background, technical skills, general knowledge, and their personality traits to ensure the candidate will be the right fit for the team.
  6. The first meeting – discuss the project background, share more details, and pay attention to the candidate’s experience and personality traits
  7. If the new developer is a good fit – proceed with introduction to the customer in a separate meeting
  8. Once the customer approves – the team sets up access to tools, communication channels, and provides more details if needed

Table of Contents

Are you ready to hire our developers?
Contact us!
Please fill require field.
Please fill a valid Email.
Please fill require field.
Please fill require field.
Please fill require field.