How to foster intrinsic motivation in a software team [closed]

Question

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?

EDIT: Please provide comprehensive answers. Share your personal experience with objective analysis.

EDIT #2: To facilitate a productive and on-topic discussion, we should assume that monetary compensation is satisfactory to the developer.

Answer 1

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.

Signs: 'facebook blockers', fixed worktimes, desk regulations. (I think Jeff Atwood wrote sth. about 'Furniture Police')

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.

Answer 2

As part of your Software Development Life Cycle

• Assign the right tasks to the right people (if possible)
  • This implies that they want the task in the first place
  • If not, consider that maybe this task should not be done
• Assign challenging tasks
  • 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

Answer 3

I think most business (co)owners are missing a point here.

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.

Answer 4

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 equipment.

Answer 5

By trusting their developers to do the right thing

Most developers will try to develop quality products if given the facilities to do so. If a developer asks for faster equipment or better monitors or quiet working conditions - work to provide them.

Answer 6

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).

Answer 7

Let me play the devil's advocate.

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.

Answer 8

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.

Answer 9

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.

Answer 10

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.

Answer 11

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.