And who is in your gang?

    It so happened that in the companies where I worked, I loved all sorts of tests from the arsenal of HR. All - and managers, and ordinary performers, chased through these tests.

    Tests, as a rule, determined the type of personality in relation to professional activity - what a person is most inclined to, what is easy for him, what activity makes him tense, and what is better not to take at all.

    To our surprise, we found that different tests reveal approximately the same tendencies. If one test showed that a person, for example, the soul of a company, a shirt guy, then the rest of the tests give similar results.

    Probably, there is nothing strange in this, because the tests are built according to the same principles, and they divide people approximately into the same types of personalities, invented by scientists of the last century.

    But for me personally, this convergence of results helped to believe in the types of personalities, and their influence on the professional activity of a person. Besides, I had the opportunity to observe people with “portraits” known to me for several years, and the correctness of the characteristics was only confirmed.

    I will not talk about the tests themselves - this information is full on the Internet, and your HR, if you ask, will gladly send you a dozen.

    I wanted to tell not about the tests, but about my personal observations : how people with different characteristics behave in a team, what roles they perform well, and what they should not take in, in what work and at what moment it is better to use (in a good sense ).

    I will tell you mainly on the example of programmers and system administrators. Sometimes I will go beyond the established limits, because There were no several types of personality in the IT team at all, but they were walking in neighboring departments.

    Coordinate system

    I will tell you on the example of Belbin's team roles - personally this test seems to me the most successful. Not too many types, it is difficult to get confused, while there is a lot of information on the Internet, and it is not difficult to pass the test - for those who want.

    So, the Belbin test divides people into types, according to the roles in the team:

    • Coordinator (Coordinator) - one who knows how and likes to manage at the operational level;
    • Motivator (Shaper) - one who knows how and loves to move work forward, roughly speaking, “pushing” people with positive and negative motivation;
    • Team Worker is one who can rally a team (mostly aimlessly) to be a friend;
    • A diplomat (in a different way, a Provider, Resource Investigator) is one who can interact with other teams and the environment in general;
    • Idea Generator (Plant) - one who knows how and loves to invent new ideas in all aspects of the team’s work;
    • Analyst (Monitor Evaluator) - one who knows how to analyze options, look ahead and see errors;
    • Implementer - one who loves to just do what he is told;
    • Specialist (Specialist) - similar to the Contractor, but well understands specifically selected area;
    • A Finisher (Completer Finisher) is one who can and loves to organize the completion of cases.

    According to the test results, usually, a person has 2-3 clearly defined roles, rarely one, very rarely, not one, that’s all average. Usually the blurring of the result indicates unfair filling.

    So go out one by one.


    Specifically for programmers, the role is not very useful, because it is not always, not every day necessary. The coordinator is well able to deal with a crisis situation in a short time.

    For example, the server fell. Go iron, or virtual, or applications. Well, what is it, all of your own - an application server, such as 1CN, for some reason, gobbled up all the memory, the entire processor and the console hung.

    It seems to be okay - with rare exceptions, data loss will not happen. But it scares, stops, and makes one blunt in such a situation - time trouble. There is no time, little people run around with their eternal “aaaa, I have a car for loading!”, Or it is necessary to turn in a profit tax after 2 hours - it doesn't matter. Karkushi and clickers will always be there.

    So, this situation is ideal for using the coordinator. He quickly takes matters into his own hands, begins to give clear, short instructions, usually - on the case. Everyone else needs to just shut up and perform, and then everything will turn out.

    Note that the coordinator does not work because he is the smartest, or the most experienced. He just does not get lost like the rest.

    If you turn off time trouble - for example, drop the server in the New Year holidays, when there are no people, then any dude from the team can handle the situation. But in time trouble, the coordinator is the best at it.

    Yes, the important point is that the coordinator copes well precisely with guiding the problem-solving process, and not with the solution itself.

    The coordinator, at first glance, most of all looks like the guy we used to call the leader. We had a lot of coordinators among the managers, and they were all happy - hey-gay, even the test confirmed that we are the leaders, this is direct our personality type!

    But, alas, the coordinator is rather a dispatcher, a foreman for the distribution list, an office manager, etc., well, you understand. Let's just say, this is the lowest level of control when you give orders directly, and for a very short period of time - a maximum of one day. What, in fact, was confirmed with time.

    In normal, non-crisis time, a coordinator among programmers does more harm than good. Begins to distribute obvious instructions, change priorities on the fly, like “so, run down help Lilya, she is beautiful”, “hey, drop your OneScript and close the month!”, “So, let's show progress, 15 minutes have passed.” It is necessary to make it clear in time for this dude that it is not necessary to climb to steer what works. A crisis will come - and then take the reins.

    The horror, of course, if the programmers got a boss with this type of personality - then, as they say, you run around and ass in the soap (idiomatic expression). I had such a boss, I had enough for a month and a half (or I don’t remember him).


    This, in my opinion, is the most useful role in the team of programmers. A motivator is a person who can move other people forward.

    He can inspire, order, can manipulate, challenge. The main thing, probably - he knows how to find the right words for a particular person. Because he is either a good psychologist by nature, or he has learned something like this, or just a devilish devil.

    To move forward and work, and the development of the team, and the self-development of a particular person, in time giving him information or forcing him to think about something outside the context of work.

    Why is motivator the most useful guy for programmers? Because, anyway, we're lazy slugs a little awkward.

    But the trouble is that among programmers and their supervisors such guys are extremely rare, and from the outside it is rare that programmers come to encourage. Customers who stomp their feet and put deadlines are not motivators, but, as a rule, latent parasites .

    Among all those who were digitized in Belbin, only two people were strong motivators, and all were outside IT. Therefore, I have no examples of natural motivators from programmers.

    But there is good news. Motivator is something you can learn. So cool, like natural ones, it is unlikely to succeed, for one simple reason - they are interested in motivating , but we will have to do it through force, at least at first.

    I studied for a long time with natural motivators, I managed to acquire some skills. Compared to those guys, I, of course, was a hoe, but in the midst of programmers with a beer he pulled.

    Pro motivator skills are well and written a lot in books on applied psychology, emotional leadership, and leadership in general, and in any non-fiction, such as Transurfing.

    Personally, my opinion is that at least one person in a team must necessarily become a motivator, at least a little. You will have to try for it, but now. You can be comforted by the fact that motivation skills are very versatile, and their acquisition will make the right contribution to the dismissal kit.

    Team soul

    Personally, this team soul seems to me the most useless guy for programmers.

    This is the guy who calls everyone to drink beer on Friday after work, or in the summer on a hike, or starts talking “for life” while working, or the first one shouts, “Guys, let's go and eat!” At 12-00.

    I don’t know, maybe these are some preconceptions, but such a programmer (and he was in our team) more infuriated me than he put together with the others. I will not insist, but it seems to me that it is wrong and harmful to forcibly mix personal and working.

    It’s fun, of course, but it’s bad for the work - and we came to work, sort of like, work. If I want to drink beer, then I will find with whom, and I don’t need a reason, and I can handle the organization of get-togethers somehow.

    There were many such "souls of the company" before, in factories, in villages and small towns. Thanks to them, there are always two value systems in the team - professional and household, and they almost always conflict.

    If you work well and a lot / efficiently, then you drop out of the household value system - you don’t drink tea from 9-00 to 10-00. Accordingly, and vice versa - the one who knows the most jokes, stories about fishing, and brings the most delicious cakes from home - is rarely the foremost production.

    But here, I repeat, my personal opinion. Actually, like everything stated in the article. If you like the shirt, the guys in the team - on health. I do not like. Therefore, I limited the length of their fishing stories :)

    Motivator is more important for the team.


    The translation is stupid, in the original it is called "resource investigator" - an expert on resources. In a team of programmers, especially implementers, an extremely helpful guy.

    A diplomat is a person who is interested and easy to build external relations with respect to the team. In our reality, these are relations with users, customers, owners, decision makers, etc.

    Especially such a person is irreplaceable, as you understand, on introductions - where you need to spend a lot of work with the external environment. This is especially important not on franch introductions, where the relationship is, so to speak, for one night, but in active fix teams that develop the corporate information system of the enterprise at a normal pace.

    Because the long-term success of the team, one way or another, depends heavily on the external environment. You can be the coolest super-duper team, but if your friends are only Lilechka from the accounting department and Serega from the sales department, and the rest of you are considered a bunch of self-satisfied morons with a horse's salary, then this holiday will not last.

    We were lucky - there were as many as two diplomats, so to speak, of different levels.

    One is a specialist in horizontal relations, who quickly made many connections (in a good sense of the word ... although, who knows) with unburdened high-level employees in almost all departments. Not that they became direct bosom friends, but they responded almost joyfully to adequate requests for help - they wanted to help a good guy. We, as a team, brazenly used these connections if we needed it for implementation or change.

    The second is a specialist in vertical ties, pointing up the stairs. This guy had consciously built a fairly stable direct channel of communication with the top - the owner, director, top managers.

    Especially helped contact with the owner and director, because with it, it was possible to have a very significant influence on senior and mid-level managers, who are often a brake on implementation and change.

    It turns out that middle managers were unlucky most of all - they came under pressure from above and below, from two overly annoying resource investigators.

    Idea's generator

    This is a person who likes to come up with ideas. Ideas are his product, the result of which he is proud. It doesn’t matter whether someone implements this idea or not, it’s enough for the generator to come up with an idea and voice it - and he thinks he has worked well and fulfilled his mission.

    There are a lot of generators among programmers, because our profession is creative. A generator programmer working on fixes in a typical company — such as a factory or wholesale business — can, if you expand your horizons in related business areas, go beyond IT and make an impressive career breakthrough. The reason is simple - there are very few generators of ideas among the non-creative professions, so in related areas there is, physically, a lack of high-quality ideas.

    Ideas such as “the chief accountant invented the EDI to connect”, or “financials invented a transfer to the FIFO in the management account”, or “The logistics director invented the WMS to implement”, or “The director of commerce lit up the introduction of CRM increases sales by 10%” - bullshit alas Formally, these are ideas, but their quality is zero.

    A generator programmer is able to invent high-quality application ideas, because, no matter how trite, he is a programmer. Judge for yourself.

    If, for example, an idiot (not a programmer) is allowed to formulate requirements for an information system, then his ideas will feed After all, have you heard, at least once, the idea of ​​a “big red button” (is it still green)? More often, ideas of idiots begin with the phrase “You know how to be alone…”, well, there further meaningless fantasies begin, such as turning on a computer in the morning, drawing round forms, working from a mobile phone “like on a computer” (= in a thick client), staff manage through exoskeleton, etc.

    All these ideas are a meaningless set of letters that you shouldn’t say, for one simple reason - they are not realizable, and therefore are useless. Well, like the idea of ​​"make peace in the world." Such ideas are uttered by idiots only for one thing - to be spoken.

    The generator-programmer has one key difference - his ideas are context-sensitive. Because he is a programmer, especially if he also has 1Snik, and he always has something in his head? Platform restrictions be they amiss .

    Platform restrictions sit in the head, as a coordinate system, forcing to remember what is possible and what is not. Of course, these restrictions are constantly expanding - and the platform seems to be evolving , according to the looking-glass , and the frameworks external to 1C have become firmly established in practice, but the context is always defined.

    Of course, there are always new technologies, blockchains, artificial intellects, and all kinds of opensource. But if you ask the control question “What are modern IT technologies capable of?” To the programmer, he will answer “to many things, but they still cannot dohera, go and drive in the invoice and do not interfere with OneScript.” And if you ask the same question to an idiot, he will answer "For everything!".

    Coming back to going beyond IT. Now you understand why the ideas of a programmer who figured out, for example, in logistics, would be valuable? Because he will know the restrictions, and the idea expressed by him has already passed (in his head) a check on the restrictions. Although, of course, in the end there are questions like “here I’m just not sure that this is possible, you need to google and smoke a manual” :)

    And now we return to the team of programmers. The generator is very important to them. First and foremost, its greatest value is non-standard solutions within the constraints . The generator will help to avoid, for example, thousands of lines of govnokod, by inventing a small solution for a whole class of problems, on something like a layout.

    Again, custom solutions are not necessarily something out of the ordinary. Sometimes only the generator will see the possibility of using a standard mechanism where others see only the new kilometer of code.

    But the team with the generator can be full of problems.

    First, the generator is a daffodil. If he gives an idea, it must be liked, otherwise he will be seriously offended. Because he, poor thing, tried, he thought, he did not sleep at night, but here - a cold silence in response.

    Secondly, the generator in the team must be one . If there are two of them, it will be a nightmare - they will surely start “to be measured by ideas”, to become depressed and depressed if the second has invented something more abruptly. No, not so - it will be discouraged because they supported another idea.

    If there are two of them, you will have to learn the rules of living together.

    Thirdly, the generator must be recorded. Better, of course, to make him do it himself. Because the generators have a trite memory, and if you do not write down the idea, then he will come up with it sincerely the second time.and you will again have to like and admire. And if he doesn’t record, but he remembers, he will remember for a few more years - aha, I told you, and you ignored, you never listen to me, blah blah blah.

    But everything is not so bad. Generators are quite capable of growing up and becoming adequate. It helps, oddly enough, the already mentioned record of ideas - somewhere in the information system. When an idea is written down, the generator releases it and stops worn with it, as with a written bag.

    But the main thing will happen later. When the generator returns to the previously recorded idea, he himself, the first, will say that the idea is lazy. Because, if this is a normal generator, and not lazy to write down, the list will be large - hundreds, thousands of ideas - and there will be no point in clinging to them, you can safely cross out the marriage. Because it's not scary - a million more ideas will come to mind.

    Well, do not try to convince the generator that "the idea is nothing, this is the result of production." He has an iron counter-argument - “well, come on, try to come up with an idea yourself, and I will program and issue it in production”. The torments of creativity of the non-generator are not worth it, and even this brute will hang around and laugh.

    Such things are better just to let go - to each his own.


    It is also called the "critic". This is a dude who knows how to competently consider decisions, ideas, processes, systems, and make verdicts.

    For example, he can well predict the results of the changes. In our 1S practice, this is important, you know yourself - you need to understand how changes in one metadata object can affect another object.

    There are quite a few such guys among programmers, they are not in short supply. Probably, an analyst is generally a common personality type for all engineering professions.

    In teamwork, it is important and useful to ask for the analyst's opinion. He, like all the types previously listed, is interestedanalyze and criticize other people's ideas, suggestions, plans and goals. Therefore, do not worry if you give him something to analyze - for the analyst it is a thrill. Of course, if it’s not about the two revolving shells that are uploaded to Excel, between which you need to find differences.

    The analyst complements the idea generator well if they are both adequate. One comes up with the idea, the second analyzes it. Both in the case, no one is hurt, everyone is interested . This can be turned into a game.

    The analyst in the team of programmers is well suited to the role of a scrum master - a person who oversees the work of the others and sees what programmers are blunt and lose time on. He manages this quite easily, because finding a loss for the analyst is a thrill, because loss is a mistake in the system. Favorite dish analyst.

    True, the analyst will only get half a scrum master - the one that saw the problem. How to solve it, the analyst does not come up with - here you need a generator. And then the analyst will criticize, try to solve the problem, find inconsistencies in the interface, inform the generator that he will come up with something new, etc., ad infinitum, stop someone else , iteratively.

    There are two extremes in analytics that need to be followed.

    The first is perfectionism and excessive dedication. If you do not set restrictions, it will analyze the location of elements on the form to infinity.

    The second - do not let it to the system, which is almost in production. The analyst doesn’t care that you have deadlines and nerves there at the limit, he will stick his nose at the flaws, “which are obvious as you don’t see.” Even if it is the same bit down the bindings on the form. Submit to analyze the next project. Or let the soul of the team bring him to the canteen :).


    This is the most common type of personality - both among programmers and among employees in general.

    This is the person who will do what they say. And that which is not said will not be done.

    This formula describes well its advantages and disadvantages. If the performer correctly, in time to set the task, then he will fulfill it with a high probability. Well, if you did, but there is no next task, then what? That's right, go on blunt on facebook. Or in the canteen with the soul of the team.

    Artists love instructions, plans, schedules, processes, systems, and all that jazz. It is they who form the mass that happily and meekly helps build hell - because they were told to do so.

    At the same time, performers are the best environment for introducing changes. For example, to move programmers to scrum. It is clear enough, consistently to explain that now the task is not there, but here, on the board, and they have no deadlines anymore, and you need to figure out not the end of the task, but until the end of the week.

    And they don’t really care, because they have a clear and understandable coordinate system at work - if you do what you are told, then you are a good fellow . This is what should be used.

    Sometimes, of course, such programmers get beside themselves - they need to chew everything, the task, the process, where to go, and with whom to talk, and what to read, and where the files are with the remnants. But they are furious if you do not know the type of personality. And when you know - everything, of course, here is such a dude, and you should treat him that way.

    The worst thing in the world is the filth that performers in this world do - they become leaders. After all, in order for the performer to lead, someone must lead the performer. Do not strategically manage, giving goals for a year, but right every day - set tasks, under the entry in a corporate notebook, timelines, explain details, designate resources, etc.

    And then this executive director goes to his subordinates, and the chewing of snot begins. No, how to do something yourself, the performer still somehow understands, and how to delegate it to his subordinates, and even keep track of the performance - ahhh, better shoot me.

    The typical behavior of such leaders is “it's easier for me to do everything myself.” In fact, easier because they can do, and not to lead. And the problem is not in the subordinates, but in the manager - as they say, I apologize, “you do not want to be fucked up, do not torture me.”

    Of course, if someone once writes a normal instruction “how to manage a department,” then the executor will succeed. But it will not be a performer, but a dispatcher.

    And so - nothing, good guys. If you know how to cook them.


    I used to think that a specialist is that same performer, only a highly specialized one or something.

    But when it turned out that one of my subordinate sys.admins was an expert, I finally realized that this guy was not right.

    A specialist is a person who normally, with interest and enthusiasm, solves problems only in the field that he has chosen , and in which he is really an expert.

    There is no question of any performance. But, unlike the performer, there is enthusiasm.

    For example, we have a specialist in server hardware and software (both Windows and Linux). If you have, God forbid, you have a serious task of setting up servers, and the task is not ordinary, but important for the company - for example, eliminating vulnerabilities - this guy will sit in the server for days, without breaks and weekends.

    Just because it is interesting to him - to solve problems according to his specialization.

    And all the other tasks he will solve carelessly. Or, as they say about so many system administrators, "as if he’s piled on his pants." There is no question of any sense of execution, discipline, timing, or quality. Did - and that is good.

    And, unfortunately, or fortunately, such specialists are valued precisely for their “specialism”. Because the solution of a task that fell clearly in the circle of interests, on weekends and nights, in the value system of almost any manager looks like a serious commitment to the company.

    Such approaches have long enraged me. I understand, it is interesting to you to dig with the server, but, damn, someone also has to change cartridges, and sometimes you have to lay a twisted pair.

    But specifically in our case, the solution was found by itself - in connection with the extension, they took an assistant system administrator, lower qualifications, but - about happiness - the performer. And that's all, order and harmony have come in all matters that the main sysadmin did not like. And finally, he had time to dig deeper into the servers, buy and set up a second tsiska, auto-switch to an Internet backup channel, pick up vpn between offices and ooooo, there was a huge list that he himself wrote and was happy to do.


    This is the most elegant personality type, but I have to upset it - I didn’t see him among the programmers, this wasn’t in our team.

    But there was one bright, rich, natural finisher among the leaders parallel to me. From him and write a portrait.

    A finisher is one who knows how and likes to bring things to the end. Cases are both small tasks and big projects.

    No one in the company could do so long projects like this man.

    Judge for yourself. During my observations, a person fell several times to supervise projects whose duration ranged from 6 to 24 months. Good, large projects, with large budgets, diversified.

    Now guess how missed the person with the actual completion date of the projects? 1 day maximum ! It is not joke!

    Moreover, there were no podgadivany, scrum tricks, reducing requirements, spreading tasks over time.

    First, when the person was put to lead the project, he was immediately told the time - exact, up to the day. And no plan, just a goal.

    The person, without fail, made the most complete and detailed plan, budget, indicated the performers and resources, the volume of outsourcing. All agreed, of course.

    And he did. Just in time, all points of the plan. It is clear that there were deviations inside the project - something was delayed, somewhere the outsourcers failed, or the cash gap suddenly interrupted funding and, accordingly, some work or purchases. Like everyone else, in short, it's life.

    But what is important is not what happened, but how the manager reacts to it. And this dog, the finisher, differs from us, ordinary loafers, in that it will always find how to return to the schedule ! He doesn’t even have a thought that by arising - by objective, external - obstacles one can hide behind, otmazatsya, renegotiate the term.

    Its (finisher) key competence is to always understand what needs to be done and what will lead to the finish. The finish is work done on time.

    I sincerely admire this competence, because I have not yet learned this. But I understand the obvious disadvantages.

    The main disadvantage is a permanent, pipelined surrogate production.. Above, you have seen that a person receives a goal, and turns it into a task list, from which he almost never retreats. This approach is the main breeding ground for the surrogate.

    For the finisher, the purpose of the project, its meaning and usefulness do not have any meaning at all. All that matters is the right finish. He kicks from the fact that he hit like a shooter at a target . Well, or as in a joke - kayfuet, when he ran behind the bus, and managed to jump on the bandwagon. And then he asks - what is this number?

    A minor, but also an important minus - the finisher is scary, constantly and painfully endures all brains. If the finisher needs to do a project, and you, God forbid, stand in his way - do not expect mercy. Whatever your position, reputation, authority - the finisher comes to the president, but you will do what is necessary for his project. You signed, or for the first time you hear about his project - take it out and put it down.

    But the finisher is tricky, if adequate. He will give you and all the brains while the project is going on, and then, at the end, he will come, hug, kiss, cry and say that it is not he who is bad, but the evil will of Saruman drove him through the steppes of Middle-earththe director made, and you are his best friend, and he didn’t want to shout at you and complain, just stood the question of life and death, blah blah blah. And forgive, where to go. Until the next project.

    Therefore, I personally did not learn anything from this particular finisher - I don’t like the methods. But the goal - to learn how to do projects on time - I like.

    My gang

    Anticipating the question “what is your profile on Belbin?”, I will answer: Generator of ideas + Critic + Diplomat. I can come up with an idea, I can trash someone else, I can do it with someone else’s hands. I work slowly, badly and only from under the stick.

    Having understood this, I drove out my small team using the Belbin test, and we redistributed responsibilities, replacing the missing competencies and skills.

    The team had, besides me, 4 programmers. The three had a prominent role of the Contractor, so all duties beyond its scope were removed from them. They began to communicate less with customers and users, because not diplomats. And I, and they themselves, stopped tormenting themselves, squeezing ideas out of themselves — that was my job.

    One of them turned out to be the Soul of the team, so he became something like a mediator - he extinguished conflicts, convened everyone for lunch and pobohat in the weekend.

    But there were gaps. For example, lack of coordination, none of us had this role. Therefore, we simply replaced this role with automation and prioritization techniques like this . In fact, they used the role of the Idea Generator and the Contractor to invent and automate a method that replaces the coordinating person with a coordinating machine.

    The same was done with the role of the Finisher - automatic balancing was added to the system of priorities, depending on the degree of completion of the project. I wouldn’t say that the megakruto came out right - the aunt from the article did better, but, on the whole, he did it.

    But the role of the Motivator had to be mastered by me. The experience is also valuable, because, it seems, it turned out. This will be a separate article.

    After all these modifications, we were no longer called “programmers”, “information technology department”, etc. - we became a gang. It was not we who called ourselves that way, but one depressed financial director who was not able to get through his stupidities through our all-round defense.

    The main thing in the Belbin model, in my opinion, is to accept, understand and adapt. If there is not a single Idea Generator in the team, then it’s not necessary to fantasize that “yes, we only will, we will come up with so many ideas!”. If, damn it, there is not a single Contractor, then in general not a damn thing will work out - everyone will lead and motivate each other, but there will be no one to work. And if there is no Coordinator, then there will be a lot of senseless, useless, or even harmful work that nobody needs.

    Also popular now: