Your community isn't built from events (you've got cause and effect backwards)

This post is part of a series on building developer relations, adapted from a book chapter I wrote. You can find all the posts once published in the series here.

I grew up in the eighties with a home computer and parents who would happily have told you "our kids grow up with all this stuff, it's native to them." "This stuff" meant anything with a plug - the video recorder, the answering machine - but I didn't care about any of that. Everything programmable was mine to conquer. When my father finally gave in and spent what was, for him, half a month's salary on a Sinclair ZX81, I had arrived in nerd heaven.

I wanted to tinker, solve puzzles, control technology, and above all learn new things. But there's a hard limit to how much you can learn alone. There was no YouTube, barely any written tutorials, and only a handful of kids at school who cared about the same things. So we started a little hacker club. That club later became the core of a developer group that's still active in my old hometown, decades later.

That club is where I got my community socialization. We'd meet, build projects together, sometimes just hang out, and now and then help each other crack a puzzle. And that experience - that exact experience - is what drives literally every developer community out there. It starts with fascination, grows into an appetite for knowledge, and the final ingredient is always the same: the fun of solving problems together and the joy of shared learning.

Now here's where a lot of well-meaning organizations go wrong.

Active communities tend to run a lot of events. So people look at that and conclude: if I just run enough events with developers in the audience, I'll end up with an active community. It sounds obvious. It's also exactly backwards. You're confusing cause and effect. Events can lead to community, sure - but more often than not, the "community" you built this way dries up the moment your organization stops paying for the events.

This is the cleanest line I know between developer marketing and developer relations. Developer marketing creates a channel and pushes information down it, hoping to trigger action in a defined audience. That's a perfectly legitimate thing to do. But developer relations is about creating and growing social groups and their relationship with your business. I've made that argument at more length elsewhere: the whole thing only works when you start from what is good for them. And those groups are not bound by the events they happen to show up at. They're bound by a shared interest and a shared passion.

And here's the part that surprises people: in most cases that passion is not the technology. The passion almost every developer community actually shares is a passion for learning and teaching.

People who love learning new things in company, and love helping each other, cluster together and form relationships. Those relationships are the community. And communities built on relationships are dramatically more scalable - and have a far better return on investment - than groups temporarily glued together by an event series.

Why? Because nobody has to be prompted. People show up with things they built, they answer each other's questions before you've even seen the question, and after a while the group has enough gravity to pull newcomers in on its own. A calendar of events grows in a straight line, one audience at a time. Relationships don't.

So if you're standing up a community program, resist the urge to measure your progress in events on the calendar. Ask a different question: are people here because of what you're paying for, or because of each other? The second one is the only kind that survives your budget review.