Software Team Turnover: Why Developers Leave (And What You Can Do About It)

Unplanned turnover hurts—especially when you lose top
people. Good developers are a rare breed. If you’ve ever hired a new software
developer, you know how difficult it is to find people that are competent.

Good developers that work well with your existing team
of developers are even harder to find. Even when you find a person with the
right skills, personality conflicts and other issues can arise to complicate
the team dynamics and jeopardize the team’s cohesion. When a good team has
finally been assembled, it’s imperative to keep them together and working well.

In addition to the loss of team cohesion, the organization
loses the intangible knowledge that good developers take with them when they
leave. Even with good documentation, developers possess undocumented knowledge
about the product, the domain, and the designs that is essential to the
project’s completion. The fact that most development efforts also suffer from
less than adequate documentation compounds the impact that the loss a
developer’s product knowledge has on the overall outcome.

In addition to product knowledge, key developers have
indispensable knowledge of the organization’s processes, development tools,
source code control, coding standards, and more. All of this adds up to a very
costly void that any company needs to fill when key developers jump ship.

Far too frequently a manager or executive will get
caught up in the mindset that the salespeople are the most important cogs in
the machine. After all, the sales people are the ones bringing in the money,
right? Well, yes and no. Sales people are important, and a good sales staff is
essential, but if you have no developers to build the product, what will the
sales people sell?

It sounds simple, but I’ve been involved with far too
many companies where sales people are treated like gold and developers are
treated more like rusty iron. Whether your organization is sales-oriented or
not, if you depend on your software developers for success, you might be
missing opportunities because of unplanned turnover that could have been
avoided.

So the question then becomes: How can you avoid
developer turnover and keep key team members on staff for lengthy periods of
time? Well, there’s no simple answer, but I’ve got some ideas to share with
you. All situations are different, and there are countless reasons why people
may or may not seek a change. I’ll discuss the top three reasons why developers
tend to look for greener pastures. Considering these three areas and making
some adjustments may help you hold on to key pieces of your puzzle.

Money

Easily one of the biggest issues that causes developers
to look elsewhere is probably the first issue which causes managers to cringe.
That’s right, most developers are just like everybody else in that they too
exclaim the immortal words of Jerry Maguire, “Show me the money!”

Unfortunately, most developers are painfully aware that
the best way to get a raise is to simply get a new job. A developer might be
happy in all aspects of her job, but if she knows that her company is paying
her below market rates, that fact might outweigh all the good. There are few
companies that are willing to give a good, yet underpaid, developer a raise
that will exceed what the developer could get by jumping ship and landing in a
new job elsewhere.

I know what you’re thinking. You can’t possibly afford
to pay all your developers enough money to compete with any offer that may be
out there on the horizon. So what is the solution then? It’s a good idea to
ensure that all development team members are paid a competitive rate, but the
key is to identify a small portion of your development staff as people who you
decide to invest in long term, and to take care of them in a way that will make
them never want to leave for monetary reasons.

There are numerous ways to let a developer know that you
are interested in working with him long term, and not all of them involve
monetary rewards. Any kind of additional “perk” goes a long way towards making
people happy. These can involve non-liquid monetary assets such as stock
options as well as perks like telecommuting, free lunches/snacks/sodas, good
hardware, other gadgets (cell phones, PDAs) and so forth. Keep in mind that
many developers are “geeks” and often a cool PDA or a sweet workstation can go
a long ways in this department.

There is a catch here, however. While these kinds of
incentives can go a long way towards pleasing employees, nothing can harm
morale faster than broken promises. That is, promising a bonus is great, but if
the money isn’t available, or the rules are changed midstream, and the
developers end up not getting the promised bonus, it does far more harm than
never having promised a bonus in the first place. Make sure that whatever you
commit to is feasible and that you follow through with the promise.

Morale

If a good developer leaves the company for a reason
that doesn’t directly involve money, it is often some type of morale problem—one
that may be more widespread than you think. If people aren’t happy where they
work, they will often leave for equal—or even less—pay elsewhere.

There are a few key things, especially when dealing with
software developers, that can go a long ways towards keeping people happy and
in turn, keeping them on your payroll.

I believe the biggest morale-related factor that causes
good developers to look elsewhere boils down to the need for a new challenge.
Part of the problem with keeping a developer challenged is inherent in the way
software projects are run. For example, developers tend to learn on two
different curves when landing a new development job which are pictured in
Figure 1 below.

Figure 1: Developer Learning Curves.

The dotted line represents the progression a developer’s
rate of learning and enhancing his or her technical skills. When first hired, a
developer learns at a rapid rate. This is due to working with new people, new
processes, new tools (possibly new development languages), working with
existing architectures, and so on. At a certain point, that learning curve
begins to level out because the developer becomes familiar with the work, the
tools, the languages, etc. At this stage the work can become a bit more routine
and monotonous.

The solid line represents the rate at which the
developer acquires domain knowledge while working on a given project. For
example, if a developer starts a new job in the public library domain, that
developer will begin learning more and more about the operation and nuances of
public libraries. This curve tends to not level out as much or possibly not at
all due to the fact that even though a software project may be released and
completed, future research is spent on finding out ways to improve library
operations and other user-related features that could be a selling point for
the product.

As you can see from the graph, there is a certain point
at which a developer starts learning more about the domain and not learning
much, if anything, new technically. For many developers this may not be an
issue, but for other developers this can result in a loss of interest in the
company, the product, or their job as a whole.

A developer may be seeking to improve their skills, and
not care as much about domain specific knowledge. If that is the case, this is
the point at which a developer can become dissatisfied with his job and look on
to bigger and better horizons.

The development of this situation is natural, but
detecting it and doing something about it can be difficult. Get to know each of
your talented developers individually and find out their career goals and
desires. Each person is different, but a general theme you will encounter is
that you need to keep your good developers technically challenged. Actually
keeping them challenged is the difficult part. How to best go about it really
depends on the individual developer—what challenges they seek and what
motivates them individually.

By getting to know your developers, you will learn
numerous ways that you can try to keep the technology learning curve from
leveling out. All developers are different and different things inspire and
motivate them. Find out what each person’s motivating factor is, and then keep
your good developers where they want to be. You may even find that some of your
best developers will actually prefer working on an existing project with
familiar code as opposed to working on a new project with new technologies. Try
to keep your good developers working on projects they enjoy—whether that be an
existing project a person has worked on for a long time, or a brand new system
that needs to be designed, or something in between.

Moving developers to new projects can be difficult
because as developers build up domain and project knowledge, your first
instinct is to keep them on that project and hire new developers to work on new
projects. While that sounds like a good idea, it may or may not be the best
solution for your developers and/or your company. What often happens is
employers will keep proven developers on existing projects and hire unproven
ones to spearhead new projects. While this may make sense from a business
perspective in the short term, in the longer term—after the unproven new hire fails
to develop a good product and the proven developer quits from boredom—it may
not turn out so well.

When changing projects is not an option, there are also
a number of other ways to allow developers to flex their brains now and then.
These can include offering training opportunities to train people on the latest
technical tools, sending people to technical conferences or workshops, offering
tuition reimbursement to allow developers to continue their educations, giving
good developers the go-ahead to analyze and re-work existing architectures, and
so on. Be creative and let developers know that they are allowed and encouraged
to further their own careers and not just your projects.

The bottom line here is to identify your good
developers, the ones that you want to have around for a long time, and find out
where they want to be and what they want to be doing. Work with them to make
them happy and to keep the company moving forward. Even when you’re not able to
take the actions you’d like to take, simply pulling a developer aside and
taking the time to find out what makes him or her happy goes a long way, in and
of itself, towards building good morale.

Burnout

Finally, I’ll address the third major reason why
developers tend to switch jobs: burnout. Software development is a tedious
business and a difficult task for all involved. As projects near completion,
work life is full of meetings, disorganization, overtime, and stress. Even the
standard day for a good developer is full of heavy thinking, problem solving,
frustrating compilation errors, and the like. Software development is not your
standard “sit at your desk” job. It’s the equivalent of taking a difficult test
8 hours a day, 5 days a week (plus overtime).

Burnout is a real issue and something that faces nearly
every developer at some time in their career. Often the thought is to change
careers completely and get away from it all. Some look to management positions,
hoping for less stress. More often than not, however, the “solution” is to look
elsewhere for a new job thinking the immortal words, “it can’t possibly be this
bad over there.”

The biggest thing that managers need to be able to do in
order to prevent burnout is to allow their employees to have fun. This is a
very hard thing for a lot of development managers to do. Taking 15 minutes to a
half hour out of the day to have fun will seem superfluous to many. But there
is so much that can be accomplished in a simple activity that may last only as
long as your average smoke break.

A team that has fun together is much more likely to work
together well, enjoy working with each other and help each other. Job
satisfaction is increased when there is something other than work to look
forward to as well. The mental drain of a tough day of debugging can severely
be lightened by a few minutes of entertainment.

What kinds of activities am I talking about? That’s up
to you. People are different and different things work for different people so
there isn’t any one clear answer to that question. Many developers are computer
gaming geeks as well so a quick match of Warcraft III or Unreal Tournament can
serve to refresh a developer almost as well as a good nights sleep. Others
don’t enjoy PC gaming, but will welcome other things, like a quick game of
HORSE on the Nerf basketball hoop in the hallway.

One company set aside a few minutes every Friday morning
for miniature golf. Every person was responsible for setting up a miniature
golf hole in their cubicle and then the team played a round of golf. Another
company had a racing course setup in an unused conference room for Friday
office chair races. Some companies have parties and luncheons to raise employee
morale and give employees and occasional break. Be creative and come up with
something that will be entertaining for the team members while also being
constructive toward building team morale and keeping everybody energized for
the work ahead.

Keep in mind that it is far better to offer an activity
that costs less and free to employees than to offer something more lavish and
charge employees an admission fee. For a team morale building exercise, nothing
slaps you in the face as much as a money collector at the front door. Imagine
being that one employee that is just making it paycheck to paycheck and is then
excluded from work activities because of the cover charge. Not many things can
destroy morale as quickly as that.

Conclusion

There are many other reasons why developers would
lean towards moving on to greener pastures, but I’ve touched on some of the
biggest ones. What this all really boils down to is managing a public relations
campaign within your own organization in an effort to win over (and keep) your
employees.

However, before looking to big, broad, expensive
gestures and top-down morale improvement initiatives, look at the simple things
first. Things like getting to know your employees personally, using common
sense in operations, and finding out what employees want from you and your
company can go a long, long way towards helping you keep good people working hard
in your organization.

Aaron Reed is an Assistant Professor at Northface University in South Jordan, Utah. He holds a BS in Computer Science from Weber State University. He has worked in the software development industry for 12 years in positions ranging from entry-level developer to vice-president of development at several companies.