Almost the entire Skyeng development team, which consists of more than 100 people, works remotely and the requirements for specialists have always been high: we were looking for seniors, fullstack developers and middles. But at the beginning of 2019, we hired three juniors for the first time. This was done for several reasons: hiring only super-specialists does not solve all problems, and to create a healthy atmosphere in 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 and buildup processes. It doesnβt work that way with juniors, plus, in addition to training, a competent integration of a beginner into the team is also required, 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 established developers. But over time, it turned out that teams consisting only of seniors and fullstack developers have their own problems. For example, who will be engaged in routine, but mandatory tasks that do not require super-qualification and some special knowledge?
Before, instead of hiring juniors, we messed around with freelancers
While there were few tasks, our seniors somehow clenched their teeth and took on these uninteresting tasks for themselves, because development should move forward. But this could not go on for long: 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 attract a person whose rate is conditional $50/hour to work that an employee with a rate of $10/hour can handle, then you have problems.
The most important thing we 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 seniors perceive as a punishment and entrusting it to them is corny inefficient. For example, writing bots for the Slack chats of our teachers and course writers, or doing small internal improvement projects that developers constantly do not have enough time for, but which would make life much more pleasant.
At this point, an intermediate solution was worked out. We began to involve freelancers in our projects. It was for such outsourcing that simple and non-urgent tasks began to go: to correct something somewhere, to check somewhere, to rewrite something. Our freelance wing grew quite actively. One of our project managers collected tasks from different projects and distributed among freelancers, guided by the existing database of performers. Then it seemed to us a good decision: we removed the burden from the seniors and they could again create to their full potential, instead of tinkering with something elementary. Of course, there were tasks that, due to trade secrets, could not be transferred to external performers, but there were many times fewer such issues compared to the mass of tasks that went to freelance.
But it couldn't go on forever. The company was faced with the fact that the freelance division has become 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, a freelancer is not immersed in the specifics of projects, which is a constant waste of time on onboarding. Obviously, when you have 100+ professional developers in your team, you cannot hire even fifty freelancers to help them and effectively manage their activities. In addition, interaction with freelancers is always some risk of missed deadlines and other organizational problems.
It is important to note here that a remote employee and a freelancer are two different entities. A remote worker is fully registered in the company, has designated working hours, a team, superiors, and so on. A freelancer is a project work that is mainly regulated by deadlines. A freelancer, unlike a remote employee, is mostly left to himself and interacts poorly with the team. Hence the potential risks from interacting with such performers.
How we came to create a "department of simple tasks" and what we got
After analyzing the current situation, we came to the conclusion that we need employees of lower qualifications. We did not build any illusions that we would grow up to be future superstars from all the juniors, or that hiring a dozen juniors would cost us three kopecks. In general, according to the situation with juniors, the reality is as follows:
- It is economically unprofitable to hire them for a short distance. Instead of five to ten juns βright nowβ, it is 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 the moment when June has learned something and seems to have to start βworking offβ investments in himself for the first six months of work, he needs to be promoted to middle, or he leaves for this position in another company. So hiring juniors is only suitable for mature organizations that are willing to invest in them without guarantees of profit in the short term.
But we have grown to the point where there is no way without juniors in the team: the number of ordinary tasks is growing, and it is simply a crime to spend man-hours of hardened professionals on them. That is why we created a department specifically for junior developers.
The period of work in the department of simple tasks is limited to three months - that is, this is a standard trial period. After three months of full-time paid work, a rookie is either sent to a team that wants to see him in their ranks as a junior developer, or we part with him.
The department we created is headed by an experienced PM, who is responsible for the distribution of work tasks among juniors and their interaction with other teams. June receives a task, completes it, receives feedback from both the team and his manager. At the stage of work in the simple tasks department, we do not assign beginners to specific teams and projects - they have access to the entire pool of tasks according to their skills (now we are hiring AngularJS front-enders, PHP backers, or looking for candidates for the position of a web developer with both languages) and can work on multiple projects at once.
But everything is not limited to hiring juniors - they need to create acceptable working conditions, and this is a task of a completely different plan.
The first thing we decided on was voluntary mentoring in reasonable volumes. That is, in addition to the fact that we did not force any of the existing specialists to mentor, it was clearly indicated that the training of a beginner should not become a substitute for the main job. No "50% of the time we work, 50% we teach the junior." In order to have a clear idea of ββhow long mentoring will take, a small βcurriculumβ was drawn up: a list of tasks that each mentor had to complete with their mentee. The same was done for the project manager of the juniors, and as a result we got a very smooth and understandable scenario for preparing newcomers and their entry into the work.
We have provided for the following points: testing of theoretical knowledge, prepared a set of materials if a junior needs to finish learning something, approved a single principle for conducting code reviews for mentors. At each stage, leaders 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 more careful. To simplify the learning process for juniors and experienced developers, a common chat in Slack has been created, so that other members of the team can join the learning process and answer a question instead of a mentor. All this makes working with juniors a completely predictable and, importantly, controllable process.
At the end of the three-month probationary period, the mentor conducts a final technical interview with the junior, based on the results of which it is decided whether the junior can move to a permanent job in one of the teams or not.
Total
At first glance, our junior department looks like an incubator or some kind of 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 the most important thing is that we give people a concrete horizon. The Easy Tasks department is not an endless limbo that you can get stuck in forever. There is a clear deadline of three months, during which the junior solves simple tasks on projects, but at the same time he can prove himself and move to some team. The newcomers we hire know that they will have their own project manager, a mentor from seniors (or maybe several) and the opportunity to fully integrate into the team, where they will be happy and waiting for him.
Since the beginning of the year, 12 juniors have been hired in the simple tasks department, 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 simple tasks department for a new term, during which, we hope, he will find himself a new team. The work with juniors also had a positive effect on our experienced developers. Some of them, after a period of mentoring, discovered in themselves the strength and desire to try for the role of team leaders, someone, looking at the juniors, improved their own knowledge and moved from the position of middle to the position of senior.
We will only expand our practice of hiring young developers, because it brings many benefits to the team. Junes get full-fledged remote employment, regardless of their region of residence: members of our development teams live from Riga to Vladivostok and cope well with time differences thanks to streamlined 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, for some reason, decided to change their profession. Our junior with the same success can be both 18 and 35 years old, because a 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. At the same time, it allows you to selectively hire talented juniors from anywhere in Russia or the CIS, and at the same time upgrade the mentoring skills of experienced developers. In financial terms, this story is extremely inexpensive, so everyone wins: 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.
Source: habr.com