Tough and flexible IT skills: everything is more and less serious than I would like to think
Recently, I often have to observe a very nervous reaction of IT specialists at the slightest hint that their “basic skills” are devalued, and first of all - in favor of other skills that they have not honed their whole life. This is most clearly manifested in discussions where the so-called hard skills are opposed to soft. This attitude in itself shows how important this problem is. But in the depths of it lies an assumption, which, I think, disproportionately inflates the alarm: no matter how absurd it may sound, perhaps such a harsh reaction is caused by the fact that we take soft skills not seriously. Today I would like to share my view of the situation and suggest a number of steps that could help us all.
One of the most reliable ways to pump people up on the Internet is to assume that soft skills may eventually come to the fore in the IT sphere, shielding hard skills. When I say “jack up”, I mean not just disagreement, but disagreement with a strong intensity of emotions. This heat is a very important indicator.
There is one very reliable pattern that I was able to trace in many situations: the strength of a person’s emotional reaction to a statement can tell a lot about how closely this statement is related to topics that are painful for him. In words, this all seems to be transparent, but as a detection method it works extremely efficiently. Acute reactions lead us to real problems and real threats.
')
(I shamelessly stole this trick from psychologists, and more specifically from psychotherapists: they use it to find out which problems are fundamental to the patient. The general rule is: the harder it is to talk about something, the more important it is would be the same principle can be applied in many other areas, for example,.. if a person is offended when he is credited with some quality or passion - this often means that the quality and enthusiasm characteristic of the group to which they absolutely do not want to be, etc. numerical, although it is detected much similarity.)
In our case, it is of interest that people somehow worry about the value of hard and soft skills relative to each other, and not, say, about economic instability in general or oversaturation of the market with experts, although these two factors also carry a danger for their status.
We can perceive the frequency of acute reactions as a kind of implicitly expressed “public opinion”. From the point of view of culture, this is an important moment - after all, culture is created by the very society. Identifying patterns in conversations and replies on this topic over the past few years, seeing how high the level of anxiety is with discussions, I come to the following conclusion: many people instinctively anticipate that soft skills expect a big boost, but fear from the thought of what consequences it will have for themselves.
If you look from the side, there will be nothing surprising in this sharp rise. The “lonely genius with a difficult character” type is becoming less and less common due to the fact that few technologies are now being created by one person. In my previous work, a significant part of my duties was to lead hundreds, if not thousands, of people to an agreement and support this consensus so that everyone moves in the same direction. It was a very difficult task; Like most IT specialists, I was not prepared for this at all, and I constantly felt that I was only pretending that I knew what I was doing, in the hope that no one would understand me.
When you work in a large team, the resolution of difficulties with communication and cooperation quickly turns into a determining factor for success or failure. Things like “psychological security” and “mutual trust” affect the daily workflow much more than any specific programming tasks. For juniors, they are important for the reason that they determine their quality of life: trying to perform technical tasks among people who can not stand you is both difficult and painful. When you move to a higher level, to create and maintain an atmosphere in the team gradually becomes your responsibility. The profound difference between the positions of junior and senior is in that number: the task of junior is to look for answers to questions, the task of senior is to find out which questions need to be asked. When you cross a certain line, the number of technical questions that correspond to their level of expertise drops sharply, and the wide distribution of various tools - from reliable compilers to the Stack Exchange - means that there are more and more complex questions for which you can get a straightforward answer.
Of course, there always remain the most puzzling problems that are of critical importance and with which inexperienced employees will not cope, no matter how much you throw them at the task - except that if they drastically pump over. Accordingly, we also need to continue to develop and expand our skills. But, developing as a specialist, you will soon find that all these incredibly difficult technical tasks take far from all of your working time. On the contrary, the most fundamental problems for the operation of the system (and the most complex) relate to how it interacts with the outside world — that is, with people.
Interestingly, hard and soft skills overlap each other much more than most people think. When you start to consider your system as part of a larger system in which people function as elements, when you start wondering how people interact with each other and behave, many of the good old systems developed by hard skills not only become more understandable, but also give more accurate answers to questions that are usually attributed to the sphere of soft. Two classic examples are the rules of operation on sites with multiple users and the ranking of all sorts of results. In both cases, the whole point is to translate the "soft" intuitive understanding of what people want into "hard" mathematical expressions.
But even if you do not take those cases when the technical problem itself requires a mixture of soft and hard skills, many of the soft skills that are now in price are directly related to the management of the community. This sphere has historically developed a bad reputation among programmers, because it (again, according to the old tradition) has always worked people who do not understand anything in programming, and, more importantly, those related to it and those who do it, without hint of respect. The reason is that most of these managers left the school of industrial management of the 20th century - and this is the area that gave us expressions like “human resource”. Employees for them - this is extra trouble and waste, the mass, which must be "managed" to maintain high production rates.
This type of “management,” if it can be called that at all, also has nothing to do with soft skills. It was created by people who often thought that they had comprehended the art of working with people, although in reality they did it very badly, in some cases to a pathological degree. The mere fact that people feel a lack of respect from managers should be very alarming. In the end, the job of a manager is to coordinate people and tune in to team work. If they are not able at the most basic level to build relationships of mutual respect between employees and themselves, others should not expect help from them in this regard.
The bottom line is that the soft skills in question are not taken from nowhere. They do not learn from "etiquette lessons" or "get-togethers". They consist of observing people, studying their peculiarities, the ability to understand their needs, even when they themselves cannot clearly articulate what they want - and, accordingly, it is inconceivably difficult to work them out, not any easier than professional skills. Our habit of talking about them as if it were none and not skills, denying them value and taking it outside the professional sphere only hurts us: when the need comes to perform the corresponding tasks, it quickly becomes clear that everything is not so simple and primitive.
- Specialists from our region have been struggling with this problem for many years.
- They do not need to fight again! I'm here to solve it with algorithms !
* Six months later *
- Wow, how is it all complicated.
- What are you saying?
(It reminds me of a story with an Engineer I knew. When his team moved to another building, he said fatal words: they say, organizing the space is easy, he will cope with it, he is an engineer. The results were, let's say, entertaining. Scientists and directors seem to suffer from the same disease: the conviction that all other professions are a trifling matter.)
I think the situation can be rectified in a very “simple” way: start treating soft skills as serious professional skills, value them along with the latter, train people and hire those who have already mastered them - in general, do all that we do. relation to all other fundamental skills.
As a first step, it would not hurt to make sure that we have a common vocabulary to discuss them. It's hard enough to appreciate something that doesn't have a name. Typical tasks that often fall out of our field of vision include: “give everyone the opportunity to have a general idea of what is happening with the project at the moment,” “develop a common vocabulary for basic technical concepts so that anyone can explain them”, “make sure that everyone has the right to vote, and important concerns do not remain unspoken simply out of fear ”and“ make sure that all participants feel their personal interest in the project and consider its success as theirs ”(and this is not all). Typical indicators that we often ignore include: “how often will users experience irritation or other negative emotions while using the product and how will this affect long-term retention?” Or “how the next session goes after negative experiences and how will it affect the overall impression of the product? "
I did not list anything new in the previous paragraph: these are all standard questions in various professional specialties, from project management to user experience research. But if the team as a whole treats them as collateral considerations, rather than key success factors, the case can end in disaster: deadlines are missed; different groups are working on slightly different versions of products that will start to conflict only at the final stage when they are integrated; one of the teams gradually sabotages the product because it does not want it to become successful; users run into some kind of “minor” bug and are horrified (this can lead to anything: from a mass exodus to a lawsuit); customer confidence is fading. I watched with my own eyes how each of these reasons led to the collapse of the project, despite the fact that technically everything was immaculate.
If we treat such things as important and not third-party components of a project, any team member should have a general idea about them in order to be able to at least assess their significance, even if he does not deal with them himself. They should be considered as a basis for individual roles in a team, on a par with front-end, back-end or security, and distributed among specific people.
It's okay if every engineer will not have the necessary skills to perform all these duties. I will say more: I will be amazed if there is a person who can handle the complete list. But making “invisible work” out of them, which is not appreciated by anyone and is not taken into account anywhere, and pretending that the skills that it requires do not exist, we will not achieve anything, only to harm ourselves.
This harm is not only in direct consequences (that is, that the necessary work is not performed), but also in less obvious ones - we have to deal with unnecessary fears. Anxiety, which was discussed at the beginning of the article, is a symptom of what we realize: we lack something crucial, and this missing unknown becomes more and more necessary every day. If we consider what we lack, “not a skill,” but something that some people can just from birth (the most popular applicants are women and party people, it’s good if not at the same time), and others (programmers) are not , from this state of affairs we feel uneasy. After all, it turns out that we are about to be thrown out of work and replaced by some incomprehensible people who will look down on programmers. But if we recognize all these skills as true skills - that is, what people learn and improve (or not improve) all their life, then this is a completely different conversation. And this conversation goes something like this: “Damn, in our team no one knows how [to insert the necessary] and we get out as it should” - that is, it is painfully familiar to anyone who has been involved in at least one project. Yes, people who cope with these tasks best of all usually come from areas not related to programming, this is true - in the field of programming for several decades it has been decided to ignore learning such things. But this does not mean that they will not have the slightest understanding of programming and respect for this area.
Perhaps I will say a commonplace thing, but if a person who is responsible for coordinating programmers or debugging their interactions with users or something else like that, belongs to programmers without respect, he will not cope with the work and should not be hired. “From communication with this person, everyone's hands are falling” - a serious bell, and not just an inevitable side effect of the profession itself.
But it should be noted that this works in the opposite direction: each of the project participants must respect all the skills that are necessary to work on it, and understand them sufficiently to take part in the dialogue. If there is any legal hitch related to the operation of the system, everyone should know the relevant articles. If user research has shown that something is causing them a positive or negative reaction, everyone should take these facts into account when designing. If the delay blocks some types of user behavior, everyone should understand what the problem is. And in the same way, everyone should understand and appreciate the skills of working with people - after all, the system you are building includes at least yourself.
Few observations
One of the most reliable ways to pump people up on the Internet is to assume that soft skills may eventually come to the fore in the IT sphere, shielding hard skills. When I say “jack up”, I mean not just disagreement, but disagreement with a strong intensity of emotions. This heat is a very important indicator.
There is one very reliable pattern that I was able to trace in many situations: the strength of a person’s emotional reaction to a statement can tell a lot about how closely this statement is related to topics that are painful for him. In words, this all seems to be transparent, but as a detection method it works extremely efficiently. Acute reactions lead us to real problems and real threats.
')
(I shamelessly stole this trick from psychologists, and more specifically from psychotherapists: they use it to find out which problems are fundamental to the patient. The general rule is: the harder it is to talk about something, the more important it is would be the same principle can be applied in many other areas, for example,.. if a person is offended when he is credited with some quality or passion - this often means that the quality and enthusiasm characteristic of the group to which they absolutely do not want to be, etc. numerical, although it is detected much similarity.)
In our case, it is of interest that people somehow worry about the value of hard and soft skills relative to each other, and not, say, about economic instability in general or oversaturation of the market with experts, although these two factors also carry a danger for their status.
We can perceive the frequency of acute reactions as a kind of implicitly expressed “public opinion”. From the point of view of culture, this is an important moment - after all, culture is created by the very society. Identifying patterns in conversations and replies on this topic over the past few years, seeing how high the level of anxiety is with discussions, I come to the following conclusion: many people instinctively anticipate that soft skills expect a big boost, but fear from the thought of what consequences it will have for themselves.
What is behind this
If you look from the side, there will be nothing surprising in this sharp rise. The “lonely genius with a difficult character” type is becoming less and less common due to the fact that few technologies are now being created by one person. In my previous work, a significant part of my duties was to lead hundreds, if not thousands, of people to an agreement and support this consensus so that everyone moves in the same direction. It was a very difficult task; Like most IT specialists, I was not prepared for this at all, and I constantly felt that I was only pretending that I knew what I was doing, in the hope that no one would understand me.
When you work in a large team, the resolution of difficulties with communication and cooperation quickly turns into a determining factor for success or failure. Things like “psychological security” and “mutual trust” affect the daily workflow much more than any specific programming tasks. For juniors, they are important for the reason that they determine their quality of life: trying to perform technical tasks among people who can not stand you is both difficult and painful. When you move to a higher level, to create and maintain an atmosphere in the team gradually becomes your responsibility. The profound difference between the positions of junior and senior is in that number: the task of junior is to look for answers to questions, the task of senior is to find out which questions need to be asked. When you cross a certain line, the number of technical questions that correspond to their level of expertise drops sharply, and the wide distribution of various tools - from reliable compilers to the Stack Exchange - means that there are more and more complex questions for which you can get a straightforward answer.
Of course, there always remain the most puzzling problems that are of critical importance and with which inexperienced employees will not cope, no matter how much you throw them at the task - except that if they drastically pump over. Accordingly, we also need to continue to develop and expand our skills. But, developing as a specialist, you will soon find that all these incredibly difficult technical tasks take far from all of your working time. On the contrary, the most fundamental problems for the operation of the system (and the most complex) relate to how it interacts with the outside world — that is, with people.
Interestingly, hard and soft skills overlap each other much more than most people think. When you start to consider your system as part of a larger system in which people function as elements, when you start wondering how people interact with each other and behave, many of the good old systems developed by hard skills not only become more understandable, but also give more accurate answers to questions that are usually attributed to the sphere of soft. Two classic examples are the rules of operation on sites with multiple users and the ranking of all sorts of results. In both cases, the whole point is to translate the "soft" intuitive understanding of what people want into "hard" mathematical expressions.
But even if you do not take those cases when the technical problem itself requires a mixture of soft and hard skills, many of the soft skills that are now in price are directly related to the management of the community. This sphere has historically developed a bad reputation among programmers, because it (again, according to the old tradition) has always worked people who do not understand anything in programming, and, more importantly, those related to it and those who do it, without hint of respect. The reason is that most of these managers left the school of industrial management of the 20th century - and this is the area that gave us expressions like “human resource”. Employees for them - this is extra trouble and waste, the mass, which must be "managed" to maintain high production rates.
This type of “management,” if it can be called that at all, also has nothing to do with soft skills. It was created by people who often thought that they had comprehended the art of working with people, although in reality they did it very badly, in some cases to a pathological degree. The mere fact that people feel a lack of respect from managers should be very alarming. In the end, the job of a manager is to coordinate people and tune in to team work. If they are not able at the most basic level to build relationships of mutual respect between employees and themselves, others should not expect help from them in this regard.
The bottom line is that the soft skills in question are not taken from nowhere. They do not learn from "etiquette lessons" or "get-togethers". They consist of observing people, studying their peculiarities, the ability to understand their needs, even when they themselves cannot clearly articulate what they want - and, accordingly, it is inconceivably difficult to work them out, not any easier than professional skills. Our habit of talking about them as if it were none and not skills, denying them value and taking it outside the professional sphere only hurts us: when the need comes to perform the corresponding tasks, it quickly becomes clear that everything is not so simple and primitive.
- Specialists from our region have been struggling with this problem for many years.
- They do not need to fight again! I'm here to solve it with algorithms !
* Six months later *
- Wow, how is it all complicated.
- What are you saying?
(It reminds me of a story with an Engineer I knew. When his team moved to another building, he said fatal words: they say, organizing the space is easy, he will cope with it, he is an engineer. The results were, let's say, entertaining. Scientists and directors seem to suffer from the same disease: the conviction that all other professions are a trifling matter.)
Good news: there is a way out.
I think the situation can be rectified in a very “simple” way: start treating soft skills as serious professional skills, value them along with the latter, train people and hire those who have already mastered them - in general, do all that we do. relation to all other fundamental skills.
As a first step, it would not hurt to make sure that we have a common vocabulary to discuss them. It's hard enough to appreciate something that doesn't have a name. Typical tasks that often fall out of our field of vision include: “give everyone the opportunity to have a general idea of what is happening with the project at the moment,” “develop a common vocabulary for basic technical concepts so that anyone can explain them”, “make sure that everyone has the right to vote, and important concerns do not remain unspoken simply out of fear ”and“ make sure that all participants feel their personal interest in the project and consider its success as theirs ”(and this is not all). Typical indicators that we often ignore include: “how often will users experience irritation or other negative emotions while using the product and how will this affect long-term retention?” Or “how the next session goes after negative experiences and how will it affect the overall impression of the product? "
I did not list anything new in the previous paragraph: these are all standard questions in various professional specialties, from project management to user experience research. But if the team as a whole treats them as collateral considerations, rather than key success factors, the case can end in disaster: deadlines are missed; different groups are working on slightly different versions of products that will start to conflict only at the final stage when they are integrated; one of the teams gradually sabotages the product because it does not want it to become successful; users run into some kind of “minor” bug and are horrified (this can lead to anything: from a mass exodus to a lawsuit); customer confidence is fading. I watched with my own eyes how each of these reasons led to the collapse of the project, despite the fact that technically everything was immaculate.
If we treat such things as important and not third-party components of a project, any team member should have a general idea about them in order to be able to at least assess their significance, even if he does not deal with them himself. They should be considered as a basis for individual roles in a team, on a par with front-end, back-end or security, and distributed among specific people.
It's okay if every engineer will not have the necessary skills to perform all these duties. I will say more: I will be amazed if there is a person who can handle the complete list. But making “invisible work” out of them, which is not appreciated by anyone and is not taken into account anywhere, and pretending that the skills that it requires do not exist, we will not achieve anything, only to harm ourselves.
This harm is not only in direct consequences (that is, that the necessary work is not performed), but also in less obvious ones - we have to deal with unnecessary fears. Anxiety, which was discussed at the beginning of the article, is a symptom of what we realize: we lack something crucial, and this missing unknown becomes more and more necessary every day. If we consider what we lack, “not a skill,” but something that some people can just from birth (the most popular applicants are women and party people, it’s good if not at the same time), and others (programmers) are not , from this state of affairs we feel uneasy. After all, it turns out that we are about to be thrown out of work and replaced by some incomprehensible people who will look down on programmers. But if we recognize all these skills as true skills - that is, what people learn and improve (or not improve) all their life, then this is a completely different conversation. And this conversation goes something like this: “Damn, in our team no one knows how [to insert the necessary] and we get out as it should” - that is, it is painfully familiar to anyone who has been involved in at least one project. Yes, people who cope with these tasks best of all usually come from areas not related to programming, this is true - in the field of programming for several decades it has been decided to ignore learning such things. But this does not mean that they will not have the slightest understanding of programming and respect for this area.
Perhaps I will say a commonplace thing, but if a person who is responsible for coordinating programmers or debugging their interactions with users or something else like that, belongs to programmers without respect, he will not cope with the work and should not be hired. “From communication with this person, everyone's hands are falling” - a serious bell, and not just an inevitable side effect of the profession itself.
But it should be noted that this works in the opposite direction: each of the project participants must respect all the skills that are necessary to work on it, and understand them sufficiently to take part in the dialogue. If there is any legal hitch related to the operation of the system, everyone should know the relevant articles. If user research has shown that something is causing them a positive or negative reaction, everyone should take these facts into account when designing. If the delay blocks some types of user behavior, everyone should understand what the problem is. And in the same way, everyone should understand and appreciate the skills of working with people - after all, the system you are building includes at least yourself.
Source: https://habr.com/ru/post/347588/
All Articles