In his book, Drive, Daniel Pink describes two fundamental approaches to motivation:
If you’re not sure what the difference is, then here’s an example.
Let’s say you’re taking a holiday in a hotel room with a beautiful mountain view. The hotel provides coloured pencils and art paper. During your stay, you choose to draw a picture of the scenery outside your window. You do so because you enjoy creating art. Your motivation to draw comes from the enjoyment you get simply from doing it. That is intrinsic motivation.
Now, let’s change the scenario. Rather than taking a vacation, let’s say that I invite you to spend a day in the hotel room. I offer to pay you $1,000 if you draw a picture of the view outside the window. Even if you enjoy drawing, your primary motivation in that case is the money. That is extrinsic motivation.
We experience both types of motivation in our lives. We work because we need to earn money –– extrinsic motivation –– but many of us, especially in dev rel, are lucky enough to have jobs that give us a sense of reward just by doing them.
So, which picture of the mountain would be better? Perhaps the one I pay you for; after all, you’re earning a thousand bucks for drawing a picture.
However, according to a field of academic research known as self-determination theory, the picture you draw for fun will probably be creatively and technically better. Why? Well, it comes down to how different types of motivation affect different types of work.
Creative tasks, such as drawing a picture, writing code, or finding a solution to a business problem, are examples of heuristic work. As the person doing the work, you experiment until you find the solution. Work that has a fixed set of steps, such as washing dishes, is algorithmic.
A classic study, known as the candle problem, shows that extrinsic motivation narrows a person’s focus and leads to worse outcomes in heuristic work. Similarly, Harvard professor Teresa Amabile focuses on how extrinsic motivation –– very often in the form of money –– kills creativity.
What does that have to do with community champion programmes?
Software developers become involved in communities for practical reasons: to learn more, fix a bug, network, write an SDK in their preferred language, and so on. But what prompts someone to go beyond and become a net contributor?
Let’s say a developer wants to try something new with an API. There’s no documentation on that particular topic. So, she visits the API community’s forum to ask for help. Someone answers with just enough information to help her work it out for herself. She then writes a post on her blog that describes her solution.
Many community participants would gain an intrinsic reward from writing that blog post. It feels good. Cynics might also note that it could drive traffic to her website and thereby lead to extrinsic benefits, such as framing her as an expert on that API.
But what would prompt her to make a pull request, covering that topic, on the API’s official documentation? Of course, some developers would go ahead and do that anyway but most would see the blog post as enough.
As a developer community manager, you might create a framework that encourages people to make contributions that have a greater impact. An update to the official documentation will help everyone, whereas a blog post will help only those who stumble across it.
The question is: does such a framework provide short-term gains at the expense of long-term contributions? The answer lies in how your community process impacts people’s autonomy.
Many developer champion programmes have rigid requirements for membership. A developer must have answered X number of questions in the forums, written Y blog posts, and spoken at Z meet-ups over a 12 month period, for example. In return, the status of champion gives the developer certain extrinsic rewards: access to the product’s engineers, free travel to the annual developer conference, a badge to put on their LinkedIn profile.
The danger is that your champion programme turns something that people do for fun into something that feels like work. You replace the intrinsic motivation with extrinsic motivators. But you can mitigate that risk by ensuring that your developer community members feel in control of how they contribute.
Let’s look back at self determination theory. Researchers Edward Deci and Richard Ryan posit, in their seminal book on the subject, that humans work best and feel happiest when they feel autonomous, competent at what they’re doing, and connected to other people. Those three things are at the heart of the very best developer communities.
The risk comes when we try to control –– or gamify –– what people would otherwise do for intrinsic reward. If your champion programme sets rigid membership requirements, then you both reduce people’s autonomy and you narrow their focus to meet the requirements rather than making creative contributions that you couldn’t have anticipated. Perhaps worse is when you reward a top community contributor with champion status and then ask them to meet your criteria to qualify again the following year.
Unless your developer relations programme has a very narrow focus –– and you are willing to risk both reducing people’s creativity, as well as making participation in your community less fun –– then you should avoid prescriptive champion programme requirements. Instead, create a framework that works with people’s need for autonomy, their desire to feel competent, and their requirement for connection with others. Develop an environment that allows members to make contributions that they find intrinsically rewarding.
There is the small matter, though, of meeting your company’s goals. A community of happy, autonomous members is a good thing but your execs will ask why they’re funding the community unless it provides a return on their investment.
So, how do you create a community process that gives people their autonomy and lets them derive intrinsic rewards, while also complementing your broader developer relations strategy?
There are three things you can do:
That last one needs a little more unpacking. Instead of asking people to answer three forum posts each day, for example, you should measure “contribution events”. Contribution events can be anything that you decide in retrospect had a meaningful benefit to the community. Crucially, you do not state upfront what people should do but, instead, you recognise them for the valuable things that they chose to do. Champion status then becomes a “thank you” rather than a rank to be won by following a certain algorithm.
Prescriptive champion programmes risk destroying the very value they’re designed to encourage. Great champion programmes, instead, recognise that people are at their most creative when they do work for its own reward. If your community process thanks people rather than telling them what to do, then you’ll work with the grain of human nature rather than making people feel like you’re just another boss.
Indeed has seen a huge uptick in Hacktoberfest participation from their engineering team. Hear how they did it.
People were organising communities long before developer relations. So what can we learn from those that went before?