And who is in your gang?
It so happened that in the companies where I worked, I was very fond of 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 based on the same principles, and 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. In addition, 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.
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:
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 smearing of the result indicates unfair filling.
So go out one by one.
Specifically, for programmers, the role is not very useful, because not always, not every day is 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's there, all 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 are always 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. All the rest you just need to 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 with the leadership of 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 away, 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 that, 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'relazy 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, 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 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 become a motivator, at least a little. You will have to try for it, but now. You can indulge yourself with the fact that motivation skills are very versatile, and their acquisition will make the right contribution to the dismissal kit.
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 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 with us in the team) was more infuriating than connecting 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 a beer, then I will find with whom, and I don’t need a reason, and I can cope with 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 for the team is more important.
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 indispensable, as you understand, on introductions - where you need to spend a lot of work with the external environment. This is especially important not in French introductions, where relationships are, 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 to be 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 senior positions 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 steady direct channel of communication with the upper levels - the owner, the director, the 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 not so lucky - they came under pressure from above and from below, from two overly annoying resource investigators.
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 normal company — such as a factory or wholesale business — can, if you broaden your horizons in related business areas, go beyond IT and make an impressive career breakthrough. The reason is simple - among the non-creative professions, there are very few generators of ideas, therefore 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 the 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 applied ideas, because, however trite it may be, 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 bash.org. After all, have you heard, at least once, the idea of ​​a “big red button” (is it still green)? Even 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, which one should not even pronounce, for one simple reason - they are unrealizable, and therefore useless. Well, like the idea of ​​"make peace in the world." Such ideas are uttered by idiots for only 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 restrictionsbe 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 platformseems to be evolving , according to the mirror , and external for the 1C framework have firmly entered into 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 delivery note and do not interfere with OneScript.” And if you ask the same question to an idiot, then he will answer “For everything!”.
Returning to go 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, as a result, there are questions like “here I am not sure that this is possible, you need to google and smoke cigarettes” :)
And now we return to the team of programmers. The generator is very important for 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, and 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 came up with something more abrupt. 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 does not write down, but he remembers, he will remember for a few more years - yeah, I told you, and you ignored, never listen to me, blah blah blah.
But all 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 lets it go and stops rushing with it, like 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 reason to cling to them, you can safely delete 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 it and give it to production”. The torments of creativity of the non-generator are not worth it, and even this brute will hang around and laugh.
These 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, the 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 listed earlier, is interested in analyzing and criticizing other people's ideas, proposals, 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 an idea, the second analyzes it. Both in the case, no one is hurt, everyone is interested . This can be turned into a game.
An analyst in a team of programmers is well suited to the role of a scrum master — a person who oversees the work of 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 who saw the problem. And 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 blunt on facebook. Or in the canteen with the soul of the team.
Artists love instructions, plans, schedules, processes, systems, and so on. 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 do not have any deadlines, and you need to figure out until the end of the task, but before the end of the week.
And they don’t really care, because they have a clear and understandable system of coordinates 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 enrage - they need to chew everything, the task, the process, and where to go, and with whom to talk, and what to read, and where the files with the remnants lie. But they are furious if you do not know the type of personality. And when you know - everything, of course, here he is such a dude, and you should treat him exactly this 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, it is easier, because it can do , and not manage. 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 wrong.
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 sense of execution. 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 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 firm.
Such approaches have enraged me for a long time. I understand, it is interesting to you to dig with the server, but, damn, someone has to change the cartridges too, and sometimes you have to lay a twisted pair.
But specifically in our case, the solution was found by itself - in connection with the expansion, they took the assistant's 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 the backup Internet 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 disappoint - I didn’t see him among the programmers, this wasn’t in our team.
But there was one bright, saturated, natural finisher among the leaders parallel to me. From him and write a portrait.
The finisher is the one who knows how and likes to bring things to the end. Cases are both small tasks and large 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 podgadyvany, skryam-tricks, reducing requirements, spreading tasks over time.
-, , – , . , .
, , , , , . , .
. , . , – - , - , , , . , , .
, , , . , , , , , , , ! , – , – , , .
() – , , – , . – , .
, . .
– , . , , , . – .
, . , – . , , . , – , , . – ?
, – , . , , , – . , , – , , . , – .
– , . , , , , , , , , ,
, - – . – – .
« ?», : + + . , , . , - .
, , , .
, , 4 . , , . , .. . , , , — .
, - — , .
. , , . , . , , , - .
— , . , — , , , .
- . , , , . .
«», « » .. — . , , .
, — , . , , « , !». , , , — , , . , , , , .
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 based on the same principles, and 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. In addition, 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 - one who can rally a team (mostly aimlessly), to be all friends;
- A diplomat (in other words, 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 likes to invent new ideas in all aspects of the team’s work;
- Monitor Evaluator - one who can analyze options, look ahead and see errors;
- Implementer - one who likes to just do what they say;
- 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 smearing of the result indicates unfair filling.
So go out one by one.
Coordinator
Specifically, for programmers, the role is not very useful, because not always, not every day is 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's there, all 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 are always 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. All the rest you just need to 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 with the leadership of 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 away, 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).
Motivator
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 that, 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
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, 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 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 become a motivator, at least a little. You will have to try for it, but now. You can indulge yourself with 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 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 with us in the team) was more infuriating than connecting 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 a beer, then I will find with whom, and I don’t need a reason, and I can cope with 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 for the team is more important.
Diplomat
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 indispensable, as you understand, on introductions - where you need to spend a lot of work with the external environment. This is especially important not in French introductions, where relationships are, 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 to be 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 senior positions 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 steady direct channel of communication with the upper levels - the owner, the director, the 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 not so lucky - they came under pressure from above and from 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 normal company — such as a factory or wholesale business — can, if you broaden your horizons in related business areas, go beyond IT and make an impressive career breakthrough. The reason is simple - among the non-creative professions, there are very few generators of ideas, therefore 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 the 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 applied ideas, because, however trite it may be, 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 bash.org. After all, have you heard, at least once, the idea of ​​a “big red button” (is it still green)? Even 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, which one should not even pronounce, for one simple reason - they are unrealizable, and therefore useless. Well, like the idea of ​​"make peace in the world." Such ideas are uttered by idiots for only 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
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
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 delivery note and do not interfere with OneScript.” And if you ask the same question to an idiot, then he will answer “For everything!”.
Returning to go 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, as a result, there are questions like “here I am not sure that this is possible, you need to google and smoke cigarettes” :)
And now we return to the team of programmers. The generator is very important for 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, and 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 came up with something more abrupt. 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 does not write down, but he remembers, he will remember for a few more years - yeah, I told you, and you ignored, never listen to me, blah blah blah.
But all 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 lets it go and stops rushing with it, like 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 reason to cling to them, you can safely delete 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 it and give it to production”. The torments of creativity of the non-generator are not worth it, and even this brute will hang around and laugh.
These things are better just to let go - to each his own.
Analyst
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, the 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 listed earlier, is interested in analyzing and criticizing other people's ideas, proposals, 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 an idea, the second analyzes it. Both in the case, no one is hurt, everyone is interested . This can be turned into a game.
An analyst in a team of programmers is well suited to the role of a scrum master — a person who oversees the work of 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 who saw the problem. And 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.,
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 :).
Executor
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 blunt on facebook. Or in the canteen with the soul of the team.
Artists love instructions, plans, schedules, processes, systems, and so on. 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 do not have any deadlines, and you need to figure out until the end of the task, but before the end of the week.
And they don’t really care, because they have a clear and understandable system of coordinates 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 enrage - they need to chew everything, the task, the process, and where to go, and with whom to talk, and what to read, and where the files with the remnants lie. But they are furious if you do not know the type of personality. And when you know - everything, of course, here he is such a dude, and you should treat him exactly this 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, it is easier, because it can do , and not manage. 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.
Specialist
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 wrong.
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 sense of execution. 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 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 firm.
Such approaches have enraged me for a long time. I understand, it is interesting to you to dig with the server, but, damn, someone has to change the cartridges too, and sometimes you have to lay a twisted pair.
But specifically in our case, the solution was found by itself - in connection with the expansion, they took the assistant's 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 the backup Internet channel, pick up vpn between offices and ooooo, there was a huge list that he himself wrote and was happy to do.
Finisher
This is the most elegant personality type, but I have to disappoint - I didn’t see him among the programmers, this wasn’t in our team.
But there was one bright, saturated, natural finisher among the leaders parallel to me. From him and write a portrait.
The finisher is the one who knows how and likes to bring things to the end. Cases are both small tasks and large 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 podgadyvany, skryam-tricks, reducing requirements, spreading tasks over time.
-, , – , . , .
, , , , , . , .
. , . , – - , - , , , . , , .
, , , . , , , , , , , ! , – , – , , .
() – , , – , . – , .
, . .
– , . , , , . – .
, . , – . , , . , – , , . – ?
, – , . , , , – . , , – , , . , – .
– , . , , , , , , , , ,
, - – . – – .
« ?», : + + . , , . , - .
, , , .
, , 4 . , , . , .. . , , , — .
, - — , .
. , , . , . , , , - .
— , . , — , , , .
- . , , , . .
«», « » .. — . , , .
, — , . , , « , !». , , , — , , . , , , , .
Source: https://habr.com/ru/post/433856/
All Articles