Jeff Atwood's blog post on Amazon's Mechanical Turk suggests that it should not offer monetary rewards but rather intrinsic motivation, "motivation that is driven by an interest or enjoyment in the task itself, and exists within the individual rather than relying on any external pressure."

How does a team member (a manager, a lead, or a developer) foster intrinsic motivation in a software team?

11 Answers
11

By not killing it. I bet, everyone working longer than 5 days has met enough motivation killers to fill books. Everyone swears, if they have the opportunity, they will do better. But somehow, these killers persist, and those who implement them usually keep thinking, they are better, 'still one of the good guys', etc.

So, in my opinion, the best way isn't not to try to do good, but to avoid to do bad.

EDIT, Amended on Request:

The Long Version

In my opinion, intrinsic motivation is strongly connected to the identification with the work/the company.

Identification comes from to identify, as in 'to make sth identic', so someone who identifies himself with his work tries to have as little differences as possible between 'doing the work' and 'doing the thing he wants'.

Therefore, everything that forces a decision between benefiting The Company/The Team by working and benefiting oneself is a potential motivation killer, and as such, should be avoided.

Some of those killers i encountered are:

Broken Communications: It matters mostly, how and to whom one says something instead of what. The motivation
to do the right thing (ad res) is punished by killing the messenger, laughing at cassandra and publicly executing the atoner.

Signs: a lot of cc, bcc and to in emails, and a discrepancy between things said in meetings and things said in the cafeteria.

Form over Results: It matters mostly, how work is done, not what it produces. The motivation of producing
something of value is killed by not appreciating the thing produced and punishing the production. It is way easier to just produce nothing by following protocol.

Boredom/Dead End: In this job, when one stays, one misses something, be it the opportunity to learn, to get to a different area
of expertise (e.g. from coding to design) or to get a pay that can provide for a family. And the longer one stays,
the lesser opportunities there are.

The choice is between improving the company and improving oneself.

Signs: everyone is known as 'the X guy', where X is the thing he's done forever.

AAA+++ would upvote again. I phrase this as some variation on "Give the team a task, give the team the tools they need, and then get out of their way". If a manager can spend their time not only not being in the way, but clearing other problems out of the way, then they're a winner.
–
Tom AndersonMay 23 '11 at 16:02

+1 best answer right here - because by definition intrinsic motivation cannot be fostered externally, but it certainly can be destroyed!
–
Steven A. LoweMay 23 '11 at 20:33

+1 for a good answer. That makes sense. Could you go into more detail (perhaps provide a list) on common factors that kill intrinsic motivation?
–
Matthew RodatusMay 24 '11 at 15:38

People are very egoistic creatures. They're mostly concerned with themselves. Very difficult to change that. Therefore you need to explore this weakness and turn it to your advantage.

When people possess "an interest or enjoyment in the task itself" that means they're pursuing their personal interest to satisfy their curiosity or learn some tool. Why learn some tool? To use it in their personal programming (self-oriented) or to turn it into a marketing advantage (greedy profit). There is hardly any trace of altruism.

In order to "foster intrinsic motivation" you must put your goals inside a sweet bounty that team members would want to have. Combine what is valuable to the company (knowledge and expertise in some technical or non-technical domain) with what is valuable to the individual personally (renowned certifications, job title, salary bump). Think in this direction.

And to be honest, yes, there are of course altruistic individuals. Without them the world would have fallen already. But then they're not necessarily interested in joining your ranks, they can always find another way to contribute to the society (open source, personal projects, providing assistance in forums etc.). So you're back to the basics, how to lubricate your greedy programmers to get them moving.

-1. People are in fact not egoistic. Thousands of years of evolution have taken care of that, and it's easily proven. However, people can act egoistically. And it's fairly predictable when they will do so - egoism strongly correlates with social exclusion. BTW, _under_paying people shows a lack of appreciation, which leads to a feeling of exclusion, which leads to egoism. That's why payment is a social hygiene factor: it doesn't motivate, but it prevents demotivation.
–
MSaltersMay 23 '11 at 14:47

Sure, go ahead and provide the best tools money can buy, put devs in own offices, dish out free meals/beer o'clock/trip to Venezuela/whatever.

These are all really great perks, but at the end of the day they serve but one purpose - increasing owner's profit (and apparently making developers "have fun" at work). And that's perfectly fine.

But, for all of us who have a life outside day job, I say, yes I'd like those perks please, but they are in no way a substitute for my bonus/reward/13th salary/whatever - monetary motivation works quite fine for me. If it does not seem to work, maybe the people managing the company are not dishing out enough cash at a reasonable pace.

@Matthew Rodatus - I think that @haylem has covered that pretty well, but I think it's dangerous to overlook the point being made by @Jas here. I've heard of some managers focusing on only the intrinsic motivation, and that's as big a mistake (if not bigger) than not focusing on it at all.
–
Ben HockingMay 23 '11 at 13:37

2

in line with my answer of not killing motivation: one may not be motivated by money, but realizing that your work is not appreciated enough to be compensated with usual sums may kill motivation.
–
kepplaMay 23 '11 at 15:08

As part of your Software Development Life Cycle

Programmers are creative people, and will prefer to have a task that is mentally challenging and not just over-redone rework of something they have already done.

Of course you can only assign the tasks you have at hand as part of your requirements, but try to identify how each of these requirement can represent a challenge, and pick the right developer for it. If your requirements are always the same and boring then there's also something to be done here. There's no intrinsic motivator here, but there's an intrinsic point of failure and redundancy.

Use Continuous Integration/Inspection games

They are fun and motivational

They encourage people to strive for perfection

They are not intrinsic in themselves, but they just appeal to the internal quality of the develop who wants to perfect himself, learn and share, but might need an occasional push.

Use Wallboards (or Radiators) for SCM, continuous integration and continuous inspection tools are fun and motivational (you need these as part of your infrastructure, by the way)

They appeal to developers for the same reasons as the CI game

Even without the competitive aspect, they give a sense of pride and entitlement to the developers who take part to a project.

It allows them to see the evolution of a grander design if they are part of a large team.

It also helps to get your teams (and not your developers, individually) to:

compete (across projects, on code quality for instnace - do not compete on LOCs...)

collaborate (by wanting to build software that belong to a family)

Use retrospectives

They help identify issues in a collaborative manner

They give developers a sense of belonging to the project (and its mistakes)

They assign neither reward nor blame (but do give a sense of responsibility)

code reviews have to be an integral part of the process (or they will fear them instead of embracing them).

Developers will naturally learn to seek and strive for praise

They will be more open to criticism

Allow (and encourage) for creative and constructive criticism

Allow (and encourage) personal development

In the form of pet projects

In the form of prototypes (which can be pet projects)

Developers are happier when they don't need to hide at their office

Allow (and encourage) knowledge sharing

Allow (and encourage) developers to polish their code

Moving on to the next task can be exciting, but being forced to abandon a task you worked on for a while without finishing it to a satisfying level of quality is bad for many reasons. You lose these feelings mentioned above (pride in good work, craftsmanship, etc...) and you will lose on quality.

Allows the developers to have fun while finishing their tasks, experiment with alternate implementations (potentially beneficial for you if benchmarks come along)

Rotate annoying tasks between teams/individuals

To ensure that multiple persons have the necessary skills

To have them share their burden and feel a bit more compassion for the ones dealing with ungrateful tasks at some time (instead of pointing their peers with a "Ahah!"), and wanting to help them

Do anything you can to avoid the cow-boy coding or submarine effect: you want your developers to be proud of what they do, to enjoy what they do, and to enjoy showing it to others and have others participate in their effort.

Even for documentation tasks, which can be rebarbative for programmers, do try the following, to make documentation more fun for them, and link it to the feeling of producing a well-finished product. Documentation must appear as an integral part of the product itself, not just a formal deliverable.

Allow them to use the tools, templates and process they want

set them before the project starts and stick to them for consistency

but review them between projects as part of your retrospective to ensure the process is as light-weight and enjoyable as possible

using an ugly (and, above all, impractical) template forced onto you by the marketing department is a downer

Allow them to discuss points of documentation that they feel are overkill

they might be right and help you reduce the load

Make them become teachers, evangelists or anything that puts them in the position of bringing know-how or knowledge to others, both as part of your SDLC and of your corporate culture. Anyone who has had the chance to teach knows the feeling it procures, even when your students don't show signs of gratitude (well, you might just be thinking you're helping them and in fact be a crappy teacher and that's all... but still, let's consider a a general case...) and you don't get any direct reward. Plus, it's at the same time empowering and humbling (you'll always find someone who'll prove you wrong or fight you on something).

The following sections outline points that are not really intrinsically motivational.

While they may not relate directly to the question, I prefer to leave them listed as they still are, in my opinion, good pointers to indirectly help foster this intrinsic motivation.

As part of your Corporate Culture

set up regular talks/sessions for developers to share...

... knowledge they acquired while working on the project

... knowledge of anything that gets them active and passionate about something

trust your developers

leave technical decisions to technical people

make them part of the decision process

listen to them (or don't be surprise if they shut up)

make their lives easier and frustration-less:

good development tools

good hardware

good environment

free food

stupid toys lying around

places to discuss ideas, and places to reflect quietly

For new starters

Outline achievements for new starters (think StackOverflow-style stages and awards they need to "unlock")

Assign them tasks within their skill-level, but with enough challenges

Remember that the definition I gave for intrinsic motivation is that it is "motivation that is driven by an interest or enjoyment in the task itself." A lot of what you mention goes beyond the task itself. Could you explain how those things help foster an interest or enjoyment in the task of programming? Not so much in the social activity of programming.
–
Matthew RodatusMay 23 '11 at 13:46

@Matthew Rodatus: Sorry, I had mentally skipped over that I think. I guess that in this case, all the corporate culture aspects are not intrinsic. However, most of the points mentioned in the first section appeal to values that the developer must already hold: you are just triggering them as a reaction. Yes, it implies an external action, but you did mention that you wanted to foster this intrinsic motivation. I'll try to expand on this later tonight with your comments in mind, but it was a quick answer over my lunch break.
–
haylemMay 23 '11 at 13:56

@haylem Thanks for the effort -- and I agree that most of the points in the first section can foster intrinsic motivation. Good work.
–
Matthew RodatusMay 23 '11 at 14:08

@Martin: Yes. As in, they are external rewards. However, they do not give you a physical reward, nor do they even give you points, even though it's comparable, I guess. But it does appeal to internal qualities: pride for good work, desire to atteign a craftsman status and show a certain skill-level, etc... I guess a lot of indirect motivators do appeal to intrinsic values.
–
haylemMay 24 '11 at 2:20

In my opinion, intrinsic motivation maps to the last need of individuals in the Maslow's hierarchy of needs; it is not a need in itself, but one that comes out of self-actualization. While this hierarchy might not be applicable in all circumstances, ignoring the basis of this hierarchy often leads to lack of intrinsic motivation.

While most organizations strive to get individuals to attain their last need, most don't for they do not focus on the needs at the bottom of the hierarchy.

Motivation depends on the attitudes towards the tasks that need to be done.
If we have an attitude to shine or excel at a task, we might actually be doing worse. Think back on the days when doing tests at school or be part of a sports club, where you wanted to excel or win the game. A performance mindset results into pressure that often hinders us to perform really well or to find creative solutions (see Dan Pink on Motivation). Therefore, using rewards based on one's performance, can actually lead to less intrinsic motivation of doing the task.

In contrary to a performance mindset, there is a orientation towards work based on a learning mindset. Here, the outcome is not important per se, but the process of doing the task and understanding the context of a task. In the sports analogy, this is when you just try to improve a little bit. There is no expectation on ultimately winning, just giving the best and learn from failure. Improving understanding of eventual failure, results into personal wealth and knowledge and can increase our intrinsic motivation on the longer term.
This type of mindsets are discussed by Dr. Steve Ritter (CMU) and Carol Dweck (Stanford).

My take on the article and the theory behind it is that it's an attempt by the owners of business to devalue the cost of labor, and make people believe that "you don't need all this money to be happy so it won't matter if we never give you a raise or if we hire you for below-market rate. You should be happy you have a job at all, let alone one that's so engaging as this, so engage with it already! Now remember, you'd better come in on Saturday from 6am to midnight because that's what an "engaged" worker-bee does. You'll get a nice pat on the head and a 'good job!' once you're done killing yourself for the project."

The study says that it doesn't matter how much you pay someone over the amount which makes them "comfortable" in that they don't have to worry about how they're going to pay their bills or put food on the table... so how much is that? 40k/year USD? 30k?

As far as how to foster intrinsic motivation, I agree with @keppala. Intrinsic motivation comes from within. The best you can do is to not snuff it out of employees who have it.

It is par for the course that the members of a team are motivated differently. Some people work for extrinsic motivation (e.g. money) and others for intrinsic motivation (e.g. quality software).

However, these team members need to be able to work together and share strengths with each other.

A developer is acceptable if they produce quality work; however, if they don't genuinely enjoy their work, it would be difficult to employ them as a leader. An important leadership trait is enthusiasm, because it propels others along in enjoyment of the task at hand.

Another important dynamic is that of healthy, regular social interaction. Joel Spolsky blogged recently about the benefits of team lunches: "Eating together is a critical part of what it means to be human and what it means to have a humane workplace..." Even though the stereotypical developer is introverted, loneliness is demoralizing and makes it hard to enjoy programming.

In summary, through enthusiastic leadership and encouraging comradeship, the intrinsic motivation that is had by some and lacked by others can be transferred to and shared by the team.

Unfortunately, studies show (see this New Scientist article, subscription required for full text) that money is not a great motivator for creative endeavours. In fact it can make people work less hard.

So the best way to motivate people is to help them believe that the work they are doing is not critical to their survival. This will allow them to take greater risks and thus be more creative.

How should you go about this?

Essentially the problem arises because of things like performance related pay. People do need to know that what they are doing is right, but you don't need to make the size of their pay packet dependant on it.

If you want to motivate people with money do it for trivial things like paying attention in meetings.

Creativity is fostered by being in an environment where experimentation is allowed and not punished due to not meeting some target or other.

What you want is to balance the experimentation with the implementation of tried and tested methods. So you invert the problem. e.g. for every N customer issues fixed or for every bland reporting feature implemented, you get to play with some new technology or look into new ways of solving old problems.

If there is money for bonuses, instead use it to go in conferences (that your team wants to go to), or put it towards some sort of experimental/interesting extra-business project (that your team wants to be involved with) to buy equipmant.

I think what Mr. Atwood is saying is you should hire people who are interested in the problems you will be solving. Their motivation derives from preexisting interest, that is intrinsic to the person. I don't think you can foster intrinsic motivation, I think you can only appeal to it.

Compensation is still important, but given the same compensation I'd rather work at a place that has problems I'm interested in. I will naturally, and unintentionally work harder because I have this interest.

@Matthew Rodatus: I think the enthusiasm of the people who find the problem interesting can be shared, not the intrinsic interest. However, enthusiasm can be enough to get everyone in the team motivated.
–
dietbuddhaMay 24 '11 at 16:37

+1 Absolutely true. After ten years in this industry of never really being 100% happy with my jobs (while at the same time loving programming in its pure sense) I've come to realise this is the key. Put me on some random boring business system and I'll be miserable, demotivated, and unproductive, and eventually burn out. Put me on something where the coding is for a problem domain I enjoy, and a cause I believe in, and I'll be a rockstar.
–
Bobby TablesMay 30 '11 at 5:02