How to make Jun a full-fledged part of the team

How to make Jun a full-fledged part of the team

Every development team is faced with the fact that a young and inexperienced person appears in it. It is natural. The company expects that the new employee will start to justify the investment as soon as possible, but in fact it depends primarily on the actions of the rest of the team. Further in the post, we will give a number of tips to complete this stage as quickly and efficiently as possible.

The easiest way to teach a person to swim is to release them into an open body of water. Either he will learn quickly himself, or he will drown. Some practice this approach with the Juns, and then they are even proud of it: these guys are cool, we made them hell, and they learned everything themselves. Unfortunately, this is survivor’s error.

Junes have just entered the profession, and the first experience they will have will greatly affect their view of the profession as a whole. Many of them entered the development with only one foot, knowing that at any moment they could shift the weight to the other, leave the unfriendly open spaces and “go to the factory”, to recall the well-known career dichotomy. Maybe their talents would have secured them a brilliant future in IT, but thanks to the toxic first team, no one will know.

“But how do we test them then? How do we know that these are the guys we need? This is natural selection,” say supporters of this approach. Well, if they want at least someone to conquer Everest for them, it is worth dividing the ascent into stages. And it is not a secret for anyone that under the luxurious carpet of achievement epithets, deep problems within the company are usually noticed, which are given to employees for ransom.

So, June joined your team. For him, this is the first work in a new direction, it is a cultural and social shock. A newcomer requires time, which will pay off when he becomes a full member of the team. And you have burning deadlines, there is absolutely no time for this, and the only way here is the “trial by fire” described above.

Senior: Enjoying lunch. – Jun: Patiently waiting to say I missed the prod. Source

Suppose you give a newbie a pair of tickets. What kind of tickets will these be? In a team where everyone is at least secretly assigned their front of work, the corresponding tickets are sorted out immediately. And what is left for June? Probably just something that no one else wants to take on. Then, day after day, a toxic attitude is formed towards such a newcomer – this is the most likely scenario of the development of events. “Let’s hurry, deadlines are burning.” “Why are you doing it this way?”. “Sorry, no one will help you, you’ll have to sit up at night to make it.” There is a risk that the toxic attitude towards the newbie will even spill over to higher levels of the organization — if not helped in time, the consequences of mistakes can reach the level of the entire department.

Another danger of this approach, in the long term, is the lack of technological development, innovation in the team. Where it would be possible to try something new, any experts – especially beginners – will cling to the old approaches, because with them there is a risk of drowning below. To avoid dire consequences for themselves, team members may even engage in underhand games in a scramble for an island of land amid an ocean of layoffs; the first step to this can be the very attitude towards Junes.

We have analyzed the typical and most unpleasant scenario, now let’s talk about what can be done to avoid it.

To begin with, you need to assess where a new specialist is coming to your team. If from a position in another development team, then he is probably already familiar with the development culture, about how the processes are roughly arranged. He knows how to communicate by mail, how to configure basic work tools, how to create applications, etc. But if this is the first place of work for a beginner, then he will need additional time to master the basic processes, to understand a completely new ecosystem in comparison with the one he was used to in educational institutions.

At this stage, it is important to determine what basic skills the beginner lacks. With the greatest probability, it will be possible to find out on van-to-vans, during personal conversations. Perhaps there are gaps in social skills or some knowledge of the “confident PC user” – although the skills required by the job are sufficiently developed. The opposite situation is also possible: if, for example, his computer won’t boot, he, as a connoisseur of iron, will start fixing it himself, although company rules strictly forbid it. It is wise to make a checklist of such trifles and not just casually hand it over on onboarding with a bunch of other instructions, but to devote a separate, albeit small, meeting to its discussion.

Having covered all the basic questions, it is worth agreeing with Jun about a time when he should not disturb anyone from the team. Except in exceptional cases. This might be two or three hours in the middle of the day, which are considered most productive, when a solid chunk of work is usually done—like 1 to 3 p.m. Agree to respond later. So the newcomer will begin to learn the internal culture of the team; besides, maybe he will be able to figure it out himself during the time of the answer. If you work in an office, you can agree on a “concentration mode”: when you put on headphones, for example, it is better not to disturb you.

It is important that you, as a more experienced specialist, do not become a “one window” for the entire company. It should be included in the list of basic questions: to whom and in what case should he contact. In some cases, it will be enough to turn to Google, but processes in each company may be implemented in a slightly different way, which should also be covered with links to internal knowledge bases and contacts of responsible colleagues.

The more responsibility you have for June, the more important it is to anticipate possible problems and questions in advance. Especially if you are officially appointed as a Mentor. This will help you a lot, especially in the first weeks, which are the most important during the onboarding process. At this time, it is important to ping Jun from time to time – you can even set yourself 4-5 reminders during the day: “Are you okay? No questions? If there are, I can answer them now.” Yes, this way you can spend a little more time than just waiting for questions yourself, but you can protect yourself from a lot of problems in the future.

First, you need to get to know the strengths and weaknesses of the new specialist better. To do this, try to give him various tasks, but at the same time related to your current project, the completion of which will really help the team. This can be a low-priority task that the team can’t reach: in this case, even if June fails, the team will still get the task after a while. And by this time, he will probably have done some part of the task and will be really useful.

I close the bug. — Senior, who added this bug to make me more confident. Source

Another option is to give Jun small tasks that will be visible in sales, but at the same time will not create a risk for the whole team. For example, redraw the buttons in the program. So he will immediately see the results of his work and be inspired, and immediately he will understand what is organized in the project, he will find answers to his questions. Create a full-fledged task in Jira and bring it to Done status – this will be a good motivator. Many people choose frontend over backend precisely because the results of their work are clearly visible. So give the newbie this opportunity.

Try to find out how your junior studies: what he watches and reads, how he organizes independent work. Perhaps you, as a more experienced professional, can share some advice on how to improve his training. The earlier he improves his studies, the more benefit he will have from it.

New developers are often put on teams that don’t have time to spare and have nothing to say to Jun except “you swim or you sink.” But still try to find this time, connect your resource manager, and as much as possible, the tech leader — in order to convey the necessary practices in the best possible way. When the newbie gets used to it, you can breathe a little easier, at least until your team is loaded with additional tasks – because now there are more of you

Tell me, and what techniques do you practice for training juns?

Related posts