Are you overpaying your developers? Productivity vs. Salary



Do your developers earn adequate money for their effectiveness? Maybe you overpay for some?

It seems evident to us that those who work more and better should earn more. Sometimes, however, we have the impression that this correlation is not so clear. So what does it look like in a typical project team, and what can you do about it?

Let's consider the IT developers

Imagine a big hall full of IT developers - let's say, 100 people. For simplicity, 
let's assume that they were all employed at the same time by the same recruiter and earning precisely the same amount of money +/- 20%.

How big the difference in efficiency can be between the weakest and the best developer ...?
I can almost hear voices saying that there will be a Gauss curve... Sure, it will be a Gauss curve, but what value will it have?

Let's try to estimate how much the effectiveness of 2 developers may differ?
10%.....?......20%.....?......50%.....?......100%.....?

The Answer:

The subject was scientifically tested several times over the past several years, and the observed results ranged say the difference between the worst and the best programmer around 10 TIMES! YES! Side-by-side developers can vary in efficiency by ten times or more.

Can the difference be greater? - There is no limit. The most significant difference I have personally seen was around 100 times. Nevertheless, to simplify the further discussion, let's stick to the x10 multiplier.

Since the difference is so significant why developers earn almost the same amount of money?

An essential element here may be seniority (junior/senior) Senior earns, of course, more than junior and it can be assumed that the length of the internship may slightly affect its effectiveness, but in reality, the multiplier x10 is not expected here. A person who works for a long time does not have to be more effective than a person with relatively low seniority.
How often have you seen a developer who is five times more effective than his colleagues and earns only 20% more, and leaves after some time because he does not feel appreciated?

How often have you seen a developer who is five times less productive than his colleagues and earns almost as much as his colleagues despite working much less effectively?

What can we do?

Let's focus on three essential elements that will allow us to increase the overall effectiveness of the team.
• Appropriate recruitment
• Measuring effectiveness and developing knowledge
Suitable team composition and adaptation

OK. Can we measure the real efficiency of developers?

At first glance, this seems simple; We can ask the developers to write the same algorithm and see who will do it faster...
Unfortunately, this is not so simple, and the more we explore the subject, the more we will understand that we are trying to compare pears to apples.

Does this mean that developers' efficiency cannot be measured?

It can be done! Should be done! The truth is, however, that we can't easily translate the number of lines of code, time spent, issues fixed or errors found into the real effectiveness of programmers. Reliable measurement must take into account several factors, preferably over a more extended period.

OK. Let's assume that we have measured the effectiveness of our developers.
Is it not enough to get rid of the few least effective, and significantly raise the salary of these top developers?

Not necessarily.!

Let's not forget about point 3 above.
Without developing the right composition of the development team (the last of the 3 points above), the other 2 points are of little value.

Throwing out less effective developers from the team is not always the best solution because they can sometimes play an essential role in the team. Similarly, a significant increase in the salary of the best developers (the measured ones) can generate more demanding attitudes.
Besides, it should be taken into account that less efficient people can perform other vital roles in the team that we are not even aware of. Removing them from the team without analyzing the composition of the team can do more harm than help.

And here we come to the point - sometimes it is not as important as the effectiveness of a single developer, but how effective is the whole team with its participation.

Moment, Does this mean that you can't do anything or you don't have to do anything?

You have to do it!
You have to measure efficiency, but... it won't be 1 KPI.
You have to pay more for the best but... not x10 and not directly to everyone.
You have to deal with people who add nothing to the team - but...
You must also take into account factors other than efficiency.

&….

The most important thing is to arrange the team, rules in the team, how to work, and to adapt roles and tasks to make the teamwork well.
Only then, treating these elements as a whole, can we say that we have a good team.

No comments: