How to Motivate Developers - A three step framework
Join the DZone community and get the full member experience.
Join For Free
Anyway, now that we're approaching the end of the calendar year, invariably many folks are filling out self-evaluations and managers are presiding over year-end reviews, and choosing raises and bonuses for their staff.

No . . . . not THOSE three steps!
Managers
should also be considering the year ahead and one of the most important
aspects - developer productivity. A key element of productivity is
motivation and this article tries to answer the question "How to
motivate developers".
But first some comments on prior work . . . .
There
have been quite a few blog articles written by others on this topic
(see some references below). They're pretty solid but they're mostly
written from the perspective of
1) Developers or
2) Managers who don't have a major technical background.
The problem with #1 is that self-reporting of what a person wants is very unreliable.
Often people don't really know what they want. Or they know what they
want but don't truly understand how it will make them feel or for how
long (see this really great article on happiness for some more insights)
The
issue with #2 is that, without knowing the perspective of the other
side (developers understanding what it means to be a manager and
vice-versa) the full picture is often lacking.
One thing I
noticed in my research for this post is that many of the articles below
try to ask "What do developer's want?". That's important but a bit
misleading. For example take a more common situation - housework. I
don't want to do the dishes - I'd rather be playing Call of Duty 4
- but I *have* to. For many reasons - the sanitary one is obvious - the
not so obvious one . . . . my wife will kill me otherwise :-) So what's
my motivation - good health and staying alive :-) What motivates me
isn't what I want.
There's also another aspect to this that I
feel people haven't considered. I am going to venture (without citation
. . . I couldn't find one) that the majority of a person's motivation
is intrinsically determined. That is - their motivation level is
largely driven by who they are, their personalities and things in their
lives you have no control over.
So please don't get the idea
from this that I believe one can control 100% of a developer's
motivation. You can influence it, but only so much. In many respects
motivation should be a key aspect when interviewing new team members -
because once they're hired you can only impact a relatively small
aspect of their motivational make-up. Again that's based on experience
- I'm not aware of any scientific studies to confirm this hypothesis.
To
repeat, I feel that, to a large extent, people are already largely
motivated or not. You can improve things quite a bit though. Say you
could make a developer 5-10% more effective - that's like having an
extra 2 weeks to a month of their development time each year.
That's
a lot of extra bugs fixed or new features produced. Do that across a
team of 6-8 developers and you can make a very noticeable improvement.
Anyway
after thinking about it - from both a managerial and developer
perspective, here's what I've come up with for my framework.
STEP 1) Compensate Well
This is one of those "necessary but not sufficient"
conditions you often hear about. You can address every other
motivational item but if you don't pay well and give good benefits
you're shooting yourself in the foot and worst of all people are going
to go elsewhere. Probably most of all you're just not going to be able
to attract and retain really good (i.e. already motivated) developers.
If you think of the famous Maslow's Hierarchy of needs, this is one of those fundamental "lower" or more basic needs.
STEP 2) Remove or reduce demotivating aspects
You
can pay all the money in the world to people but if you have
non-existent specs, unrealistic deadlines, micro-manage etc. people
aren't going to be motivated for long and they will quickly become
unmotivated or leave.
As I just stated there are several things that many developers experience that drive them batty.
i) Poor requirements
- there's nothing worse than building junk but consequently (for me at
least) there's nothing better than great (detailed, unambiguous)
requirements and the resulting happy users.
ii) Unrealistic deadlines
- whether this results in 90 hour+ weeks or buggy software - this is
very much a drain on developers, their ego and sense of pride.
Developers want to be proud of their work and go home and see their
families. Is that too much to ask?
Yes everyone has crunch times
and there's invariably some extra unforeseen work but hopefully it's
infrequent and as a manager hopefully you don't have to "go to the
bank" too often.
iii) Too many meetings
- I've found that the more formal a place is (or the less friendly it
is) the more meetings you need to just get people to talk to each
other. But many meetings are a bad sign - ideally developers
would/should be able to talk to each other and meetings should be
"organic" and not forced.
iv) Disrespectful or uncooperative colleagues.
"Bad apples" can ruin a whole batch. The problem is exacerbated when
management is unaware of them or worse, is aware, but refuses to do
what it takes to remedy the situation.
v) Processes, Tools or Techniques that slow you down e.g. slow builds, slow unit tests, slow desktops etc. They suck productivity and reduce enthusiasm.
vi) A poor work environment
e.g. a place where it's too loud, there's no privacy, you get lots of
interruptions etc.. A bad environment can destroy motivation or at the
very least be a distraction. And distractions are TERRIBLE for a
developer's focus on the problem at hand.
Either way, my recommendation is that before focusing on MOTIVATING factors, I would focus on removal or amelioration of demotivating factors. There's also some evidence that there is some psychological difference between demotivating aspects and motivational factors.
The
good thing is by focusing on these e.g. improving requirements,
reducing unnecessary meetings, speeding up processes etc. you are also
improving team productivity even if there's no motivational boost
to be had. But that's unlikely - removing some of those impediments
should buy you some good will - but frequently that fades over time.
Either way, for the productivity boost alone that's makes good business
sense.
STEP 3) Focus on positive motivational aspects.
Here are the things that you really are hoping will translate into more motivated (and more productive and happy) developers
i) Support Developer Learning
Developers
love to learn - new languages, new tools, new frameworks. Spring, Ajax,
Hibernate, Ruby - that gets their juices flowing. Now the challenge is
how do you direct that to produce the product you're paid to . . . . .
the key here is to align the new item with key gaps needing filling.
Need an Object-Relational Mapping system - Hibernate! Need a rapid
prototyping language - Ruby! etc. You also need to factor in the
productivity dip as they learn.
ii) Provide Challenges & Problem Solving Opportunities
Developers
in general love to solve problems - whether it's how to integrate new
features into a legacy system, how best to compare two lists of strings
or how to make a system more scalable developers love such problems.
In
my experience however there are sub-types - different developers who
prefer different kinds of challenges - ideally again you would align
the challenge to the person who wants it!
iii) Provide Feedback
Developers
want to learn and grow - beyond the technical learning / challenge they
also need feedback in other ways to help them grow as individuals and
adapt to their organization. Often I find this is where management
falls down. Who could blame them / us - we often say we're open to
hearing about areas needing improving but not so good in practice. I've
found the Sandwich Feedback Technique works quite well though.
iv) Other Ideas
See the section below for other really good ideas from other articles
These
are all the things that "developers" want, in the sense of the higher
"self actualizing" levels of Maslow's hierarchy. Again, these factors
should not be detached from "conditions on the ground" as it were.
For
example I've known a few developer's whose idea of self-actualizing was
deciding what to eat for lunch that day. They didn't want to learn
ANYTHING new - no new languages, no new environments - they know what
they have and don't want to change. Their motivation isn't going to
take a boost from being asked to learn something - on the contrary.
STEP 4) The Secret Step - Fear as motivator
OK
I said there were three steps, but here's that "magic" 4th step. The
"nuclear option". Go here only when you must e.g. you or someone on
your team might be fired unless some action is taken, a client could
lose a lot of money etc.
As with the "doing the dishes" analogy,
there comes a point when you have to do what you don't want to do. You
do it because the ramifications of not doing it are worse - MUCH worse.
Often
if you're seen as the "good cop", you need a "bad cop" to make this
work. Sometimes you might need to be the "bad cop". Most folks know the
analogy having seen it many times on the various CSI or Law & Order
shows on TV.
Basically the line here is "Do this or you'll lose your bonus / won't get a raise / be fired".
As
I said you can't rely on using this too often, but you need to be sure
also that people know the chance is there. Developers are smart people
- if you don't follow through on what you promise you lose credibility.
This lesson on follow-through was something that my two year old taught
me. "If you don't get down from that chair, you'll get a timeout".
Guess what, unless you start handing out "timeouts" they just will
continue to stand on that chair.
Again you don't want to do it
too often and when you do you need to explain the reasons, it can't be
seen to be arbitrary. For example - fire too many people, and people
will start updating their resumes and looking elsewhere rather than
live in fear. Don't fire anybody and you send the message that there
are no consequences and people want to leave because they tire of
supporting the slackers. It's a fine line but most of your strong
developers already can identify who isn't pulling their weight and will
thank you for pulling the trigger and finding someone better.
Anyway there's my thoughts on developer motivation - I look forward to your comments.
REFERENCES TO RELATED WORK
Nine things developers want more than money
1) Being Set up to Succeed
- Good requirements
- Realistic Deadlines
"Being forced to build crap is one of the worst things you can do to a craftsman"
2) Having Excellent Management
3) Learning New Things
4) Exercising Creativity and Solving the right kind of problems
5) Having a voice
"When
a developer speaks, someone should listen. When several developers are
saying the same thing, someone should listen and act . . .quickly"
6) Being Recognized for Hard Work
7) Building Something that Matters
8) Building Software without an Act of Congress
9) Having Few Legacy Constraints
Top 10 ways to motivate geeks
1) Geeks are curious. Let them feed their desire to learn things
2) Geeks like to be self-sustaining. Let them figure things out on their own.
3) Geeks are creative even if they don't know it. Give them a chance.
4) Geeks need tools, good ones. Give them more than they need.
5) Private, yet collaborative. Geeks need to be left alone, but not too alone.
6) Free stuff. T-shirts, food, desktop widgets, whatever.
7) Control
8) Geeks need recognition
9) Freedom
10) Compensation - Saved this for last, but geeks gotta live too
Motivating Software Developers
1) Allow me to focus
2) Allow me to feel that I am making progress
3) Allow me to make something I can take pride in
4) Allow me to do it for me, not for the money
5) Allow me to work on interesting problems
6) Allow me to be part of a team
7) Allow my ideas to be taken seriously
What motivates software developers?
1) Introduce new technologies and techniques
2) Practice pair programming to encourage communication, sharing of skills and team building
3)
Encourage participation in community developer events (user groups,
code camps), blogs (share links across the team), books (monthly
bookshelf anyone?) and conferences.
4) Avoid generalized training - in my opinion this tends to serve the paycheck programmer more than the dedicated ones.
5) Interesting projects
6) Satisfy your customer
Motivating Software Developers
To Motivate or not to demotivate
"Only
taking away the things that make people dissatisfied, will simply
result in people having neutral feelings towards their jobs."
Some programming principles: People
Managing and Motivating Developers: Tips for Management Cluefulness
What makes people tick - 10 motivation factors in the workplace
"The first thing to note here is that most people are motivated by:
1. doing interesting stuff
2. feeling recognized and appreciated
3. making an impact"
What motivates programmers?
11 ways to motivate geeks
Five things your manager could be doing better
 From the art and craft of great software development and architecture
Opinions expressed by DZone contributors are their own.
Comments