I will describe it using the example of the abstract developer Tom. Tom got a job at Internetmagazinzaden as a php middle developer. The company makes online stores from template to complex ones with a bunch of integrations. The company has all the best Agile, SCRUM, stand-ups and retro. Tom has worked for 3 months and everything is going well for him, he launched a couple of IMs, they even work and the customers are happy.
Here comes a new task for the development of IM, but with integration with CRM. Tom starts with the task of integration and at some point he does not succeed and the term stretches for a week. At the same time, at the general rally, Tom says that he is “dealing with the problem,” hoping that he is already close to a solution. Tom turns to senior developer Mike (who is not his mentor and just sits not far from Tom), he directs him to manuals and briefly explains what needs to be done.
Tom leaves to read the tutorials and deal with the problem. After a couple more days, he returns to Mike with questions about integration, and together they sort them out.
Tom leaves to sort it out for a couple of days, after which he returns to Mike again and gives him the final solution. Mike checks the assignment and points out a few minor bugs that Tom will soon correct.
It seems to be a working picture, but there are several points that show us that Tom is no longer a middle developer as we thought before, but June.
- Tom spent a very long time (in this case, a week) dealing with the problem and did not signal the problem in time.
- I could not figure it out with the tutorial myself and instead of googling some incomprehensible moments I went to Mike.
- Tom spent the time of another developer instead of using stand-ups and discussing his problems there.
Sometimes at interviews for the position of a team lead, they ask the question "How do you divide developers into June, middle, senior?" And my answer is something like this:
- , ;
- , ;
- - .
In Tom's case, he just got the tutorial and implementation description from Mike, but he couldn't figure it out and returned to Mike. This for me was the first important "call" that we are not middle. The second important call was that the skill of “signaling a problem” is very important for the middle, and if he does not possess it, then in terms of soft skills this brings him back to the juniors. The third "bell" is the careless attitude to the time of another developer inherent in Juniors, who sometimes do not understand the importance of following the process and turn to the most "kind" developer instead of going to the lead and getting a mentor through him. This is important, because perhaps the developer Mike is busy on a super responsible project or his task requires high concentration, but the programmer John is literally sitting at the next table,who has just finished a project and has not yet had time to start diving into a new one.
Let's consider another case. Senior developer Vasya has been working for the company for a long time. Vasya has a team lead, Petya. And it just so happened that Petya is a very thoughtful leader and he not only sets a task, but works together with a system analyst on every aspect of it and only then gives it to work. Vasya and Petya have been working in the company for 4 years and this scheme is already in the order of things. At the same time, Vasya perfectly implements tasks according to the written technical specification, documents the code and is pleased that everything is so "nice and fine" with him.
But here's the bad luck, after a while the company closes and Vasya has to look for a job and for some reason they begin to qualify Vasya at interviews not as a senior, but as a middle. “How did this happen? Where did I fall? " He asks himself.
Everything is simple again, Vasya lost the skill of finding the optimal solution to the problem, in 4 years the system analyst and the caring team lead relaxed Vasily so much that this skill was no longer needed.
What to do in this case? Most often, having found this in a company, you should not take rubles away from developers and lower their salaries (even if indirectly), but be puzzled by the question "can this be fixed?" And if the answer is “no”, then it is better to say goodbye to the employee “kindly”, because at some point in time he will be dissatisfied with the fact that his salary is not growing, and the rest of the team may have problems with this. If the answer is yes, then you will need a very thoughtful work of both the personnel training department and the team lead. Indeed, in this case, you will have to pump up the employee's skill and do it as gently as possible so as not to hurt his pride and give him the motivation to develop.