In today's stage of software development, we can observe a diversity of production roles. Their number is increasing, classifications are becoming more complex each year, and, naturally, the processes of selecting specialists and working with workforce potential are also becoming more complicated. Information Technology (IT) is a field characterized by highly qualified labor resources and a shortage of personnel. In this sector, the process of nurturing talent and the need for systematic work with human resources can often be significantly more effective than direct selection through online resources.
The article discusses issues relevant to HR professionals in IT companies: causal relationships in the evolution of production roles, the consequences of misinterpreting the content of these roles for human resource management as a whole, as well as possible options for improving the effectiveness of talent selection.
IT Production for the Uninitiated
Who’s who in IT – this topic is up for discussion on various platforms. It has existed as long as the entire IT industry itself, that is, since the emergence of the first software development companies in the early 90s. For just as long, there has been no unified perspective on this issue, which creates difficulties and reduces the effectiveness of human resource management. Let's try to clarify this matter.
For me, the topic of production roles in the IT field became relevant and interesting from the moment I joined an IT company. I spent a lot of time and emotional energy trying to understand the production process. These efforts exceeded my expectations and costs related to adaptation in processes from other areas: education, material production, small businesses. I understood that the processes were complex and unfamiliar, as, in general, a person is more adapted to the material world than to the virtual one. However, there was intuitive resistance: it seemed that something was off, that it shouldn't be this way. The adaptation process took about a year, which, in my view, is an astronomical amount of time. Ultimately, I developed a fairly clear understanding of the key roles in IT production.
I am currently continuing to work on this topic, but at a different level. As the head of the development center of an IT company, I often interact with students, university teachers, applicants, schoolchildren, and others who wish to participate in creating an IT product to promote the employer brand in the labor market of a new area (Yaroslavl). This communication is not easy due to the low awareness of the interlocutors about how the software development process is organized, which results in a misunderstanding of the subject of the conversation. After 5-10 minutes of dialogue, you stop receiving feedback and begin to feel like a foreigner whose speech requires translation. Typically, among the interlocutors, there is someone who summarizes the dialogue and voices the popular myth from the 90s: "Anyway, all IT specialists are programmers." The sources of this myth are as follows:
- The IT industry is rapidly evolving; in this context, all fundamental meanings and principles are still being formed;
- In conditions of uncertainty, it is difficult to exist; therefore, a person tries to ease their understanding of the unknown by creating myths;
- A person is more accustomed to perceiving the material world than the virtual one, which makes it difficult for them to define concepts that exist beyond their perception.
Attempts to combat this myth sometimes resemble a fight with windmills, as there are several aspects of the problem that need to be addressed. First, an HR specialist needs to have a clear understanding of the production roles in an IT company in both ideal and real manifestations; second, to know how and when the company's internal resources can be most effectively utilized; and third, to identify real methods that will help raise awareness of labor market participants and contribute to the development of the employer brand. Let’s examine these aspects in detail.
The software lifecycle as the foundation of production roles
It's no secret that all production roles in any IT company are fundamentally linked to the software development lifecycle. Therefore, when aiming to conceptually align on the perception of this issue across the entire IT industry, it is essential to rely on the software lifecycle as a universally accepted and clearly understood foundation. The discussion of specific implementation variants regarding production roles lies within our creative approach to the software development lifecycle.
So, let’s consider the stages included in the software lifecycle, using the RUP methodology as an example. These are well-defined links in terms of content and terminology. The production process always starts with business modeling and requirements gathering, and it concludes (conditionally, of course) with user consulting and software refinements based on user requests.
If we take a historical look back to the end of the last century (which, as we know, was a period of 'island automation'), we can see that the entire software creation process was managed by a developer programmer. This is the root of the myth that every IT professional is a programmer.
With the complexity of production processes, the emergence of integrated platforms, and the transition to comprehensive automation of subject areas, along with the reengineering of business processes, the emergence of specialized roles tied to the stages of the lifecycle becomes inevitable. This is how roles like analyst, tester, and technical support specialist come into being.
The diversity of positions illustrated by the role of an analyst.
An analyst (also known as a systems analyst, requirements engineer, methodology expert, business analyst, etc.) helps bridge the gap between business challenges and the technologies used for their implementation. The description of the task setup for a developer characterizes the main function of an abstract analyst. They serve as a link between the client and the developer in the processes of requirements gathering, analysis, and software design. In real-world production conditions, the list of an analyst's functions is defined by the organization of production, the specialist's qualifications, and the specifics of the modeled subject area.
Some analysts are closer to the client. These are business analysts (Business Analyst). They have a deep understanding of the business processes in their field and are experts in the processes being automated. It is crucial to have such specialists on staff, especially when automating methodology-intensive subject areas. Specifically, for us as budget process automators in the government, it is essential that our analysts include subject matter experts. These are highly qualified employees with a solid financial and economic education and experience in financial institutions, preferably in senior specialist roles. Experience outside the IT sector, specifically in the subject area, is extremely important.
Another group of analysts is more aligned with developers. These are systems analysts (System Analyst). Their main task is to identify, systematize, and analyze client requirements to assess their feasibility, prepare technical specifications, and formulate task descriptions. They are knowledgeable not only in business processes but also in information technology, have a clear understanding of the capabilities of the software provided to the client, possess design skills, and thus understand how best to convey the client's interests to the developer. These employees must have a background in ICT and an engineering mindset; experience in IT is preferable. When selecting such specialists, having design skills using modern tools is a definite advantage.
Another type of analyst is the technical writer. They are involved in documentation within software development processes, preparing user and administrator manuals, technical instructions, training videos, etc. Their main task is to convey information about the program to users and other interested parties, describing technically complex concepts concisely and understandably. Technical writers typically possess a strong command of the English language and have a technical background and analytical mindset. For such specialists, the most important skills are the ability to create clear, grammatically correct, detailed technical texts in accordance with standards, as well as knowledge and proficiency in documentation tools.
Thus, we see the same role (and, by the way, the position in the job description) – analyst, but in its various practical embodiments. The search for specialists for each of them has its own peculiarities. It's important to note that these types of analysts must often possess incompatible skills and knowledge within one person. One is a humanities-oriented individual inclined towards analytical work with large volumes of text documents, with developed speech and communication skills; the other is a 'techie' with an engineering mindset and interests in the IT field.
Should we hire externally or grow internally?
For a major player in the IT industry, the effectiveness of direct recruitment from online resources decreases as projects grow. This occurs for several reasons: the inability to quickly adapt to complex processes within the company, and the speed of mastering specific tools is slower than the pace of project development. Therefore, it's crucial for an HR specialist to know not only whom to search for externally but also how to leverage the company's internal resources and which employees to nurture into specialists.
For business analysts, hands-on experience with real processes in the subject area is crucial. Thus, hiring externally is more effective than developing talent internally. In this context, it's important for the HR specialist to know which organizations can serve as sources for this talent pool and to focus on sourcing resumes from them during the recruitment process.
In contrast, filling vacancies for roles such as systems analysts and software architects greatly benefits from internal training. These specialists need to develop within the existing production environment and the specific characteristics of the organization. Systems analysts evolve from business analysts, technical writers, and technical support engineers. Software architects emerge from system designers and software developers as they gain experience and expand their horizons. This situation enables HR specialists to effectively leverage the internal resources of the company.
Intersection, integration, and evolution of production roles
There’s another challenging aspect regarding implementation in the production process — establishing clear boundaries between roles. At first glance, it may seem obvious: the implementation ends, documents are signed for the software to enter commercial operation, and everything is handed over to technical support. This is indeed correct, but situations often arise where the client, having been in close contact with the analyst and viewing them as a 'magic wand', continues to engage actively with them, even after the system is implemented and the support phase has formally begun. From the client’s standpoint, who better and faster than the analyst who set the task with them can answer questions about system operation? This brings up the issue of partial role duplication between the technical support engineer and the analyst. Over time, things settle down, and the client gets used to communicating with the support team, but initially, during the software's operational phase, this 'internal transition' is not always executed without stress on both sides.
The intersection of the roles of an analyst and a technical support engineer occurs when the flow of development requirements arises during the maintenance phase. Referring back to the software lifecycle, we see a mismatch between actual production conditions and formal setups that dictate that requirement analysis and task definition can only be performed by the analyst. A personnel specialist must certainly understand the ideal picture of roles within the software lifecycle, as they have clear boundaries. However, it is essential to keep in mind that overlaps may occur. When evaluating the knowledge and skills of a candidate, attention should be paid to the presence of adjacent experience; therefore, when looking for technical support engineers, candidates with experience as analysts may very well be considered, and vice versa.
In addition to overlaps, there is often a merging of production roles. For example, a business analyst and a technical writer can exist as one person. The presence of a Software Architect is essential in large-scale industrial development, while much smaller projects may do without this role, as developers take on the functions of the architect.
Changes in historical periods in approaches and technologies of development inevitably lead to the evolution of the software lifecycle as well. Globally, of course, its main stages remain unchanged, but their details evolve. For example, with the transition to web solutions and the growth of remote configuration capabilities, a role for software configuration specialists emerged. In the early historical stages, these were implementers, that is, engineers who spent most of their working time at client workplaces. Increased volume and complexity of software led to the emergence of the Software Architect role. The demands for faster version releases and improved software quality have facilitated the development of automated testing and the appearance of a new role – QA Engineer, etc. The evolution of roles at all stages of organizing the production process is significantly linked to the advancement of methods, technologies, and tools.
So, we've looked at some interesting points regarding the distribution of production roles within a software development company in the context of the software lifecycle. Clearly, this is an internal perspective, which is specific to each company. For all of us in the labor market of the IT industry and those responsible for promoting the employer brand, an external viewpoint is particularly important. Here, there's a significant problem not only in finding meanings but also in conveying this information to the target audience.
What is wrong with the 'zoo' of IT positions?
Confusion in the minds of HR specialists, production organizers, and the variety of approaches lead to a wide range of roles, essentially resembling a 'zoo' of IT positions. Experience from interviews and professional contacts shows that people often lack a clear understanding of the semantic load that should follow from job titles. For instance, in our organization, positions that include the term 'analytical engineer' imply that this person is a task setter. However, it turns out that this isn't the case everywhere: there are development organizations where an analytical engineer is an implementer. Quite a different understanding, wouldn't you agree?
Firstly, the 'zoo' of IT positions undoubtedly reduces the effectiveness of staff recruitment. Every employer, when developing and promoting their brand, wants to convey all the meanings that exist in their production in a concise form. If they themselves often cannot clearly state who is who, naturally, they will convey uncertainty to the outside environment.
Secondly, the 'zoo' of IT positions creates huge problems in the preparation and development of IT personnel. Every serious IT company aimed at forming and developing human resources, rather than merely exploiting job websites, sooner or later faces the necessity of interacting with educational institutions. For highly qualified IT personnel, this pertains to universities, particularly the top ones, at least those ranked in the TOP-100.
The problem of integration with universities in establishing a continuous process for training IT specialists arises partly from the lack of understanding among universities about the roles within an IT company. They have a very superficial understanding of this. Typically, universities have several majors with the word 'informatics' in their titles, and often during their admissions campaigns, they emphasize that all these majors essentially refer to the same thing. It seems similar to relying on the popular myth that all IT professionals are programmers.
Our experience of close collaboration with universities shows that the 'Applied Informatics (by industries)' major provides us with personnel for methodology and technical support departments, but not for development. Meanwhile, 'Fundamental Informatics' and 'Software Engineering' produce an excellent talent pool for developers. To avoid guiding applicants down an unsuitable path from the start, it is necessary to 'clear the fog' surrounding IT production.
Is it possible to bring everything to a common denominator?
Can we unify production roles and achieve a common understanding of them both internally and externally to the company?
Certainly, it is possible and necessary, because the accumulated collective experience of all development companies demonstrates the existence of common unifying concepts in organizing the production process. This is a consequence of the fact that there is a universally understood concept of the software life cycle, and the newly emerging production roles (Data Scientist, QA Engineer, Machine Learning Engineer, etc.) are a result of the clarification and development of the software life cycle itself, taking place with the improvement of technologies and tools, as well as with the growth and consolidation of business tasks.
At the same time, it is difficult to unify production roles because IT is one of the youngest and most rapidly developing sectors of the economy. In a sense, this is chaos from which the universe has emerged. A clear organizational structure is neither possible nor appropriate here, as IT is an intellectual yet highly creative sphere. On one hand, an IT professional is an intellectual 'physicist' with developed algorithmic and mathematical thinking; on the other hand, he is a 'lyricist' creator, a bearer and promoter of ideas. Just like an artist, he does not have a clear plan for creating a painting and cannot break down an image into parts, as it would cease to exist. He is the master of information processes that are themselves abstract, intangible, difficult to measure, yet swift.
Ways to Build Effective Workforce Management in IT Production
So, what is important for an HR specialist to know in order to establish effective workforce management amid the diversity of roles in IT production?
First of all, any HR specialist in an IT company must have an understanding of the situation that is characteristic of his enterprise: who does what, what titles are used, and most importantly, the meaning attributed to these roles in the context of specific production.
Secondly, the HR specialist must have a flexible understanding of production roles. Initially, he forms an ideal understanding of them, which allows him to navigate everything. Then there must be a real picture of production: where and in what ways the roles intersect, overlap, and what perception of these roles exists among production managers. The challenge for the HR specialist is to reconcile the real and ideal situations in his mind, not to try to forcibly restructure processes to fit an ideal understanding, but to assist production in meeting the demand for resources.
Thirdly, it's essential to understand the possible career paths for various specialists: under what circumstances external recruitment might be effective, and when it might be better to develop an employee within your team by providing them with opportunities for growth, what qualities candidates should have to progress in a specific direction, which of these qualities might be incompatible within one person, and what is initially important for choosing a career path.
Fourthly, let's return to the thesis that IT is a field of highly skilled personnel, where early integration with the university educational environment is inevitable for more effective human resource work. In this situation, every HR specialist must develop not only skills in direct search, working with applications, and interviewing, but also must be well-versed in the university training environment: which universities prepare personnel for the company, what specialties within specific universities meet staffing needs, and importantly, who is behind this, who leads and conducts the training of specialists at universities.
Therefore, if we are to systematically debunk the myth that all IT professionals are programmers, a series of steps must be taken in this direction, with special attention paid to our universities, where the foundations of future professional perceptions are laid. In other words, constant interaction with the educational environment is necessary, for example, through modern formats of collaborative work in co-working centers, 'boiling points', and participation in educational intensives. This will help dismantle incorrect perceptions of IT enterprises, improve the efficiency of human resource work, and create conditions for collaborative activities in training various specialists in our industry.
I would like to express my gratitude to the colleagues who participated in the preparation and support of the relevance of this article: Valentina Vershinina and Yuri Krupin.
Source: habr.com
