Hard and Soft Skills in Tech Sector
In recent years, tech specialists have taken on certain concerns due to the devaluation of their “basic skills” in favor of other skills, which they haven’t been developing throughout their professional life – the soft skills. This issue is most clearly manifested in discussions where the so-called hard skills are opposed to soft ones. Anxiety and nervous reaction of the tech specialists on the necessity to develop soft skills demonstrates how important this problem is. However, the problem is not the harsh reaction, but rather the fact that we may take soft skills not seriously enough.
Wait. What is the problem here?
One of the most reliable ways to hornswoggle people up in the Internet is to assume that soft skills may eventually come to the forefront in the tech sector, displacing hard skills. The emotional response to this statement from the specialists involved in the sector is a pretty important indicator. The strength of personal reaction to a statement can tell a lot about how closely this statement is related to the topics that one considers as important. Overreaction discloses what people see as meaningful problems and real threats. Psychologists use this trick to find out which problems are fundamental for their patients.
In our case, it is surprising that people worry about the value of hard and soft skills in relation to each other, rather than about economic instability or oversaturation of the market with experts, although these two factors also carry danger for specialists. We can perceive the frequency of acute reactions as a kind of implicitly expressed “public opinion.” Taking into account conversational patterns and reaction on this topic over the past few years, seeing how high the level of anxiety is, one can conclude that many people instinctively anticipate that the value of soft skills expects a massive boost, but fear the thought about the consequences it will have for them.
What gets left behind?
To look closer, there is nothing surprising in the growing popularity of soft skills. There are much fewer projects that require an effort of one person, than of many. The majority of modern technologies is a result of teamwork. Many tech specialists face a necessity to build social connections and cooperate with other people in order to conduct the tasks they have. Moreover, many of them need to manage groups of different sizes in order to encourage them working in one direction. Most tech specialists are not prepared to do so, and many do not understand the reason to work this way.
In a large team, solving 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 task. For Juniors, these skills are important as they determine the quality of their life: trying to perform technical tasks working with a team of people, who are in tension with you, can be difficult and painful. When you move to a higher professional level, creating and maintaining a welcoming atmosphere in a team gradually becomes your responsibility. The serious difference between the positions of a Junior and a Senior is in the following: the task of a Junior is to look for the answers, the task of a Senior is to find out which questions to ask. The higher your position in the team is, the less technical questions that correspond with your level of expertise appear and the more general questions, which do not have a straightforward answer, occur.
Interestingly, hard and soft skills overlap much more so 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, many of the good old systems based on hard skills not only become more understandable, but also can provide more accurate answers to questions that are usually attributed to the sphere of soft skills. Two classic examples are the rules of operation on websites with multiple users and the ranking of results. In both cases, the whole point is to translate the “soft” intuitive understanding of what people want into “hard” mathematical expressions.
In essence soft skills don’t come out of the blue. They are not acquired through etiquette lessons or parties. They consist of observing people, studying their peculiarities, the ability to understand their needs, even when they themselves cannot clearly articulate what they want. Working out these skills is no easier than professional skills. Our habit of talking about them as if they were unimportant and meant nothing, denying their value and taking them outside the professional sphere only harms us. When the need comes to perform certain tasks, it quickly turns out that it is not so simple and primitive without certain soft skills.
So what’s the solution?
The solution is quite simple: we have to start treating soft skills as serious professional skills, value them not less than hard ones. Companies should train people and hire those who have already mastered soft skills. Generally, in this case, we can do everything that we do to acquire all other fundamental skills.
To start with, we have to make sure that we have an appropriate vocabulary to speak about soft skills. It is quite hard to value something that doesn’t even have a name. Typical tasks that require soft skills and often fall out of the vision include: providing everyone with an opportunity to have a general idea of what is happening with a project at the moment, developing a common vocabulary for basic technical concepts so that anyone could explain them, making sure that everyone has a voice, and important concerns do not remain unspoken, and all participants understand their personal interest in the project and consider its success as their own.
These are all standard questions in various professional fields, from project management to user experience research, and they all have to do with hard skills. However, if the team treats them all neglectfully, not like the key success factors, the case could end in disaster: missed deadlines, unsynchronized work, sabotage, minute bugs, and mistakes.
If we treat such things as important, rather than third-party components of the 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. 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 not a problem if every engineer will not have the necessary skills to perform all these duties. Moreover, it is highly unlikely that there is a person who can handle the complete list. However, pretending that soft skills don’t exist and are not taken into account in any case, can be harmful to the company’s work.
These harmful consequences are expressed not only directly (that is, the necessary work is not done), but also in a less obvious way when we have to deal with unnecessary fears. Anxiety, which was discussed at the beginning of the article, is a symptom of how we realize the lack of something crucial. If we consider what we lack as not a skill, but something that some people are born with, while others are not, we feel ourselves stuck in a dead end. After all, it turns out that we are about to be thrown out of work and replaced by someone else who is born with these skills. But if we recognize these skills as true ones, which one can acquire and improve, the situation changes. Then we can say: “Damn, in our team no one knows how [to communicate with a client], we have to learn it.” It is painfully familiar to anyone who was involved in at least one project. People involved in programme developing are usually not familiar with a range of soft skills, but this does not mean that they cannot acquire them.
Everyone involved in the project should respect all the skills that are necessary in order to conduct the work, and understand them and their value to a sufficient extent to take part in the dialogue. If there is any legal hitch related to the operation of the system, everyone should know relevant details. If user research has shown that something is causing a positive or negative reaction, everyone should take these facts into account working on the task. 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 yourself.
