Juniors are free. And 7 more misconceptions of team leaders about beginners
My name is Anton Marunko, and I have been a team lead in product companies for over 5 years. Now I am an iOS Lead in HiFi Streaming Soundand as a consultant I help build and train teams in the IT and near-technical fields. I have experience as a CTO and co-founder in a number of projects. In this article, I would like to share my accumulated team management experience and dispel some myths about team leads working with juniorsThis story has been troubling me for the past year, as when I consult with newcomers I often encounter inhuman demands on them without appropriate recognition and reward.
Junes are free (or almost)
No, juniors are not free.
Yes, there is a tendency to complicate the requirements for junior developers. Many agree to work “for food” and experience or do a long internship in search of a normal job. But this does not mean that such juniors should be underestimated (rather the opposite!). Losing a person at the start is very expensive. A junior pays off for the company only if he works in it for a sufficient amount of time: otherwise, you will lose time spent on onboarding, training, etc., and be left with nothing. If you are limited in budget, then a compromise can be an intern or student rate for the first time, but then there should be an announced and systematic (recorded on paper or somewhere else) plan for the junior's income growth in proportion to his contribution or the internal regulations of your company. In my practice, I often encountered juniors closing many small tasks, bringing real benefits to the business.
Juns should study in their free time
Indeed, many juniors are ready to sit day and night to quickly level up in the profession. But not everyone can do it without harming themselves: such a pace can lead to burnout at the first stage of immersion in the profession and, as a result, a brain drain from the industry. If you take a junior on board, be responsible for his training. It is worth including him in working hours, ideally – to create training on the recommendation of a mentor with intermediate checkpoints. You can develop a person through work tasks, if you have enough of them in different areas. For example, at Zvuk, we try to select development tasks from adjacent areas of responsibility, implement something within the framework of technical debt or agree with the team on joint development of the employee.
The Junes are not members of the team yet.
Junior is a full-fledged member of the team. This means that he needs to participate in the review. Yes, at first he is unlikely to leave active comments on the work, but the junior will definitely learn and observe the team's standards, its decisions, reasoning in discussions and the conclusions reached. Junior participates in all team meetings and learns not only the code, but also the processes, approaches, practices and culture of the company. He has a fresh perspective, so the junior can suggest a non-obvious solution for fixing a bug or a method of working with a certain entity. We add different participants of product streams to the review in teams for knowledge sharing and immersion in the area of responsibility, this, by the way, is also a good way to reduce the bus factor.
Juniors turn into middles in a set time frame
The most annoying and frequent argument from leads of different companies. No, if you hired a junior, he will not become a middle in 3 months or in some period of time set by you. I encounter such misconceptions so often that I had to put this mistake in a separate section of the article. Make realistic plans for the development of a junior and adjust them for a specific person, do not demand the impossible from the employee.
There have been stories in the IT industry where a junior was given a condition – to grow to a middle in 3 months or quit. Or after a two-week onboarding, a junior was required to perform as an average middle (along with the lack of clear documentation and a refusal to train a specialist on project tasks).
Do not do it this way.
The Junes can handle everything
This also needs to be explained. No, they won't cope. More precisely, it is not guaranteed. Have you provided all the documentation on the functionality? Description of the methods of working with the backend and clients? Have you left room for questions and discussions? Have you outlined the architectural milestones, described them in the project documentation? Yes? Then the probability of solving the problem is higher. If you have not given all the keys, then prepare for an iterative approach. Help, guide, prompt.
June will leave as soon as she learns everything.
No, he won't leave. More precisely, he won't leave without a reason. You can lose a grown junior if you haven't created the necessary conditions for his development: training, introduction to the process, salary increase as his competencies grow.
If this is not the case, then the trained specialist will go looking for a job with normal conditions (and this is logical). Therefore, look at the market, be in the market – and this is a topic for a separate article (here we will accept it as a given for now). It would be cool if you shared your stories of growth within the company from the entry level in the comments. This will help managers reduce the fear of losing a specialist after his training.
Junes can't do anything
They can. Juniors often find fresh and interesting approaches to work. Often, new specialists bring something new to the team. This happens because juniors learned from scratch, absorbed a ton of knowledge from different sources of information, and at the same time do not have the burden of background and developed solutions (that is, there is no influence of experience on work). Believe me, sometimes juniors can bring a ton of benefits by closing the tasks with which you play ping-pong at each backlog review, and thereby improve the metrics and statistics of the team.
Once I gave a junior a bug (an annoying one, but not the most important one) to fix, being completely unsure about the solution to the problem. However, the junior coped: he refactored the code a bit and described the case in the documentation for the future.
Instead of a conclusion
I have listed here the misconceptions that I have encountered in practice, but in reality there are many more of them. Don’t be an angry lead, who leaves a negative impression of working with you: choose a non-toxic and creative management style. Remember that juniors grow up and become those who carry information about you and your company to the community, which means they influence the brand and hiring in general.
If you are not ready to invest, grow and develop specialists, then it is better not to take juniors into the team. I will be glad to hear about your experience of working with juniors and exchange opinions in the comments!
