Recently, I sat down with a CIO who looked a little worse for wear.  He’d had a bad year . . . he said that 100% of his development staff had turned over during 2014.  He had an all new (and more expensive/less knowledgeable) development staff.

100% turnover is pretty extreme, but as the market for technical talent heats up again (yeah!) we can expect far greater turnover.  Of course one obvious solution to this problem is to raise salaries and this is already occurring.  But besides the obvious, what else can technology leaders do to keep their technical colleagues around?

Following are five non-salary ways of improving technical people’s happiness with their jobs:

Get rid of written reviews

The written review is basic common sense in most companies.  It’s common sense that you should write down feedback and give it to your colleagues.

How else will they learn?

Besides, we’ve been getting written feedback on our work since our kindergarten teacher drew a smiley face on our first assignment. And yet, we know that there is very little evidence that written reviews cause positive adjustments in behavior.  In fact, as you are no doubt aware, written reviews are so highly flawed in most organizations that the process can destroy weeks of productivity.   First, you destroy the productivity of the person writing the review and the person/people administering the review process.  But more importantly, badly written reviews (and let’s face it . . . most of them are bad) destroy the productivity of the recipient as well—perhaps for months or even years.

It is far better to deliver timely verbal feedback through a discussion.  The proper time to tell a developer that he has been taking too long to complete assignments or has missed the implementation of a key feature is at the time when the issue occurs . . . not months later during a review process.  Of course, if a person needs to be counseled out of the company or outright fired, documentation may be necessary, but why do we subject the rest of the organization to a disheartening, misleading, political personal review process so that we can get rid of a few bad eggs?

End reviews.  Keep more technical staff.

Spread out the maintenance

Developers, especially the good ones, the ones that are passionate about making software, want to solve new problems with new technology in new ways. Software maintenance is a reality in every organization, but too often, developers can get stuck on the maintenance of a platform. The best developers won’t tolerate it for long.

If retention is important to your organization, there are ways to spread out maintenance responsibilities. You can set up maintenance sprints that are shared by the development staff. For example, perhaps every developer takes a maintenance sprint once every four sprints. You can outsource maintenance and leave the more interesting development in house.  You can use maintenance as a training ground for new recruits . . . with the commitment that the maintenance has a clear and definite end point.

Whatever the solution you choose, make sure your best people don’t get stuck with your oldest stuff.

Allow time for autonomy

Most of the time, in modern organizations, the priorities in software development will be set by someone other than the person doing the work.  Maybe your organization has a change control committee or an executive prioritization group.  In other words, someone other than the person writing the code decides what code needs to be written.

But, like all professionals, one of the things that developers crave most of all is autonomy: the ability to decide for oneself what is important and what will make a difference.

Different organizations solve this in different ways.  There is the now-famous Google 20% where technical staff dedicate a day a week to pursue their own product interests.  Some companies do a similar thing once a month.  There is a KANBAN approach of allowing developers to take whatever task they’d like to take next.  Some companies allow developers to propose their own projects to the organization’s change committee.

There are many ways of allowing people some control over their work and one that will work within the culture of any organization.

Support personal growth

The technical world changes quickly.  The skills and languages you picked up just a couple of years ago are out of date today.  And yet, we spend little time helping developers as they grow in their field.  Besides autonomy, most people want to be able to master something  . . . to be seen as an expert in their field.  Expertise requires study, research and practice.  And, if your organization doesn’t let them grow in their field, someone else will.

Again, there isn’t only one way to help a developer grow his or her expertise.  You can offer formal training in house, or out of house, or allow self-study time, or computer based training, or, simply, allow time to explore new technologies that aren’t currently being used in your organization.  You can also use your vendors to help grow expertise.  Most vendors would be happy to walk your team around a shop floor, or do an educational lunch or workshop.

Investing in people leaves them inspired.

Stop the insane incentive programs

Of the five ways to reduce turnover, this is the most important.  Increasingly, we are seeing complex incentive schemes cooked up to encourage developers to be more productive.  Perhaps the idea is to pay out bonuses at the end of an on time sprint or at the end of successful delivery of a project (or God-forbid . . . incentives based on lines of code.)

It seem logical, if we pay people more to behave in a certain way, they will.  And in fact (as explained in this excellent video by Dan Pink),  incentives do just that–So long as the task is fairly easy and requires little higher order thought.  But, as soon as the task becomes even remotely complex, incentive programs no longer work.  In fact, they backfire.  Study after study has shown that pay for performance in most jobs will actually make people slower and more prone to error.

This type of study has been repeated over and over again with the same results.  Incentives Do NOT help productivity, problem solving, creativity, motivation or job satisfaction when complex tasks are involved.  And yet, most organizations love incentives, despite the fact that repeated scientific studies have shown negative results for decades (and I suspect most of us … especially those in charge of corporate incentive programs have read these studies).

I’ve never seen a study on why organizations continue to implement incentive programs despite mountains of evidence against them.  But, let me pose a hypothesis:  It is a well-meaning, common sense attempt to improve the performance of our individuals.  And, we can’t think of anything else.  Of course, in this case, our common sense steers us in the wrong direction. Let me repeat, incentives do not work for complex tasks.  Surely, that should be enough of an incentive to get rid of incentives.

Of course, none of these are easy solutions.  And, their implementation in your organization will have to be made to fit the unique cultural and business needs of your organization.  But, these ideas can help you hold onto your team and keep them motivated.

Or, you could just throw some more money at them . . .