Why developers are more expensive than money, how to save and increase them
Software developers are becoming more valuable assets than money. To lose them or lose control over them (and it’s still not clear what is worse) is easier than ever. We decided to talk about how to reduce these risks.
/ Flickr / Damien Pollet / CC BY-SA
According to a study by Stripe & Harris Poll, 61% of top managers (from a sample of more than 1,000 managers) were considered the main factor able to determine the success of their business, the opportunity to get into the team of strong developers. According to Forrester, organizations for which engineering talents are critical and lacking such talents, in 2018, faced with the need to pay professionals an average of 20% more than the market.
And in general, attracting and retaining qualified programmers in the current environment is not an easy task. The “free-money economy” (the gig economy), with flexible non-standard employment models, involves more and more able-bodied adults: according to McKinsey, as of 2017, there were up to 162 million people in Europe and the United States alone. Today, the developer has an increasing number of diverse opportunities to receive an acceptable monetary reward for him, without restricting himself to the scope of an employment contract with one employer.
To recruit a team of engineers and create an environment from which you do not want to leave, you should follow a few rules. Their recipe for success in technological talent management is not limited to, but they definitely work if applied without fanaticism.
Sometimes hiring “celebrities from coding” - eminent information security specialists or geniuses of hayload, etc. - leads to the fact that they at some point become inviolable, de facto acquiring levers such influences on the team that actually rely only management. This happens if, for the sake of developing a new technological direction or a project, a company wants to assemble a dream team and starts “vacuuming” the market, snatching the most experienced professionals from it, regardless of how they work together.
Often in large companies with a long history, “IT stars” undergo unpleasant personal metamorphoses due to the fact that only they know how to maintain huge arrays of legacy code. In the case of an opaque technological management structure, such employees are already reluctant to share relevant knowledge with newcomers and begin to sabotage initiatives hypothetically capable of undermining their status in a company or department.
/ Flickr / Code for America / CC BY-ND
To a certain extent, these risks eliminate or mitigate the honest, consistent implementation of the principles of Scrum and Agile in the work of the organization (see below), but even in a single IT company, where flexible methodologies have triumphed, such “technoprima” can complicate the work of the IT department.
However, the “star” is not a sentence. Just such employees do not need to try to “tear off with their hands,” just as there is no need to avoid them. During interviews with the most experienced developers, you should pay increased attention to their soft skills, including teamwork skills (most of the massive software is not done by a single person) and feedback from previous employers.
This does not mean that, for the sake of “hedging risks,” one must take into the team a multitude of specialists with duplicate functions or prefer middle peasants to professionals above. But the "star" developer - certainly not the absolute value.
For most developers, system architects, timblids, the main motivator - while we leave money behind the brackets - is professional self-improvement. They simply like to write code and create systems that can do something useful. They also like it when they have the opportunity to study and do their job better than others.
Moreover, in the professional community, this craving tends to take on the character of a neurosis: developers are afraid of not knowing something, being insufficiently competent even in areas where they have been working for years. They are owned by FOMO (fear of missing out, or “loss of profit syndrome”). No one bothers an employer who understands these nuances to give programmers the possibility of accelerated development.
Fortunately, there are many such opportunities. First, it is (no matter how trite) an interesting job, thanks to which the senior developer will strengthen his professionalism, and the junior developer will, willy-nilly, improve his skills to “middles”. Provided that the climate in the team is favorable for the diligent newcomers.
One thing is to rivet one-after-one patterned online stores, another is to make a complex, atypical product. In the case of truly meaningful projects, purely technological issues that are within the competence of the IT department acquire a real dimension. Routine disputes around the choice of a technology can be translated into a constructive course - into the channel of the benefits that a particular choice will give to the audience of the service.
For a company that cares about the qualifications of its developers, it’s in order to create its own technological knowledge bases, pay for all or part of training and certification courses, buy professional literature at the request of developers, and conduct internal hackathons.
/ Flickr / betsy weber / cc by
A smart employer with peace of mind will let an engineer speak at a core conference, since he understands that he indirectly promotes his report not only as an expert, but also a company. There is no need to fear that at the conference a specialist will be lured to another place: if an employee himself hesitates, he can be leveraged online from his office.
When they say that money is not the main motivating factor for the developer, for some reason they are often completely blind to them. Meanwhile, just because IT-specialists are committed to the principles of rational thinking, it is especially important for them to understand what remuneration they can expect in the foreseeable future and under what conditions. If programmers were indifferent to money, they would not be paid so much .
It is also important that the model for the formation of remuneration is understandable and maintains a link to the benefits a specialist brings to the company. It happens that this rule is violated in relation to "star" developers (see above) and overpaid with them "for status".
For a startup, it also makes sense to calculate the option program for leading developers and keep these promises, no matter what happens with the business. However, you can not overdo it - to promise more than you will be able to give. Often, the founders of innovative projects neglect this rule and promise a share in the company of almost no trainees. You should know the measure - for example, in Buffer, under the option program, the team (minus the co-founders) allocated 17% of the shares in total, and leading consultants - about 3%.
The head of a company or a CTO, depending on the scope and structure of the business, must understand what the basic motivation of engineers, testers, and projects under its authority is. In many cases, developers and other technical specialists are frustrated with the company and leave it because they do not see where they will go next.
Of course, there is no single way for everyone and everyone; developers are very different. You need to push off from the needs of each employee individually. For example, for many developers, an excellent way of development is to become a team leader: without taking off from programming, begin to be more responsible for the product, to have the right to vote when the technological stack changes.
/ Flickr / Damien Pollet / CC BY-SA
But not all engineers want to take on anything other than development tasks. An attempt to “train” a technical manager even of an entry level from such a specialist will most likely lead to the fact that he simply quits. Fortunately, software development is an area where limitless horizontal growth is possible if a company has projects that will present worthy (in their eyes) challenges to senior developers.
So speak with the developers: at the start, during interviews, and when they are already in your staff. If you are a manager of a higher echelon, then their direct managers (department heads, team leaders, etc.) will help you understand the professional and career needs of ordinary programmers.
This recommendation applies primarily to IT companies, for which the value of engineers is even higher than the market average. Stack Overflow Operations Director Jeff Schepanski recommends nurturing the culture inside the company, which he dubbed developer-first, that is, where the programmer with his needs is at the forefront.
Some circumstances and situations that demotivate programmers may not be clear to the manager, who has not worked closely with them before. Suppose if a qualified software developer is forced to scribble a fifth of his working time for a person who has not written a single line of code, there is a risk that sooner or later (and more likely sooner) he will wave his hand and leave, even though the salary is higher than the average to the market.
Therefore, in companies whose success relies primarily on the work of developers, it is important to build the right organizational structure, where intermediate programmers are located between programmers and classical managers - grassroots and middle management, who are well versed in the work of engineers.
Finally, one of the typical reasons why developers most often leave large companies is the lack of autonomy in making important decisions, as well as excessive limitations in the choice of tools, sometimes not due to anything other than corporate considerations.
Caring - or rather, “caring for a healthy person” - about developers is expressed at various levels: from understanding the current realities of the project (maybe the project allows “techies” to work from home 1-2 days a week?) To the ergonomics of the space in which employees (not all IT specialists, for example, like open spaces).
Often, entrepreneurs and managers blame developers for “not seeing the big picture” and losing sight of the company's business goals. Totally in vain. System architects, engineers, and coders are not obliged to reason in financial and market categories. Yes, “grocery thinking” is great, but it is brought up in the right environment.
For developers to do something that will be useful for business, you need to put them in suitable conditions. The goal is to kill two birds with one stone. On the other hand, we need to ensure that developers do not have questions like “Why do we do this?”, On the other hand, to ensure that management does not require results from technical managers that the IT people do not understand at the root. And this goal is achievable.
/ Flickr / Paul Downey / CC BY
Over the past 20–25 years, many frameworks and sets of the best practices of information technology have been developed and continue to improve in the world. Among them, for example, - ITIL and COBIT. The first was created in order to minimize bureaucracy and create understandable reproducible rules for performing routine IT processes. And the second , in turn, was originally designed to connect and synchronize business needs with the principles of software development.
In addition, the introduction of agile development methodologies, primarily Scrum, helps build a healthy environment for creating and maintaining IT products. To understand how your company complies with Scrum principles, there is an excellent Scrum Open test. The mechanisms that are adopted in flexible methodologies help to level many of the above risks.
For example, a person with a special role - “Scrum-master” - concentrates, in particular, on making a transition to a truly teamwork team. Including, on the one hand, it removes the fears of the old-timers of the team, who are afraid of becoming unnecessary, on the other hand, it sets up newcomers to be respectful of local “IT-stars”.
We understand the value of developers and try to make it comfortable for them to work in 1cloud . And right now we are expanding our team and will be happy to invite you to the role of lead backend developer . In addition to coordinating the work of colleagues, you will be engaged in the architecture and mechanisms of interaction of our solutions with other systems.
The basic requirements are: industrial development experience in C # and the .NET platform; good knowledge of SQL, T-SQL and experience with MS SQL Server; experience with Git, experience building CI / CD processes. We are considering full-time candidates. Our office is located in the center of St. Petersburg (m.Chernyshevskaya).
/ Flickr / Damien Pollet / CC BY-SA
According to a study by Stripe & Harris Poll, 61% of top managers (from a sample of more than 1,000 managers) were considered the main factor able to determine the success of their business, the opportunity to get into the team of strong developers. According to Forrester, organizations for which engineering talents are critical and lacking such talents, in 2018, faced with the need to pay professionals an average of 20% more than the market.
But even with worthy pros at their disposal, both corporations and startups can miss profits - simply because of systemic errors in working with IT people. In particular, many programmers are forced to maintain outdated systems or software of frankly low quality. Companies around the world because of this approach are losing about $ 300 billion a year.
And in general, attracting and retaining qualified programmers in the current environment is not an easy task. The “free-money economy” (the gig economy), with flexible non-standard employment models, involves more and more able-bodied adults: according to McKinsey, as of 2017, there were up to 162 million people in Europe and the United States alone. Today, the developer has an increasing number of diverse opportunities to receive an acceptable monetary reward for him, without restricting himself to the scope of an employment contract with one employer.
To recruit a team of engineers and create an environment from which you do not want to leave, you should follow a few rules. Their recipe for success in technological talent management is not limited to, but they definitely work if applied without fanaticism.
Carefully hire "IT-stars"
Sometimes hiring “celebrities from coding” - eminent information security specialists or geniuses of hayload, etc. - leads to the fact that they at some point become inviolable, de facto acquiring levers such influences on the team that actually rely only management. This happens if, for the sake of developing a new technological direction or a project, a company wants to assemble a dream team and starts “vacuuming” the market, snatching the most experienced professionals from it, regardless of how they work together.
Often in large companies with a long history, “IT stars” undergo unpleasant personal metamorphoses due to the fact that only they know how to maintain huge arrays of legacy code. In the case of an opaque technological management structure, such employees are already reluctant to share relevant knowledge with newcomers and begin to sabotage initiatives hypothetically capable of undermining their status in a company or department.
/ Flickr / Code for America / CC BY-ND
To a certain extent, these risks eliminate or mitigate the honest, consistent implementation of the principles of Scrum and Agile in the work of the organization (see below), but even in a single IT company, where flexible methodologies have triumphed, such “technoprima” can complicate the work of the IT department.
However, the “star” is not a sentence. Just such employees do not need to try to “tear off with their hands,” just as there is no need to avoid them. During interviews with the most experienced developers, you should pay increased attention to their soft skills, including teamwork skills (most of the massive software is not done by a single person) and feedback from previous employers.
This does not mean that, for the sake of “hedging risks,” one must take into the team a multitude of specialists with duplicate functions or prefer middle peasants to professionals above. But the "star" developer - certainly not the absolute value.
Let the professionals get new skills.
For most developers, system architects, timblids, the main motivator - while we leave money behind the brackets - is professional self-improvement. They simply like to write code and create systems that can do something useful. They also like it when they have the opportunity to study and do their job better than others.
Moreover, in the professional community, this craving tends to take on the character of a neurosis: developers are afraid of not knowing something, being insufficiently competent even in areas where they have been working for years. They are owned by FOMO (fear of missing out, or “loss of profit syndrome”). No one bothers an employer who understands these nuances to give programmers the possibility of accelerated development.
Fortunately, there are many such opportunities. First, it is (no matter how trite) an interesting job, thanks to which the senior developer will strengthen his professionalism, and the junior developer will, willy-nilly, improve his skills to “middles”. Provided that the climate in the team is favorable for the diligent newcomers.
One thing is to rivet one-after-one patterned online stores, another is to make a complex, atypical product. In the case of truly meaningful projects, purely technological issues that are within the competence of the IT department acquire a real dimension. Routine disputes around the choice of a technology can be translated into a constructive course - into the channel of the benefits that a particular choice will give to the audience of the service.
For a company that cares about the qualifications of its developers, it’s in order to create its own technological knowledge bases, pay for all or part of training and certification courses, buy professional literature at the request of developers, and conduct internal hackathons.
/ Flickr / betsy weber / cc by
A smart employer with peace of mind will let an engineer speak at a core conference, since he understands that he indirectly promotes his report not only as an expert, but also a company. There is no need to fear that at the conference a specialist will be lured to another place: if an employee himself hesitates, he can be leveraged online from his office.
Fair pay developer
When they say that money is not the main motivating factor for the developer, for some reason they are often completely blind to them. Meanwhile, just because IT-specialists are committed to the principles of rational thinking, it is especially important for them to understand what remuneration they can expect in the foreseeable future and under what conditions. If programmers were indifferent to money, they would not be paid so much .
It is also important that the model for the formation of remuneration is understandable and maintains a link to the benefits a specialist brings to the company. It happens that this rule is violated in relation to "star" developers (see above) and overpaid with them "for status".
Of course, employers do not encourage disclosure of information about the salaries of their employees, but in the end all the same everyone knows who gets what and how much “injustice” in charges to someone from office neighbors easily demotivates programmers.
For a startup, it also makes sense to calculate the option program for leading developers and keep these promises, no matter what happens with the business. However, you can not overdo it - to promise more than you will be able to give. Often, the founders of innovative projects neglect this rule and promise a share in the company of almost no trainees. You should know the measure - for example, in Buffer, under the option program, the team (minus the co-founders) allocated 17% of the shares in total, and leading consultants - about 3%.
Offer suitable career development options in time.
The head of a company or a CTO, depending on the scope and structure of the business, must understand what the basic motivation of engineers, testers, and projects under its authority is. In many cases, developers and other technical specialists are frustrated with the company and leave it because they do not see where they will go next.
Of course, there is no single way for everyone and everyone; developers are very different. You need to push off from the needs of each employee individually. For example, for many developers, an excellent way of development is to become a team leader: without taking off from programming, begin to be more responsible for the product, to have the right to vote when the technological stack changes.
/ Flickr / Damien Pollet / CC BY-SA
But not all engineers want to take on anything other than development tasks. An attempt to “train” a technical manager even of an entry level from such a specialist will most likely lead to the fact that he simply quits. Fortunately, software development is an area where limitless horizontal growth is possible if a company has projects that will present worthy (in their eyes) challenges to senior developers.
So speak with the developers: at the start, during interviews, and when they are already in your staff. If you are a manager of a higher echelon, then their direct managers (department heads, team leaders, etc.) will help you understand the professional and career needs of ordinary programmers.
Create a culture in which the primary developer
This recommendation applies primarily to IT companies, for which the value of engineers is even higher than the market average. Stack Overflow Operations Director Jeff Schepanski recommends nurturing the culture inside the company, which he dubbed developer-first, that is, where the programmer with his needs is at the forefront.
Some circumstances and situations that demotivate programmers may not be clear to the manager, who has not worked closely with them before. Suppose if a qualified software developer is forced to scribble a fifth of his working time for a person who has not written a single line of code, there is a risk that sooner or later (and more likely sooner) he will wave his hand and leave, even though the salary is higher than the average to the market.
Therefore, in companies whose success relies primarily on the work of developers, it is important to build the right organizational structure, where intermediate programmers are located between programmers and classical managers - grassroots and middle management, who are well versed in the work of engineers.
It is important and, without losing control over the developers, to avoid micromanagement, which can kill their productivity. With such hypercontrol, either managers without an IT past often try to cope with their own feeling of helplessness, or, on the contrary, those initial-level managers who themselves recently recently coded and are afraid that they will not cope with new responsibilities.
Finally, one of the typical reasons why developers most often leave large companies is the lack of autonomy in making important decisions, as well as excessive limitations in the choice of tools, sometimes not due to anything other than corporate considerations.
Caring - or rather, “caring for a healthy person” - about developers is expressed at various levels: from understanding the current realities of the project (maybe the project allows “techies” to work from home 1-2 days a week?) To the ergonomics of the space in which employees (not all IT specialists, for example, like open spaces).
Link IT development with company goals
Often, entrepreneurs and managers blame developers for “not seeing the big picture” and losing sight of the company's business goals. Totally in vain. System architects, engineers, and coders are not obliged to reason in financial and market categories. Yes, “grocery thinking” is great, but it is brought up in the right environment.
For developers to do something that will be useful for business, you need to put them in suitable conditions. The goal is to kill two birds with one stone. On the other hand, we need to ensure that developers do not have questions like “Why do we do this?”, On the other hand, to ensure that management does not require results from technical managers that the IT people do not understand at the root. And this goal is achievable.
/ Flickr / Paul Downey / CC BY
Over the past 20–25 years, many frameworks and sets of the best practices of information technology have been developed and continue to improve in the world. Among them, for example, - ITIL and COBIT. The first was created in order to minimize bureaucracy and create understandable reproducible rules for performing routine IT processes. And the second , in turn, was originally designed to connect and synchronize business needs with the principles of software development.
In addition, the introduction of agile development methodologies, primarily Scrum, helps build a healthy environment for creating and maintaining IT products. To understand how your company complies with Scrum principles, there is an excellent Scrum Open test. The mechanisms that are adopted in flexible methodologies help to level many of the above risks.
For example, a person with a special role - “Scrum-master” - concentrates, in particular, on making a transition to a truly teamwork team. Including, on the one hand, it removes the fears of the old-timers of the team, who are afraid of becoming unnecessary, on the other hand, it sets up newcomers to be respectful of local “IT-stars”.
We understand the value of developers and try to make it comfortable for them to work in 1cloud . And right now we are expanding our team and will be happy to invite you to the role of lead backend developer . In addition to coordinating the work of colleagues, you will be engaged in the architecture and mechanisms of interaction of our solutions with other systems.
The basic requirements are: industrial development experience in C # and the .NET platform; good knowledge of SQL, T-SQL and experience with MS SQL Server; experience with Git, experience building CI / CD processes. We are considering full-time candidates. Our office is located in the center of St. Petersburg (m.Chernyshevskaya).
What we write about in the corporate blog:
Source: https://habr.com/ru/post/438390/