Software developers aren't satisfied to just sit in a
cube and pound out code day after day. Like their not-as-nerdy
counterparts in other parts of the company, they need more to stay
engaged and happily productive. There is a lot of talk about the
poor job market out there lately. Don't be fooled, your dev talent can
find other work. The reality about top developers is that they aren't
locked into one market segment or vertical. Your awesome JScript
guys can go write websites for anybody. Your competitors might be
happy to steal some of your talent away too. Don't let all the
company knowledge and history that is stored in their heads just walk
out the door. Do something right now to keep your development
machine humming.
Compensation
Let's go ahead get the tough news out
of the way. You're going to have to compensate your developers.
You don’t have to over compensate to get good retention –
especially if you get the rest right - but pay a salary commensurate
with skill level and industry. Do some market research to find out
what those numbers might be. Remember, talent won't be cheap, but is
almost always worth some extra money. Another thing you need to do
about compensation is to have a very clear and well communicated plan
for both base salary increases (AKA raises) and bonus payments (if
applicable). There must be a clear path to making more money over
time. Without good communication about salary, bitter disappointment
awaits both the firm and the developer. Part of this plan should
include a proper performance review and clear goals. (That's a whole
other article.) In most cases, people will expect at least a COLA to
keep up with the proverbial price of bread. Have a plan and discuss
it with the team either as a whole or individually.
Product delivery
Developers like to deliver. It's
satisfying. When priorities shift and they have to move from one
project to the next before the first project is finished it can be
frustrating. This is known as context switching. Everybody
understands that it happens sometimes. Sometimes is ok. Priorities
do shift and projects do get canceled. Understood. However, if your
dev team is getting yanked around from project to project without
being allowed to finish anything, they will get frustrated. They
will feel like they're working hard and have nothing to show for it.
Frankly, if it's happening all the time, you are probably suffering
from questionable management. Pay attention to context switching
feedback. Watch your project portfolio and manage it carefully. Let
your teams deliver.
Culture
It's not just about the cool code they
get to write. Developers like to play too – and not just video
games. You've got to provide and build an environment that people
want to work in. Your culture will be uniquely your own. It will be
made and nurtured by your people. Don't trample it – grow it.
Encourage and organize group outings. Foster an atmosphere of
positive feedback and teamwork and participation. Ask for and accept
real and honest feedback in meetings. Don't just say “my door is
always open” - that's lame. Reach out and pull people through the
door. Much has been written about company culture – read up and
embrace. The more you can create a sense of family and teamwork, the
closer knit your team will be. Not only will they be happier,
everyone on a close-knit team is more productive.
Use the right tool for the job
Some managers think that all developer
resources are completely fungible. There can be a feeling that if
project X is running late, you can shift someone from project Y to
fill the gaps and pick up the slack. This is not true. Well, not
all the time. Developers have strengths and weaknesses just like
other humans. If you put someone that lacks the right skill set on a
project, you will hurt the project, the team, and the new developer.
Put the right people on the right projects. Know their strengths and
weaknesses. Become familiar with their skill sets. Now here's the
rub: when you have identified a weak spot, you must seek to build
that skill up. If you have a developer that isn't up to speed on a
particular project, develop a program or a plan to get them
cross-trained. This accomplishes two things for the organization:
1) You wind up with one more trained resource that can fill in on that
project when needed. When someone is out on vacation, you have bench
strength to take over. 2) You keep that developer's interest by
offering something new to learn. As a rule, developers love building
up their skill sets. Cross training is vital to your organization
and to your individuals and will help you always have the right tool
for the job. Be careful not to confuse cross-training with resource
allocation or moving people around to try to meet deadlines faster.
Educate
Educate your team. Pay to train your
developers in new technology or to refresh or polish old skills.
Yes, pay. Budget for it. It may not be reasonable for your company
to formally train every developer on something new every year.
That's ok, but you need to have a plan. Publish it. Make it fair.
As in the previous point, developers like to build skills. If you
help them, they stay engaged and grateful. Bear in mind, you
shouldn't be training them to leave your company. Learning new
tricks should benefit the firm too, so the plan must have a clear set
of mutually-beneficial goals. Allowing self-study through book or
online purchases is definitely a good thing and should be encouraged.
Letting your dev team buy books is a pretty cheap way to keep them
learning. However, that cannot be the sum total of your plan. Look
for conferences, training classes, technology seminars from gurus,
and the like.
I wish I could say that if all
companies got all this stuff exactly right that there would be zero
percent voluntary turnover. The truth is that some people will
choose to move on even if you create the perfect place to be a
developer. There are a lot of reasons why and not all of them are
about you or your company. However, I can say with some certainty
that, based on my personal experience, the more of this stuff you get
right, the lower your turnover rate will be. The opposite is also
true, if you erode any of these principles or just don't think
they're that important, you will start to suffer some brain-drain.
Don't let it happen, take some positive steps now to build up your
development staff.
This article is intended as five quick
bullet points with just a smidgen of info on each point. There is a
ton already published out there on each of these topics. Start
researching and learning more if you think you need help in any of
these areas.
Thanks for reading,
Eric
Shameless Plug:
I have spent the past thirteen years
writing code and managing teams of software engineers in the
financial services industry. To learn more, look me up on LinkedIn.
