How to Motivate Developers - A three step framework

No . . . . not THOSE three steps!

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.

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




This article was first posted on Frank Kelly's blog.