Live data from Hacker News

A tactical guide to kickstarting a community

orbit.love

11–20 of 26 posts

Re: A tactical guide to kickstarting a community

#12
post #11

Author of the post here. Happy to answer any questions!

Nice article! You mention doing more events earlier, is there anything else you’d do differently?

Thanks! We definitely could've started with events sooner, IMO. The simple practice of getting folks together to meet and talk shop contributed to the sense of momentum overall and the interpersonal connections in particular.

I should note that all the events we've done to date have been small, and focused on our existing community. I think such focus made sense for us in year one, since we were building the community and the product at the same time. In other words, we didn't have the capacity to produce a broadly-focused event.

That said, the intimate vibe in the early days goes a long way toward engendering a sense of ownership and belonging among community members. I honestly think it's more meaningful to do smaller insider events more frequently in the early days, versus casting a brand net and potentially diluting the group’s nascent identity and culture norms.

Now that we're scaling up, I anticipate increasing the reach of our events as well. But that’s okay, as we have the team to support it on one hand, and on the other, the culture of the community is already well-defined.

Re: A tactical guide to kickstarting a community

#15

I stopped reading at “ some of the best minds in DevRel” Jesus fucking Christ, not everything is a “DevOps” wording clone. Edit: Finished the article, good insights. However can we stop the Dev_ and _Ops BS? Please and thank you.

The term "developer relations" goes back to the mid-90s at least. I find it hard to believe that nobody shortened it to "DevRel" in the 15 years before the term "DevOps" came to be.

Re: A tactical guide to kickstarting a community

#16
To some extent, this is a chicken and egg problem -- how to get enough people to join so that other people will join -- and one way they solved it kind of falls under "backwards compatibility." They started on Slack in part because their audience was already on Slack all day, every day.

Second, they started with just two channels. Not only did this concentrate traffic, it reduced cognitive load on new members trying to figure out where to say a thing and worrying if they were in the right channel.

One good way to outright kill conversations is to have lots of low traffic channels and then fuss at people for discussing a thing "in the wrong channel" because that's where conversation happened to break out and insisting they move their discussion "to the appropriate channel" when there is no actual compelling reason for it. (There can be compelling reasons to ask people to do things a particular way, such as privacy, information security or age segregation protecting young people from explicit content. But those rarely are the reason this gets asked.)

before we created the channel, folks would share their creations with me directly via DM. That was amazing, but this approach didn’t help others in the community, since the conversation was 1:1 in private.

After that happened a few times, I proposed a new channel:

This makes me wonder what preceded that.

Why were people sending him direct messages? Were they only sending them to him or were other team members getting similar messages? If they were only direct messaging him, why is that? What was he doing that fostered that?

In my experience, creating a sense of psychological safety is key to facilitating many-to-many conversations.

One great way to do that is to help members feel like they know who’s on the other side of those usernames in Slack, and that those people are generally nice.

A thing you have more control over: Setting the example of how to effectively interact in a way that fosters safety for everyone.

This was likely done without realizing it. If you know how to have a successful career, you likely know how to relate to the public. If you are writing a guide to kickstarting a community, you likely know a lot about relating to the public effectively.

That involves a lot of baked in assumptions and best practices that you may no longer consciously think too much about. The community then looks to you to set the example for how to do this dance.

Ahead of the call, we sent registrants a $25 gift card to a food delivery app as a way to share the celebration with the community — a virtual “snacks on us,” if you will.

This is brilliant because it connects the real world and virtual world so effectively. You have a real world impact on people you connect with online and a lot of people seem to think this isn't true. A lot of people seem to think the two things are more separate than they are.

This is a brilliant example of how you can send digital goods -- gift cards -- with real world impact -- ordering food to be delivered. Though even just talking with people online is a real experience with real world impact.

Re: A tactical guide to kickstarting a community

#17
post #15

I stopped reading at “ some of the best minds in DevRel” Jesus fucking Christ, not everything is a “DevOps” wording clone. Edit: Finished the article, good insights. However can we stop the Dev_ and _Ops BS? Please and thank you.

The term "developer relations" goes back to the mid-90s at least. I find it hard to believe that nobody shortened it to "DevRel" in the 15 years before the term "DevOps" came to be.

You finding it hard to believe is irrelevant. Nobody was calling stuff Dev_ before DevOps

Re: A tactical guide to kickstarting a community

#19
post #15

Earlier quoted context omitted.

The term "developer relations" goes back to the mid-90s at least. I find it hard to believe that nobody shortened it to "DevRel" in the 15 years before the term "DevOps" came to be.

You finding it hard to believe is irrelevant. Nobody was calling stuff Dev_ before DevOps

it’s better to not talk in absolutes, we all share experiences (data points). Be kind.

Re: A tactical guide to kickstarting a community

#20

Author of the post here. Happy to answer any questions!

I run a tech community on discord and I'm having a really hard time keeping it alive and well. We've been active for about 5 years and it's hard to keep a tight group of regulars around. Most people seem to come and go, a lot of them only interested in getting their issue solved. People who are interested in being part of a community, chatting with other people etc, don't seem to find what they're looking for and end up leaving. I have about a full renewal of the regulars every year or so where the old regulars become inactive and new people emerge but I can't seem to build a cohesive core of people and build a community culture around them beside the moderators. Have you managed this? How do you deal with retention and culture?
Post reply on HN