Beyond badges: How gamification can supercharge developer engagement

Lauren Lee: Hi, everyone. My name is Lauren, and it's an absolute honor to be here today with you all. So if you were in DevRel around 2017, a whole lot of you here were, you probably remember the rise of TwilioQuest. Suddenly everyone, every booth had pixel art, the eight bit soundtrack, the XP bars. Learning an API felt like a video game.

It was playful. It was creative. It absolutely captured everyone's attention. Now I personally remember this especially well because at the time I was at Nexmo, which is a competitor of Twilio. And thinking of a time, like I wish I could give her a hug because it was impossible to ignore the sheer force of that campaign.

It was everywhere and it worked. And Twilio, I'm obsessed with you still, and I applaud what you were doing. And to those of you who are unfamiliar, TwilioQuest showed us that gamification could, teach developers in a way that was really fun, it's sticky, scalable. Here's the thing though. Right?

Transforming Gamification into Trust Building

You know, back then when gamification and coding and all of those things were kicking off, it often lived mostly inside of tutorials. You know, it helps you get through the docs, sure, but it didn't necessarily lead to launching real projects or or contributing to open source or truly growing a vibrant developer ecosystem. It was a fantastic, maybe onboarding tool, but it often stopped there. So today, gamification has absolutely evolved, but this is the question I've been pondering a lot recently, which is what if it's not just a tool for engagement, but maybe what if it's a tool and a framework for trust? We've seen gamification show up in all kinds of creative ways as of late.

Right? Quizzes, quests, coding challenges, daily streets, and they're all incredible. They're great. They help people learn, stay motivated, have fun. But most of them are still isolated, know, they're designed for consumption, not contribution.

They focus on learning, not on growing inside a community, and that's the shift that we are exploring at midnight using gamification not just to teach, but to grow the ecosystem of builders, our contributors, and our community leaders. So because when gamification becomes infrastructure, tracking real developer activity, surfacing reputation, rewarding contribution, it can do a lot more than just teach. It can scale trust. It can unlock new use cases. It can help grow your developer community from the inside out.

So if any of you know me, I you know that I came to tech via an unconventional path. Like PJ, I was a high school English teacher. I got my masters in education and that background really set me up for a deep appreciation, a love if you will for how people learn, you know, the pedagogical POV. How people stay motivated. Why?

And how they find purpose in what they do. So one psychologist I often reference is B. F. Skinner who asserted that variable rewards, which are outcomes that are uncertain but possible, create stronger engagement than the guaranteed ones. So think about it right.

Sometimes someone let's say reacts to your suggestion in a forum and the next thing you know it's tagged for prioritization by the dev team. And the unpredictability that it's a spark of recognition, it's that maybe this time thrill. It's not just about reward, it's about progress and that drive to move forward. I'd say it's it's in us. It's baked into us from the very beginning.

This is my son, Bo. He's just learning to walk here. No one had to tell him to try. Right? I didn't have to reward him for taking those first steps.

That momentum, I'd say it's natural. We're hardwired to chase a sense of forward motion. Progression doesn't need to be taught. I think it just needs to be supported. So that's why things like XP bars, quests, streaks, they don't just create motivation I'd say.

They reflect it. They help developers feel like they're getting somewhere. They translate invisible effort into visible achievement. That's the feeling of I'm getting somewhere can feel incredibly motivating. But what really stuck with me from my studies was self determination theory from Desi and Ryan, which suggests that people are most motivated when they experience autonomy, competence, and relatedness.

In other words, we want to feel like we have chosen this path, that we are getting better at it, and that we belong. So thinking about designing DevRel systems that actually motivate developers not just once but over time, I've come to realize that it's not about gamifying everything. It's about creating environments where people feel ownership and mastery and community, where their contributions matter and are visible and move them forward. That's exactly the design philosophy we're trying to apply when we built our own system at midnight, one that tracks contribution over time and not just activity in the moment. So that spark of recognition, know, it's powerful.

It feels so good. And when developers feel seen, valued, and trusted, they stick around. They build. They contribute. They lead.

They advocate. It's that network effect. We were also of course mindful that the over justification effect where too many rewards can decrease motivation. So our rewards are layered. Tangible perks, yes, of course.

But also status, visibility, and social proof. Because when your contributions are recognized publicly, of course, not just privately, it builds trust. Because in early stage ecosystems like Midnight, trust is everything. And when gamification is used intentionally, it can be more than honestly a growth hack. I I would assert that it can become a trust engine.

We've been, we've seen developers shift from lurkers to leaders. Not because we've asked them to, but because the system gave them reasons to act. It can turn participation into contribution, and then contribution into leadership. So the question then is what happens when you don't design it that way? Because the truth is most DevRel programs are built all with good intentions.

We all Absolutely. But they often operate in fragments. You've got your learning portal on one side, your hackathon strategy on another, your open source repos are maintained by a different team than the folks that are running the ambassador tracks, or your speaking programs. And then when someone actually contributes something meaningful, there's often no simple way to connect that action to a broader recognition. Unless you want to open a contract, loop in legal, wait for procurement to create a vendor record, and then cross your fingers that all of this gets approved by the finance team before the quarter ends.

All just to thank someone for fixing a typo. I've worked at a whole bunch of companies where we've had tutorials, the badge systems, the speaker tracks, the swag ladders, the contributor shout outs, and hackathons, and open source contributors. Each of them, all of them worked, but they were all siloed. None of it connected and that's what I would say is the problem. Because here's what happens.

Say someone joins your hackathon. They submit a great project. They let's say they win. Oh my gosh. But then what?

Too often that energy disappears. It doesn't unlock anything for them. No recognition. No follow-up. No next steps.

It's as if they hit a high score in an arcade game. Cool. They got some tickets, but then they walk away and no one remembers their name. Their work doesn't get surfaced in other parts of your community. It doesn't carry forward into how your team sees them or how the community recognizes them.

It's a moment of value with no momentum. Or say someone contributes to your open source project and fixes a nasty bug. But unless a PM or maybe an engineer happens to notice and escalate it, that effort disappears. It's invisible labor. Or think about your champions program.

Most of them rely on applications and self reporting. You're asking people to say, hi, look at me. Here's why I'm awesome. But what if you could see the real impact measured over time across channels based on what they've actually done. So the problem isn't that these systems exist as I've said.

The problem is that they don't reinforce each other. There's no connective tissue. No memory. And without that, every program is a reset. Every touch point is isolated.

Every community member has to reprove themselves again and again and again. And that's not scalable. And it definitely is not how you build trust. So when we were started building out DevRel at midnight, we asked, what if everything talked to each other? What if learning, the building, the contributing, the leading weren't separate tracks, but instead a part of one cohesive journey?

For quick context, Midnight is a data protection blockchain. We are building tools that help developers create applications where sensitive information stays private by default so that you can imagine the kind of developers we're trying to go after, you know, they're technical, they're security conscious, they're deeply thoughtful about what they're building and that part is why we took such an intentional approach to our DevRel stack. So our program isn't just about onboarding. It's about identifying those real builders who absolutely are willing to navigate this privacy, zero knowledge and complex architecture space and then giving them the tools and recognition to become leaders within our space. And so that got us thinking.

What if the education, the contribution, and leadership weren't separate tracks, but a part of a single connected journey. A journey where every action moves you forward, every contribution earns you trust, and then every builder helps bring in the next one. A network effect almost. And that's the idea that we came up with for Midnight Quest. And now I know, I know, I know, I know I was wildly unoriginal in my naming.

There is no need to remind me of that. We're moving on. Okay. MQ. Abbreviated.

It's short. It's different. It's a gamified system that tracks real developer activity and it ties progression, recognition, and opportunity all to one another. Here's how it works step by step. So it starts with our developer academy, our education program, and you don't just watch the videos, you know, and call it done.

To complete the Academy, you have to submit a project to whatever virtual hackathon is running at at the time. And that means that from the start, you're building something real, not just learning in theory, building an actual application. Once you ship, you earn your academy certificate, and then that goes beyond consumption and aims to be about creation. So that project submission also earns you a whole bunch of lunar points is what we call them in the Midnight Quest portal. And of course, those points though aren't arbitrary because they also then track how your developer progression is going across the whole ecosystem.

And there are visible representation almost of your impact, if you will. So Midnight Quest tracks all kinds of contributions. We're doing deploying contracts, contributing to open source, helping in Discord, participating in hackathons, submitting feedback, triaging issues, and even hosting events. So it's automated. It's consistent.

And it creates a simple profile of how someone is contributing. And it's not just once, but over time. It's your developer resume built by your actions. Right? So based on that m q level that you have, you then might get tipped for helpful posts, receive swag, earn token rewards, or even unlock special access.

Because we can track on chain activity via their wallet, which is also their login to the program, we can reward contributors automatically based on what they've actually done. That means when they submit an application, fix a bug, or complete a quest, we don't need to open a contract or file an invoice. The reward is already tied to that action and it's executed by the protocol. It's you know very simple. You helped.

You earned it. You got it baby. You That's the power of designing recognition as a part of the infrastructure and not as an afterthought. So Midnight Quest also helps us identify who's ready for more responsibility. Right?

That top tier within the m q leader board, those are the people that we can trust to host the meet ups, to go give the workshops, represent us out in the wild publicly. And that's not just a nice to have. You know, it really really matters because when you're when the tech is in that very early stage, every single interaction that you have is a first impression. If an ambassador is out at a local meet up and gives a talk full of technical errors, that's gonna be the first and most likely last time the folks in the audience ever engage with our tech. So MQ helps us vet people.

It it's give, it shows us that someone has consistently shipped solid projects. They've participated in hackathons. They've helped others. They've contributed to repos. We don't need to guess.

We know that you understand the protocol. So that's how we can confidently give someone the mic. We're not just guessing. I'd say we're knowing. The best part, it all connects.

So before a hackathon, as I said, you complete your developer onboarding quest which is a series of tax tasks to set you up your I'm sorry. It sets up your environment like kind of a series of tasks that kind of go in order of what you need to do to get started before you're ready to build. You graduate from the academy by submitting an application to a hackathon. The application earns you a bunch of points, and then the more points that you have, that equates to higher tiers within our ambassador program, which then qualifies you to host a technical workshop and event, and then the event of course brings in the next wave of learners. Those of you that were in the flywheel session yesterday, I'm very proud of this flywheel.

I think there's more to iterate on it, but like it does feel like it's it's doing the thing. So everything feeds into the next step. There's no dead end. There's no silo. Just a continuous developer journey.

The flywheel of engagement where every action builds momentum for the next. Now, almost all of you in here are probably thinking like Lauren, I don't work for a freaking blockchain company. I can't send crypto rewards. Like, I already have a champion program. That's totally fine.

A 100%. Here's the truth. You don't need a blockchain to build smarter systems. You just need better feedback loops. Everything that we've done with Midnight Quest, honestly, you know, the tracking, the contribution, surfacing reputation, rewarding people quickly, you can adapt those same principles to your world right now.

Here's a few places to start. Instead of running a hackathon over here and an education program over there, design them to feed into one another. Make shipping something real a part of your learning path. Reward hackathon participants with speaking opportunities or contributor status. Let one activity unlock the next.

Think of them, you know, we always say that DevRel is the bridge between the company and your community. Think of this as building bridges between all of your programs as well. Set up simple scripts to track your GitHub activity, your Discord participation, doc contributions. Tag your contributors automatically in your newsletter. Reward people fast even if it's just with yes, maybe a badge or a DM or a social shout out.

The faster you give recognition, we know that's the stronger moment of reinforcement. Even without access to their wallets and their on chain developer activity, you absolutely can build contributor profiles. Use GitHub, Discord, community forum data. Use that to surface your most engaged builders, not just those who are the loudest or the people who apply to everything. This helps you identify your true community leaders.

And of course swag is great, but so are speaking slots. You know, what if your rewards included access to your team, early previews of your roadmap, or a chance to co author a tutorial. Make the rewards align with growth, not just stuff. Think about what truly empowers a developer. The goal isn't to gamify everything.

It's to design systems where each contribution builds on the last. Where the more someone shows up, the more trusted and empowered they become. We're building long term relationships, not just chasing short term metrics. Okay. And even if you're like a teeny teeny tiny bit curious about dipping your toes into the blockchain space, even the tiniest bit, the there is a great option in using stable coin like USDT to send rewards because it could give you that immediate gratification.

The real time, we see you, we appreciate you feeling without requiring you to dive head first into, you know, on chain infrastructure. Infrastructure. Because there's no contracts, no invoicing delays, no vendor onboarding, just you contributed, we love that, you got rewarded baby. Like that is the magic. Developers are just like my baby.

This time my daughter, Louie, taking her first steps. They don't need to be bribed. They just need the space, the encouragement, the recognition to keep moving forward. I love that she claps for herself. Like, she's so happy.

You don't need badges. You need memory. Frankly, you don't even need points, just progression. And you don't need to tokenize everything, you just need to show your developers that their contributions matter and that they're building towards something real. To begin wrapping up today, my assertion essentially is that gamification is no longer just about the bells and whistles.

It's not about the points or the pixels or nostalgia. It's about building systems that actually remember what your developers do. Systems that compound trust. That give people a reason to keep showing up and to keep building. To keep growing with you.

And when you connect those systems, when education leads to contribution and contribution leads to leadership, that's when your developer engagement becomes maybe developer momentum. And that's the shift that we're taking at midnight. We're not just rewarding the activity, but elevating people through contribution. Creating a journey where action moves someone forward and where that community itself becomes the engine of growth. You can start small.

You can absolutely stay webbed too. Totally get that. This is I I work in a very niche space. I acknowledge it. But think about the pieces that you can, you already have.

Let's ask Ben, how can I connect them better? How can I track them more meaningfully? How can I reward them more responsibly? Because gamification isn't just a tactic anymore, it's a strategy. It's infrastructure.

And when you design for progression, reputation and trust, you don't just grow a developer community, you grow a movement. So if there's one thing I would like you to carry out of the room today, it's this. The future of DevRel isn't about chasing fleeting engagement metrics. It's about building enduring relationships, forging genuine trust, and empowering developers to become true co creators. When you connect your systems, when you automate recognition, and when you design for reputation and progression, you're not just running programs.

You're cultivating a vibrant ecosystem where every contribution matters, every builder is seen, and where collective momentum creates something far greater than any individual effort. Because ultimately, in this incredible journey of technology, it's not about the badges you give, but the builders that you empower. It's about the movement you ignite. Thank you. A big p s is that if any of this DevRel strategy sounds somewhat interesting and you know, compelling to you, my team is hiring.

We're building a community from scratch. We're very early. We're leveraging all of the lessons that our team has learned from prior DevRel teams and building upon them. The tech is cutting edge. It is exciting to build with.

It is so fun. We're a remote first company and I my whole team is here, so don't just take my word for it. Go speak with them and yeah. Feel free to chat with me with them if you're interested in learning more. I would love to speak with all of you.

Thank you. Thank you very much Lauren. Thank you.