In his book, Drive, Daniel Pink describes two fundamental approaches to motivation:
- Type X relies on extrinsic sources of motivation.
- Type I relies on intrinsic sources of motivation.
If you're not sure what the difference is, here’s an example. Imagine you contribute to an open-source project simply because you enjoy solving the problem, learning something new, and helping others. That’s intrinsic motivation. Now, let’s change the scenario: you’re being paid for each contribution. Even if you still enjoy the work, your primary motivation has shifted to the financial reward. That’s extrinsic motivation.
Which contribution will be better?
We all experience both types of motivation. Many of us work in developer relations because we enjoy helping developers succeed—but at the end of the day, we also need to get paid. So which contribution would be better? You might think that being paid ensures a higher-quality outcome. But research from self-determination theory suggests otherwise: when a task is creative or heuristic (meaning the solution isn’t obvious), extrinsic motivators like money can actually reduce quality.
A classic study, the candle problem, shows that external incentives narrow a person’s focus and lead to worse outcomes for heuristic work. Similarly, Harvard professor Teresa Amabile’s research highlights how extrinsic motivation—very often in the form of money—kills creativity.
What does this have to do with developer champion programs?
Champion programs introduce extrinsic motivation
Developers join communities for practical reasons: to learn more, fix a bug, network, or contribute something useful. But what prompts someone to go beyond that and become a regular contributor?
Let’s say a developer runs into an undocumented issue with an API and posts a question in the community forum. Another community member responds with just enough information to help them figure it out. Later, the original poster writes a blog post about their solution. That blog post is intrinsically rewarding––it feels good to share knowledge, and it might also boost their reputation.
But what would prompt them to go a step further and submit an official documentation update? Some developers would do it anyway, but most would see the blog post as enough.
That’s where tasteful community interventions come in. You might create a champion program that encourages contributions with structured incentives. The challenge is that these programs often shift motivation from intrinsic (“I want to contribute because I care”) to extrinsic (“I need to hit a contribution target to maintain my status”).
Autonomy, competence, and relatedness
In the past, many developer champion programs relied on rigid contribution requirements. A developer might need to answer X forum questions, write Y blog posts, and speak at Z meetups over a year to qualify. In return, they'd get extrinsic rewards: direct access to engineers, travel sponsorships, a LinkedIn badge, or even laptops.
But here’s the problem: when you take something people enjoy doing and turn it into work, the research suggests that they stop enjoying it. The intrinsic motivation that made them great contributors in the first place gets replaced by a checklist of obligations.
Self-determination theory tells us that people are happiest and most productive when they feel three things:
- Autonomy – control over how they contribute.
- Competence – confidence in their skills.
- Relatedness – a sense of connection with others.
Rigid champion programs undermine autonomy by dictating how people should contribute. Worse, if developers need to re-qualify every year, they may stop seeing contributions as voluntary acts of community and start seeing them as painful obligations, on top of everything else they have to do.
If your champions program is highly prescriptive, you risk making participation feel like a job and that might reduce creativity, lower engagement, and make the community feel transactional. Instead, we should try to design programs that aligns with people’s intrinsic motivations. And, yes, that probably is easier said than done.
Meeting your goals and giving your community autonomy
But while we want to meet our community members' need for intrinsic rewards, developer communities still need to show value. Your execs won’t fund a program just because it makes people feel good. So how do you balance community member autonomy with business goals?
Here are three ways to ensure your champion program supports both developers and the company without undermining intrinsic motivation:
1. Shift from top-down goals to shared purpose
Many developer programs are designed with a simple formula: "We want X contributions, so let’s create rewards to incentivize them." But this approach treats engagement as something to manufacture rather than something to cultivate. Instead, start by defining the bigger purpose that developers can align with. True communities are where people come together towards a shared goal.
Instead of prescribing specific activities, help developers understand how their contributions support that goal. If they believe in the mission, they’ll naturally contribute in ways that align with your goals.
Example: If your goal is better documentation, don't create a rule that says “write three docs to qualify.” Instead, highlight gaps in documentation, provide ways for developers to identify what’s missing, and show how their contributions will help others. The key is to frame participation as a meaningful opportunity rather than an obligation.
2. Recognize contributions in ways that reinforce intrinsic motivation
Many companies instinctively tie recognition to structured rewards: “Answer X questions, and you get a badge.” But extrinsic rewards can displace intrinsic motivation if not handled carefully. Instead of making rewards the reason people contribute, treat recognition as a way to amplify the natural satisfaction of contributing.
Public acknowledgment, such as thanking contributors in community calls, featuring their work in newsletters, or highlighting their impact on product decisions, reinforces a sense of competence and relatedness.
Instead of transactional incentives, create an environment where contributions feel valued because they matter, not because they check a box.
Example: Rather than offering fixed perks for specific actions, recognize contributions organically. If someone writes an outstanding guide, don’t just give them points. Instead, feature it, share why it’s valuable, and get to know what their motivations are so you can work with help them achieve them.
3. Rethink how you define and measure contributions
Many champion programs define contribution in rigid, quantifiable ways: X blog posts, Y talks, Z pull request. This structure makes it easy to measure activity, but it also funnels creativity into predefined tracks, which can alienate developers whose strengths don’t fit the mold.
Instead of tracking contributions as predefined actions, track contribution events: instances where someone made a meaningful impact. These could be anything from a well-received blog post to a thoughtful answer in a discussion thread.
The key difference is that you’re recognizing impact in retrospect, rather than prescribing it upfront. This allows developers to contribute in ways that align with their strengths while still supporting your community’s growth.
Example: Instead of setting fixed requirements, use retrospective evaluations to identify and thank contributors whose work had a meaningful effect. This shifts the dynamic from “checking off a to-do list” to encouraging creative, organic engagement.
The strongest champion programs work with intrinsic motivation, not against it
Rigid, prescriptive programs risk making contributions feel like work. When that happens, people either disengage or optimize for the easiest way to meet requirements, rather than making the most valuable contributions.
Great champion programs take a different approach. They trust developers to contribute in ways that feel natural to them while reinforcing autonomy, competence, and relatedness. When you design your program to support, rather than control, how developers participate, you create an environment where people want to contribute because their desires align with the community's needs, not because they’re chasing a reward.