I am 58 years old. I have worked all my life in the software industry. After all these decades, I think it is time to summarize what it takes to retain a software developer at a software company.

What Does the Management Think?

The management and HR department typically list various things that make a “happy developer”:

  • Positive work environment.
  • Career opportunities.
  • Autonomy.
  • Respect.
  • Flexible work arrengement.
  • Good vibes at the company.
  • And so on.

These are all good things per se. Certainly you have to have a positive work environment - an idiot works in a toxic work environment. But these are not the reasons a developer decides to stay at the company. You expect the work environment to be positive, that is not one of the primary reasons to stay at the company.

Just Two Important Factors: Salary and Interesting Work

After working my whole life in the software industry I have seen over and over again that there are just two really important factors for a developer when she makes the decision: should I stay or leave this company? The factors are:

  1. Salary.
  2. Interesting work.

If both these factors are excellent, a developer is not going anywhere. I have not once seen in my career that a developer leaves the company if she has an excellent competitive salary and the most interesting and challenging project in which she is able to learn new interesting technologies.

But if one of these two factors drops out of the comfort zone, the developer is immediately ready to hear about new opportunities in other companies.

If both of these two factors drop out of the comfort zone, she starts herself actively searching new opportunities in other companies.

The Paradox

The paradox is that the management and the HR department does not realize this. They list all kinds of self-evident facts what is good about our company and why developers want to work exactly in this company. Until they don’t. Until the developers realize that they get better salary and more interesting work in other companies.

Perhaps the reason for listing various HR niceties like positive work environment is the fact that it is unpleasent to pay higher salaries, and it is really difficult to win interesting projects for the developers?


In consultation business the companies try to win various projects to run their business. Of course, since otherwise they would go bankruptcy. The unpleasent fact is that sometimes there is a conflict of interest among the management and the developers. From the management point of view, some project might be lucrative to win. Perhaps, because the company can win a new big customer, or the project is big and provides good revenues for the years to come (and good bonuses for the management).

If the project also provides a chance for the developers to learn new interesting technologies that provide competitive edge for the developers for their future career, this is a match made in heaven. But it is not always like this. Sometimes there is a conflict of interest between the management and the developers. The project is lucrative from the management’s point of view, but not from the developer’s point of view. What should you do then? Pay better salaries to retain the developers to stay in the boring project.

This is the one secret about software projects every manager should know. In all my years in the software industry, I have never heard of a single developer who leaves the project that is the most interesting project in her career. A project that provides excellent opportunities to learn new bleeding-edge technologies that make the developer more competitive in her future projects. Not once. Unless the salary really sucks.


So, if you are a manager, how do you make the developers retain in your company? Pay an excellent salary and provide interesting projects for your developers.

The writer is working at a major international IT corporation building cloud infrastructures and implementing applications on top of those infrastructures.

Kari Marttila

Kari Marttila’s Home Page in LinkedIn: