Many development teams are confronted with a “bottleneck” problem when too many issues related to different aspects of development run into one, the most qualified specialist. At the same time, less experienced team members do not know where to grow, and what technologies or specific industries for the team they need to go into in order to be more useful for the team. And by itself, when an irreplaceable employee takes vacation or sick leave, the team’s productivity drops significantly, and in the worst cases, it will be almost completely paralyzed due to lack of expertise in any areas.


Today I want to tell you about a method called "Star Map" to systematically simplify the solution of these and other problems, as well as the pitfalls associated with the introduction of this tool, because nothing is perfect, especially when it comes to teamwork.

I will start with the simplest of what a Star Map is and what types of employees can be divided on the basis of their skill set.
')

A little bit about the star map

Immediately, I’ll make a reservation that this term was not coined by me, for the first time I heard it at the training from the Unusual Concepts team and coach Sergey Dmitriev. Something similar also occurred to me in different firms under the name “competency matrix”, but there the tool is more heavy. And not about the history of origin, but about the application further in the article will be discussed.

A star map is a table where columns with important skills / knowledge for a particular team are located horizontally, and employees are vertically. At the intersection of the column and column, each employee sets himself a grade in a simple gradation:

0 = I do not know anything or I know very little
1 = I know enough to manage the tasks on this topic on average, but not an expert
2 = expert, I can not only solve problems on my own, but I’m READY TO EXPLAIN OTHERS.

It is important that by setting yourself a grade of 2 for any parameter, the employee does not simply designate his expertise, but actually subscribes to the fact that he will share his knowledge on this topic if asked. You do not want to explain to others - put 1, even if you are the most qualified guru in this topic. Also, for grades 0 and 1, you can additionally set + or -, depending on whether the employee wants to delve into this technology or chooses to avoid related tasks. For grade 2, it is assumed that a person is ready by default.

Some tips on making and maintaining a map:

• The card should be known and open for viewing to everyone in the department, not just the boss.
  Apart from the fact that this will save the boss from having to constantly act as a router between employees in the spirit of “I know who you need to ask”, the assessment of the skills of different employees will be balanced by the opinions of other employees.
  
• Only skills / knowledge in demand
  It is important that the listed knowledge, such as the intricacies of specific technologies or the specifics of the work of any internal component, are relevant when working in this particular team. If someone knows React or Node JS, and all the components of the department use Angular on the frontend and Java on the backend, then it makes no sense to indicate unused in the star map, this knowledge will not be needed in the foreseeable future.
  
• Limit the number of columns 20-30, not more
  A fairly common mistake is to create a monstrous, exhaustive list of skills for 200-300 points. Of course, it is good if it is there, but most likely the staff will avoid searching in this cumbersome table and simply turn with questions to someone who, in their opinion, knows all the answers.
  
• Detail and revise this map regularly.
  Over time, people tend to forget something due to the lack of practice, or vice versa, to increase their knowledge. Some technologies and components lose their relevance and they are replaced by new ones; compare the list of skills with the tasks that are actually solved in the department, for example, every 1-2 sprints.
  

Types of employees (idealized)

So, the map is compiled, its example is given below, and at the same time different types of people will be considered, depending on their hard-skills. Each of the types in the art prototype has features that you can identify with these employees.

Chuck Norris - these people in your team and you so well identified. They know everything that is required for work, their knowledge on all (or almost all) points is maximum (2). Their authority in the team is extremely high, they are most often approached with questions or problems, because it seems that Chuck Norris can solve any problem. All the review of the code from the first time is perceived by this reviewer as a feat, just as the architectural solution approved by him is not disputed by almost anyone. Whether Chuck Norris likes it or not, but when everything suddenly breaks down / burns / falls on Friday night, everyone else is waiting for a solution to the problem from him. But the main problem is that when this person is always busy, everyone needs it all at once and, if he goes on leave / on sick leave / leaves, everyone immediately starts to experience difficulties.



Sherlock Holmes is also quite an experienced employee, but his knowledge is not so comprehensive. In some areas of interest to him, he can be with Chuck Norris (or even rarely surpass him), while in other areas he is a complete zero. The original Sherlock Holmes was an expert in everything related to detective work, but for example he did not know basic things from astronomy. “I don’t care, the earth revolves around the sun, or the sun around the earth, for my work it doesn’t matter,” such statements often come from the mouth of Sherlock Holmes.

If Sherlock Holmes is given exclusively tasks on his profile, these tasks can be considered as done in advance, and the lack of knowledge in related fields can remain in the shadows for many years. If you remove Sherlock Holmes from the team, the team’s stability will fall as much as his narrow knowledge was needed, and he alone can cope with the project in his native element, not burdened with questions from newcomers. But if, by negligence, to give him a task from an area of ​​no interest to him, it will be carried out for a rather long time, especially since Sherlock Holmes’s pride often does not allow him to address questions to other employees. “To know infinitely much about the infinitely small, necessary in work” is the principle of its development and training.



Van Dam is the so-called “universal soldier”, and when applied to IT, such people are often full stack developers. Full stack developer s in teams with highly specialized back and front often fall into this category. In a single team, there may be no front or back development in principle, then they will not have a full stack, but there may still be Van Dam. They in all areas necessary for their work possess the necessary minimum of knowledge and only in a small area their knowledge is above the average for the team. Often, such people become employees who have been installed on the bugfix and support of a wide range of components and, willy-nilly, they managed to get acquainted with all of them, as well as with the accompanying libraries. The depth of knowledge was often determined by the needs of the department and the complexity of the problem solved by Van Dam right now.

The main strength of Van Dam is that even if you leave him with a couple of less experienced employees, it will still be a full-fledged team, ready to solve any task (albeit slowly). The problem is that this is exactly a team player and highlighting it for an isolated task greatly reduces the effectiveness of the rest of the team and Van Dame himself. If you remove him from the team, then newcomers will suddenly stop solving their tasks just as quickly, and he alone will have to prove himself in a narrow area where half of his knowledge is not needed. “To know infinitely little about the infinitely many things needed in work” is their teaching principle, which in many respects has something in common with Sherlock Holmes, but from the other end.



Piglet - it's just a novice employee. Perhaps this is an experienced developer, recently come from another department or company, with a different stack of technologies. It is possible that he has a deep store of knowledge in areas that are poorly associated with current activities, but more often, everything is limited to just a basic set of knowledge. Piglet likes to ask questions with common sense and can become an excellent specialist if left in a pair with a more experienced employee.



So, what to do with it all now?

Use of a star map (idealized)

We define weaknesses

First of all, go through the skills columns and see that there are at least one 2 and 1 in each column. This means that there will be someone in the team who can solve even a complex task that requires this skill, and there is another a person who insures the first, and if he goes on vacation, if not perfect, but he can do this task. If in any column there is only a couple of units, the situation is worse and someone may be worth sending for additional training. If there is a column with a single digit other than 0, this is already a good reason to sound the alarm, even if it is 2 and the employee’s knowledge in this area is extremely deep. It means that only one person in the department who understands this technology or component should be crossed fingers, so long as his knowledge is not needed when he is on vacation / on sick leave or is about to retire. In the end, this employee can “take a part of the code hostage” and blackmail him with this, but more on that later.

Increasing team stability

Having identified weak points, it is necessary to distribute tasks on the basis of closing holes in knowledge / skills, taking into account the wishes of the employees if possible (remember the + and -, which they indicated their desire / unwillingness to develop something). Even small bug fixes or code improvements can raise knowledge from zero to 1 and close vulnerabilities in the first approximation. Ideally, we will be able to complete the training of beginner team members in the most critical areas for the team in advance, while more experienced employees can share their knowledge. At the same time, there is no question why this is exactly what is being studied, and not another, because everyone can see from the star map what needs to be developed now.

We balance the burden on experts

Usually, employees like "Chuck Norris" answer a large number of questions and deal with a large number of tasks, so they have to wait for a response from them for a long time. Instead of always and for any reason the others turned to them and the tasks were hung on them, everyone around them could look at the star map and choose “ask Chuck Norris” only when it is really necessary. So experienced employees receive unloading from a heap of small issues, and the team actively interacts within themselves among themselves.

Please note that a person with a level of knowledge of 1 in any technology can count on help and ask for advice not only from people with knowledge 2, but also from people with the same 1, because their knowledge most likely contains, in addition to general principles, non-intersecting portions. Theoretically, the holder of knowledge level 2 can ask for help from a colleague with level 1, but this will be required only in fairly rare cases of critical problems where the expert’s skills are not enough and any help is valuable.

But all this happens only in an idealized world, where the team works like a clock, and every person in it is a motivated professional whose interests completely coincide with the interests of the team. This system takes into account only the hard skills indicated in it. Now let's see how things change with the advent of mysterious soft skills and the dark side of each type of employee.

The dark side of every type of employee

A set of technical knowledge does not determine how an employee behaves when communicating with colleagues, and even if everyone in a team is technically perfectly prepared, this does not mean that together they can do more / better than a well-coordinated team of less experienced employees.

The main difficulty with soft skills, in contrast to the hard skills discussed earlier, is that they are harder to test. The formal separation of them in several columns and the open submission to the court of the rest of the team usually goes beyond ethics and leads only to endless swearing and does not give an objective assessment of what is happening to management. HRs often approach this issue, alas, also rather one-sidedly, limiting themselves to formal communication with an employee once a year or no less formally testing the old-fashioned and monotonous dull tests. Even if they are lucky with HR, they most likely do not know the work of the team from the inside, and the staff of the department do not have the competence of HR to correctly evaluate these skills. Probably, the solution to the problem already exists in several variants, but I will not aim at threatening a comprehensive solution to this problem, but I want to start by simply highlighting the fact of its existence.

Consider an alternative, dark version of each type of employee and see how even a single employee with a low value of soft skills is able to turn the entire department's work inside out and significantly reduce overall effectiveness.


Gregory House is a distorted version of Chuck Norris. Exactly as well as his good alter ego Chuck Norris, he knows practically everything that may be required for his work and even more. But unlike the first, his colleagues (and most often subordinates) Gregory House, while respecting his technical knowledge, would prefer not to have anything to do with him. This expert is distinguished by the fact that he morally humiliates and puts pressure on colleagues, using any means to diminish their merits, constant jostling and denial of ignorance of anything. He knows that with his technical baggage, almost any antics and liberties in dealing with less well-titled and reputable colleagues are forgivable to him. Being aware of the stability of Gregory House’s position, he rarely encounters resistance from colleagues and often prefer to just endure or silently leave the company with such an employee so as not to spoil his feedback from a previous job in a showdown.

This type of employee is especially egocentric and in defending his point of view and authority he can go far beyond common sense, because in his view he is the one indisputable embodiment of common sense in a team. “There are two opinions - mine and wrong,” - almost all the discussions about how to solve this or that problem with the participation of House come down to this. Hosted by Gregory House are vast parts of the code and entire components, which House takes all the merits and benefits to his own account, and he pushes all the problems and failures on his subordinates, who even got a couple of lines in my favorite patrimony of our hero. As an example, if the task that a couple of colleagues have been doing together for a week is reviewed by House, then he can cross out all of their work with his work done by him in a couple of days, committing them without reviewing the rest of the team to the master brunch. In a dispute over which particular code will cause further errors and endless corrections, House has an advantage in the eyes of his superiors, he will always find a way to keep the laurels for himself and to belittle / cross out the work of others.

Sheldon Cooper is a distorted version of Sherlock Holmes. As in the case of Sherlock Holmes, whose skill set is extremely narrow-minded, Sheldon Cooper is interested only in a couple of adjacent areas, but his main principle is to consider dust under the feet of anyone who is less technically savvy in these areas than he. The original character from the TV series The Big Bang Theory lived with several friends, scholars, erudite in other sciences, but didn’t even take them closely to their peers and regularly humiliated them. There is a similar situation.



Ostap Bender - the evil version of Van Dama. Whatever you ask him, he seems to have heard about it, knows it and knows how, but in reality he always exposes others as extreme, although to solve problems he always strives to work with his colleagues, on whose knowledge he can parasitize.



Winnie the Pooh is exactly the same as Piglet, little technically savvy, but unlike the first one, he behaves in a team like a real pig, self-confidently making silly mistakes and refusing to admit himself guilty of their consequences, constantly demanding help from the others like what something due. He makes conclusions from his actions reluctantly, repeats the same mistakes several times, while persistently collecting in his memory reasons to accuse the rest of the team members of something in the best traditions of double standards. Sometimes they dig in silence for their problems and prefer to blame others for lack of help later than to tell the team their problem and their work / thoughts on it in time.

The position of the Dark Ones (Sheldon, Ostap Bender, and especially Winnie the Pooh) in a company cannot be called as stable as that of Gregory House, and the longer they stay in the team, the more actively they devote their time to superiors. Winnie the Pooh for their affairs and can leave the company at all, if only information about him is collected from the team, and not 1-2 employees.

"Dark" are served just before those who make decisions about them, and the chief, deceived by serving "Dark", can:

1. do not ask others and make a separate decision (ideal for Dark)
2. not to believe the criticism of other employees, to forgive the “Dark One” for mistakes and ask him to correct (he will disown, throw dust in his eyes and be justified).

Remember that a trial period is one of the tools that you can use, thereby solving the problem before it is exacerbated by the necessity of the Dark One.

The methods of all the dark ones differ little from those described for Gregory House (taking the code as a hostage, belittling the merits / knowledge of others, disclaiming responsibility for mistakes and appropriating laurels), but in practice we will consider them below.

Of course, bad software skills can mean something else - lack of communication, silence on the problem, inability to constructively perceive criticism, inability to get information from colleagues - redundant or incomprehensible questions. This way, an employee with good skills turns out to be wasting a lot of time and from this he buries even more, but at least does not slow down the rest. I think it makes no sense to describe all the variants of the toxic behavior of employees, the dark side of human nature has no boundaries.

Now mentally put a person with low soft skills into a well-coordinated team of employees with normal and good communication skills. Sheldon Cooper shows himself most comprehensively here, because he has both the skills for which he needs help from the others, and those for which he is considered an expert and could answer colleagues ’questions.

One saboteur in the field, a stranger among his

How will the interaction of a toxic employee with other colleagues, if he is the only one with low soft skills in the team?

It is worth remembering that for such an employee the priorities of the sprint do not exist, there are only his own tasks — the priority ones — and everything else that does not matter to him. When Sheldon / Bender gets any task for which his skills are lacking, he is likely to plunge into a state of almost continuous call with Chuck Norris. A win-win tactic: if he copes with his task, then he will do a good job and will take the laurels for himself, and if not, he will simply spread his hands "even the help of Chuck Norris did not help, I am not guilty."

He dismisses requests to colleagues from Sheldon / Bender under the auspices of development of independence in them, also blocks Chuck Norris from answering requests from other colleagues for help and thus increases the likelihood that by the end of the sprint his task will be better than everyone else. In moments when Chuck Norris still refuses to help Sheldon / Bender, he switches on parasitizing on others and most likely it will be Van Dam or Sherlock Holmes, if his specialization is good enough. At the same time, the probability of criticism and clean-up is higher in the case of the interaction of a toxic employee with Holmes, as a less commanding player, than with Van Dam or Chuck Norris. Chuck Norris in the general flow of questions to him may not pay any attention to the fact that he has to advise one colleague more often than all the others. Especially since the Sheldon questions are still more advanced than the usual questions from beginners. Van Dam, too, by virtue of his broad outlook, will not blame Sheldon Cooper for not knowing anything, answering his questions, because he himself is not perfect. But Sherlock Holmes, a connoisseur in his field, will most likely criticize Sheldon Cooper's incompetence and unwillingness to solve his problems on his own more reasonably. Therefore, the toxic Sheldon is likely to be reinsured and in the event of such risks he will gather evidence that help did not help him very much and he came to everything himself, and Sherlock Holmes simply distracted him.

What will happen at each status rally and at the end of the sprint?



The tasks of Van Dam, Chuck Norris, Sherlock Holmes and all the Piglet novices are delayed in time and only Sheldon Cooper, the only hero in this whole apocalypse, has time to go or is ahead of schedule and is happy with everything unless he is criticized. In retrospect, Sheldon will downplay the participation of others in his success and remind others of organization, because who should be responsible for the problems of other people, if not themselves, is Sheldon? If the team is not dismissed for some time and the situation repeats regularly, then our hero, having earned enough karma on other people's heads, will feel the time to shuffle before the exposure and ask for other activities. There, the situation risks repeating.

Toxic leader and well done for yourself

It is also interesting that if Sheldon is placed in the conditions when he is the most experienced employee in the team, then he, on the one hand, will regularly send inexperienced colleagues to solve problems on his own instead of help, while the management will complain about how much time he takes these unfortunate fools. The tactic “any success of a team is my success (even if I have no relation to it), and any failures are not my problems” will become the most basic in the behavior of such Sheldon / Bender.

If suddenly Sheldon turns out to be alone in any activity without a team, the only one responsible for the result, then he is most likely to show himself worse (after all, there is no parasite on anyone) and he will turn into an ordinary employee, just with a set of hard skills. If the research task, Sheldon blames the technology and the field of study for its failures (to prove the inconsistency of such accusations, another expert of the same technology is needed, but it is not, otherwise the task would not be given). If the task is to implement business logic, the blame will be called, for example, the neighboring department, which is developing the other part, as well as the business analyst, testers and all those responsible for the infrastructure (servers, accesses, etc.). In general, adjacent links in the general chain of solving the problem, with a reputation in advance in the eyes of the authorities in the past incidents of past incidents.In this case, the opinion of Sheldon will have weight, because he coped so well with the tasks in the previous team.

Meanwhile, the rest of the team, from where they pulled this splinter, things are starting to get better, despite the seemingly decline in the number and overall level of hard skills. Because there are less disputes, undercover intrigues, there is a more balanced exchange of knowledge, no one pulls the efforts of the whole team without a compelling need.

A spoon of honey in a tar barrel

This situation is often faced by chiefs who judge employees solely on their knowledge and technical skills, ignoring their bad reputation and inability to work with people. It would seem that a dream team has been assembled, where everyone is, if not an expert, then at least an expert in several areas related to the work ahead, everyone has successful experience in other teams behind their backs. But the work begins and everything breaks off like a chain: two main specialists cannot agree on the technical details and the technology stack, a couple more employees have dug into their tasks and each status rally can hear the same “continue to work on task XYZ” without of any visible progress, and the only newcomer still can’t even fully tune up his or her working environment.

According to the results of the sprint, the usefulness of the team’s work tends to zero, everyone with everyone in continuous confrontation and especially dissatisfied with the scrum master, partly deserved. Of course, this state of affairs testifies to the ineffective work of the team, and hence the scrum master, as the main person responsible for this indicator, but the main conclusion: a high arithmetic average for technical skills in a team does not guarantee its success. A group of more technically savvy professionals may even be far behind in the productivity of a few well-coordinated TEAM motivated employees with average skills.

If there are several toxic employees in a team, then adding there a couple of people with a more sensible approach to communication will most likely lead to their quick burning out and can affect the rest of the team only if there is public support from the authorities, and even then the snake can unite to get rid of them or transformation in their own kind.

For proper organization of work requires considerable patience and the ability of the scrum-master and the desire of all others to develop, therefore, scrum and agile are gaining momentum.
What to do with it all?

The solution of the problem that works perfectly for all cases does not exist, some methods will work for some teams, others for others, but here are some ideas for solving:

• 
  
  , , , 2 1. . - , .
  
• 
  
  , , , , .
  
• 
  ( , ) . - , .
  
• ( )
  
  , , « , 50%» . , , , . .
  
• , .
  , . , , , . . , .
  
• .
  
  , , , .