Almost the entire Skyeng development team, consisting of more than 100 people, works remotely and the requirements for specialists have always been high: we were looking for signors, fullstack developers and middles. But in early 2019, we first hired three juniors. This was done for several reasons: hiring only super-specialists does not solve all problems, and to create a healthy atmosphere in the development, people of different levels of professionalism are needed.
When you work remotely, it is extremely important that a person comes to the project and immediately begins to bring benefits, without any long learning processes and buildup. It doesn’t work with juniors, plus, in addition to training, it also requires competent integration of a beginner into the team, because everything is new to him. And this is a separate task for the team leader. Therefore, we were focused on finding and hiring more experienced and already established developers. But over time, it turned out that teams consisting only of Signorers and fullstack developers have their own problems. For example, who will be involved in routine, but mandatory tasks that do not require super-qualifications and some special knowledge?
Instead of hiring juniors, we used to mess with freelancers
While there were few tasks, our Signors somehow clenched their teeth took these uninteresting tasks for themselves, because the development should move forward. But this could not continue for a long time: the projects grew, the number of routine simple tasks increased. The situation began to look more and more like a joke, when nails are hammered with a microscope instead of a hammer. For clarity, you can turn to arithmetic: if you are attracting a person whose rate is the conditional $ 50 / hour to work that an employee can handle with a rate of $ 10 / hour, then you have problems.
The most important thing we have learned from this situation is that the current paradigm of hiring only cool specialists does not solve our problems with routine tasks. We need someone who will be ready to do the work that seasoned gentlemen perceive as punishment and entrusting them which is corny ineffective. For example, to write bots for Slack chats of our teachers and course compilers or to engage in small improvement projects for internal needs, for which developers constantly do not have enough time, but with whom life would become much more pleasant.
At this point, an interim solution was worked out. We began to involve freelancers in our projects. It was on such outsourcing that simple and non-urgent tasks began to go: somewhere to fix something, somewhere to check, something to rewrite. Our freelance wing grew quite actively. One of our project managers collected tasks from different projects and distributed them to freelancers, guided by the existing database of performers. Then it seemed to us a good decision: we took off the load from the Signors and again they could create in full growth, instead of tinkering with something elementary. Of course, there were tasks that, because of trade secrets, could not be handed over to external performers, but there were fewer such issues compared to the mass of tasks that go to freelance.
But this could not last forever. The company was faced with the fact that the freelance division turned into a clumsy monster. The number of routine simple tasks grew along with the projects and at some point there were too many of them to effectively distribute them among external performers. In addition, the freelancer is not immersed in the specifics of the projects, and this is a constant waste of time on onboarding. Obviously, when your team has 100+ professional developers, you cannot hire even fifty or so freelancers to help them and effectively manage their activities. In addition, interaction with freelancers is always some of the risks of deadlines and other organizational problems.
It is important to indicate here that the remote employee and the freelancer are two different entities. The remote employee is fully registered in the company, has a designated working time, team, bosses, and so on. A freelancer is a project work that is mainly regulated only by deadlines. A freelancer, unlike a remote employee, is mostly left to his own devices and interacts poorly with the team. Hence the potential risks from interacting with similar performers.
How did we come to the creation of a “department of simple tasks" and what we did
After analyzing the current situation, we came to the conclusion that we need lower-skilled employees. We did not build any illusions that we would grow future superstars out of all the juniors, or that hiring a dozen June would cost us three copecks. In general, the situation with juniors is as follows:
- For a short distance, hiring them is not economically feasible. Instead of five to ten June “right now,” it’s better to take one signor and pay him millions of money for quality work than to spend budgets on newcomers.
- Juniors have a long period of entry into the project and training.
- At that moment, when June learned something and it seems like he should begin to “work out” investments in himself for the first six months of work, he needs to be promoted to middle, or he will leave for this position in another company. So hiring June is only suitable for mature organizations that are willing to invest in them without guarantees of short-range profit.
But we have grown to the size where there is nowhere without a junior team: the number of ordinary tasks is growing, and spending human hours of seasoned professionals on them is simply a crime. That is why we created a department specifically for junior developers.
The period of work in the simple tasks department is limited to three months - that is, this is a standard trial period. After three months of fully paid work, the newcomer either goes to a team that wants to see him in his ranks as a junior developer, or we part with him.
At the head of the department that we created is an experienced PM who is responsible for distributing work tasks in June and their interaction with other teams. June receives the task, performs it, receives feedback from both the team and his manager. At the stage of work in the simple tasks department, we don’t assign beginners to specific teams and projects - they have access to the entire task pool according to their skills (now we hire front-end renders in AngularJS, backers in PHP or we are looking for candidates for a position of web developer with both languages) and can work with several projects at once.
But everything is not limited to hiring dzhuns - they need to create conditions acceptable for work, and this is already a completely different task.
The first thing we decided on is voluntary mentoring in healthy volumes. That is, in addition to the fact that we did not force anyone to mentor existing specialists, it was clearly indicated that training a beginner should not become a substitute for the main job. No "50% of the time we work, 50% learn juna." In order to have a clear idea of how much time will be spent on mentoring, a small “curriculum” was compiled: a list of tasks that each mentor had to complete with his mentee. The same thing was done for the project manager of the jones, and as a result, we got a very smooth and understandable scenario for training newcomers and getting them into work.
We envisaged the following points: testing theoretical knowledge, prepared a set of materials, if the June needed to finish something, approved a single principle for conducting a code review for mentors. At each stage, managers give feedback to the newcomer, which is extremely important for the latter. A young employee understands in which aspects he is strong, and in which he needs to be careful. To simplify the learning process for juniors and experienced developers, a general chat has been created in Slack, so other team members can connect to the learning process and answer a question instead of a mentor. All this makes working with the Joons quite predictable and, most importantly, a controlled process.
At the end of the three-month trial period, the mentor conducts a final technical interview with the junior, according to the results of which it is decided whether the junior can switch to full-time work in one of the teams or not.
Total
At first glance, our junior department looks like an incubator or some specially created sandbox. But in fact, this is a real department with all the attributes of a full-fledged combat team that solves real, not training, tasks.
But most importantly, we give people a specific horizon. The department of simple tasks is not an endless limb in which you can get bogged down forever. There is a clear deadline of three months, for which the junior solves simple tasks on projects, but at the same time he can prove himself and go to some team. The novices hired by us know that they will have their own project manager, a mentor from the gentlemen (or maybe several) and the opportunity to fully join the team, where they will be glad and will be waiting for him.
Since the beginning of the year, 12 joons have been hired in the department of simple tasks; only two have not passed the probationary period. Another guy did not take root in the team, but since he is very capable in terms of work, he was returned to the department of simple tasks for a new term, for which, we hope, he will find a new team. Work with juniors had a positive effect on our experienced developers. Some of them, after a period of mentoring, discovered the strength and desire to try on the role of team leaders, someone, looking at the Jones, pulled up their own knowledge and moved from the position of the middle to the position of the Signoret.
We will only expand our practice of hiring young developers, because it provides many benefits for the team. June, however, gets the opportunity of full-fledged remote employment regardless of their region of residence: members of our development teams live from Riga to Vladivostok and cope with the time difference perfectly thanks to well-functioning processes within the company. All this opens the way for talented people who live in remote towns and villages. And we are talking not only about yesterday’s schoolchildren and students, but also about people who decided for some reason to change their profession. Our junior with the same success can be both 18 and 35 years old, because the junior is about experience and skills, but not about age.
We are confident that our approach can be easily extended to other companies that use the remote development model. It simultaneously allows the targeted hiring of talented juniors from anywhere in Russia or the CIS, while pumping mentor skills from experienced developers. In financial terms, this story is extremely inexpensive, so everyone benefits: the company, our developers and, of course, juniors who do not have to move to large cities or capitals in order to become part of an experienced team and work on interesting projects.