Making use of intrinsic motivation

There are two kinds of motivation, intrinsic and extrinsic. Going to work because someone pays you regularly is extrinsic motivation. So are other material rewards and moving up the career ladder. Going to work because you enjoy it is intrinsic motivation. Another example is wanting to learn something new, or taking pride in doing a job well. The trouble with extrinsic motivation is that it scales only so far. There’s no direct relationship between quality or performance and, say, the money you put in. Intrinsic motivation is the other way around. You get a lot for very little. It has two drawbacks. Different things motivate different people, and it can be hard to put that motivation to work effectively for the team and the company. I’ll try to offer a few ideas for doing it.

People don’t do things just because you tell them to, or they do them badly. If you join our team and I review code that has no tests, I won’t tell you we write tests because we want some particular level of coverage (extrinsic motivation). I’ll ask whether you want to deploy that code straight to production. Unless a developer understands they’re writing tests for their own peace of mind (intrinsic motivation), they’ll never do it properly or well enough.

Almost every bad experience I have with an internal library, component or service comes down to there being no clear owner. It’s a bit like communism. The library belongs to everyone and no one, and it shows. Things are much better when there’s an owner, because ordinary vanity kicks in (intrinsic motivation). Few people want their name attached to a pile of manure, so to speak. If it does get attached, they almost always want to do something about it. You do have to take care that some bureaucrat at a desk doesn’t assign ownership. That would give you an owner on the org chart (extrinsic motivation), but no feeling of ownership. Vanity is a great thing if you know how to use it. Perhaps professional pride would sound better than vanity, which has negative connotations.

Our work as developers is highly creative. Every day we face new problems that might fit into familiar categories such as API design, scalability or efficiency. The actual solutions always differ and take a creative approach. Unfortunately, creativity can’t be scheduled. You can’t tell yourself to start being creative now, close your computer in eight hours and go home. Creativity goes hand in hand with freedom, and with freedom comes a sense of responsibility (intrinsic motivation). Give people freedom to choose their tools and methods. That supports their desire to solve the problem (intrinsic motivation) more than telling them how. Better still, they see the problem and who’s affected without being told, and they can choose its priority as well as how to solve it.

One way to give people freedom is to let them spend some time on their own projects. It shows you trust them, and gives you a natural way to find out what they enjoy and would like to do. We’ve had great results with hackathons. Everyone wins. Developers work on something useful to the company that interests them too. Almost every hackathon produces something useful that wouldn’t have found its way in through the project backlog or another planning process. Some time for personal projects means ideas don’t stay in a drawer (intrinsic motivation). People get a chance to work on them at least now and then.