5 ways to hold onto developers in a hot market

by

businessman tied up with rope

 

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 . . .

 

READ MORE

Fake Case Study: Jack of all trades vs. Master of One

Fake Case Study: Jack of all trades vs. Master of One

  Listen to any earnings call or executive presentation and you will likely hear the terms “top line” and “bottom line.” These are words used to describe a business’s performance. According to Investopedia, the words are defined as follows: Top line refers to the...

read more
Your Personality Is Showing

Your Personality Is Showing

There I was, minding my own business one evening, digging into my organization's SEO performance (as one does), when I came across something interesting. Search terms related to "MBTI" — or the Myers-Briggs Type Indicator, developed by Katherine Cook Briggs and Isabel...

read more
Lessons From a Change Manager Who Hates Change

Lessons From a Change Manager Who Hates Change

Hello. My name is Monique, and I’m a change manager who hates change.   After years of receiving “consulting therapy” from various mentors, I am now able to say these words out loud and proudly. But for a long time, it felt more like an admission of guilt. I mean, who...

read more
Creativity as a Cure

Creativity as a Cure

The topic of creative solutioning has been front and center these days as we talk more and more about organizational adaptability in the face of dynamic and uncertain times. For example, I recently read about a project that got me thinking about specific priorities...

read more
Thought Ensemble, a Pariveda Company — Why Now?

Thought Ensemble, a Pariveda Company — Why Now?

Big news over here as we close out the year - we have been acquired by Pariveda, a 750-person consulting firm in 12 markets across North America! We are now “Thought Ensemble, a Pariveda Company” and I’ll be serving as the Managing Vice President continuing to lead...

read more
Thought Ensemble Joins Pariveda Solutions!

Thought Ensemble Joins Pariveda Solutions!

Dallas, December 9, 2021 /PRNewswire/ -- Pariveda, a leader specializing in solving complex technology and business problems, announces the acquisition of Thought Ensemble. With the addition of Thought Ensemble, Pariveda now provides holistic business strategy,...

read more
Thoughts on Colorado’s Equal Pay for Equal Work Act

Thoughts on Colorado’s Equal Pay for Equal Work Act

It was about a year ago that we first started hearing about Colorado’s Equal Pay for Equal Work Act (SB19-085) and I knew it was going to be national news. We’d just gotten past the “Rocky Mountain High” jokes, and our lovely state was trying to break new ground...

read more
Disruption Is the New Normal

Disruption Is the New Normal

By nature, disruptors are not popular. “First they ignore you, then they laugh at you, then they fight you, then you win, then they copy you.” We have all heard some version of this quote, and we have all seen it play out in real life. We've seen it with building...

read more
What Would You Say You Do Here?

What Would You Say You Do Here?

“I deal with the … customers so the engineers don't have to! I have people skills!” That famous Office Space quote from Tom Smykowski cracks me up every single time. I know Toms. I’ve been Tom. Change the quote to say, “IT Team” instead of “engineers,” and there’s a...

read more