What in-person conferences offer: feedback

I was listening to a Twitter space recently and the host had an interesting take: for the amount of money you would spend flying a speaker to an international conference (call it $5000, though of course the actual number varies depending on location, timing and more), you could record a great educational video and get it in front of many folks on Youtube.

Assume you spend $3000 on video production, and the CPM is $4 (hard to find solid numbers, but this post talks about rates in that range), you could put that video in front of half of a million people (1000 views/$4 * $2000). That’s a big number, certainly more than attend any conference.

As someone who is gingerly stepping back into work conference travel, who doesn’t like to spend time away from his home, who is a member of the flyless community, and who came into devrel in earnest during the pandemic, I’m sympathetic to that view point. It is more efficient to broadcast your message wholesale, whether that is with a blog post, webinar, or a video, than it is to talk to people retail at a conference booth, or even to give a talk to a hundred people.

But what I’ve learned is that there are real benefits to in-person conferences too: attention, prestige and feedback.

Attention

Think back to the last video you watched, especially if it was technical. How much of your attention did you give it? Perhaps 100% if following a tutorial. But perhaps substantially less if it was background noise or you were looking to learn a bit on the subject.

I’ve definitely “attended” online conferences where I was not paying attention. And I have never popped into a virtual conference “booth”, so I have no idea if the content there is compelling.

I’ve also seen folks at in-person talks on their phones or computers, to be sure, but it is not the rule.

Data is hard to come by, but I believe that folks that are more likely to pay attention at an in-person event. They have made more effort, so they are more committed (research finds “working hard can also make [things] more valuable”). There’s also more distance from the normal work task during an in-person conference. Attendees have far fewer distractions, and an expectation of attention. I think that focusing your attention on a speaker at a talk you are attending is the polite thing to do as well, and there are social norms pressuring folks to do that.

This attention makes an attendee at an in-person conference more valuable than a Youtube viewer.

Prestige

While not anyone can create a great video, anyone with a camera can make a video.

On the other hand, not everyone can buy a booth at a conference, attend one, or speak. There is a filter on everyone who is at an in-person conference. This filter disadvantages folks who can’t travel, have a disability, or have other constraints. But it improves the value of an interaction at a conference too.

Being able to pay for a booth or have a talk accepted in particular are signals of quality. They don’t equate with quality, as anyone who has sat through a vendorware conference presentation can attest, but there is some level of prestige that accrues to an organization by being at a conference. That’s one of the reasons companies pay to sponsor conferences; there’s value in being seen there. (Others might phrase it differently.)

Feedback

Feedback is the last, and in my mind, most valuable differentiator between in-person conferences and online educational activities.

At a conference, the opportunity for two way communication abounds!

Any time someone stops by a booth or asks a question after a talk, as an educator you have the opportunity to not just answer a question or address a comment, but to dig in and understand the person’s context. What do they do? Why are they asking that particular question? Is there an unstated assumption in their question?

You can and often do have ten minute conversations at a booth, and this qualitative, high bandwidth feedback from expensive software development professionals is valuable in learning about your market and seeing if your message resonates.

Contrast that with the limited q&a at an online conference or the comments on a video. Yes, that is also feedback, but it is far less nuanced, considered, and interactive.

Conclusion

The ready availability of high quality, intense feedback driven by back and forth communication is the killer feature of in-person conferences. I don’t see any way to replicate that right now online.


Collecting internet points

I’ve been pretty active on HackerNews for the last couple of years and recently made it into the top 100 posters. According to this stats page, in just over 10 years as a member, I’ve posted 3468 comments and had 7824 submissions. That is approximately 1 comment and 2 posts per day, for a decade. (The numbers are as of the time I write this post.)

That’s a lot of hours on a site.

In light of that effort, I’d like to reflect on the good, the bad and the ugly of my years on HN, collecting karma points.

The good:

  • It’s elevated worthwhile posts and sites. I don’t know a single better source of free traffic for technical content. You don’t just get the initial traffic; other sites, online communities and newsletters pick up top ranked HN posts and reshare them, so there’s an echo effect as well that lasts for weeks. It is really fun to find a good article, post it and surprise the author.
  • I’ve learned a lot by reading the comments, especially in fields outside of software engineering. Posts on topics such as economics, physics and careers all receive really insightful comments.
  • I’ve been able to help a few folks get jobs by posting on HN. They have a monthly free jobs board and I know at least two people who have been hired because of one of my posts on the jobs board.
  • While trending on HN doesn’t typically translate directly to sales, it is great for brand awareness. At my current job, quite a few sales processes have been started because an engineer read a post about FusionAuth on HN.
  • For a developer relations position, having an active presence on HN is helpful. You can certainly devrel without being on HN, just like you can devrel without being on Twitter. But in general a public profile is helpful.

The bad:

  • While most folks argue and discuss from a place of goodwill, there are some who are overly pedantic and or just not nice. I can ignore them, but I remember a few flushes of shame where I made a mistake in a comment and was called out on it in an unkind, direct manner.
  • Self-promotion is part and parcel of a community where there’s this much traffic (to be transparent I promote my own stuff, but only 1 out of 10 posts at most). Often, I’ve seen over the top self-promotion. If someone only posts their own content, it simply doesn’t work.

The ugly:

  • HN has its share of trolls. I have personally seen fewer ugly posts recently, but any time I mention HN, folks reflect on the ugly, mean comments they’ve encountered on the site. Here’s an example of some people’s feelings.
  • I’ve had people ask me not to post their content without warning them. This is because of the kind of feedback they get from the site; they want to mentally prepare. That they’d even feel the need to do that is icky.

I think finding a community or three is a key part of growing as a developer.

While HN is not perfect nor it is as welcoming as other communities like the one around the Ruby language, the breadth and volume and diversity of it has been helpful to me.

So, I plan to keep collecting internet points for the coming years.


Thoughts on managing a devtools forum

I’m one of the team members tasked with managing the FusionAuth community forum, where folks using FusionAuth who don’t have a paid support plan can find help and answers.

Here’s some advice for running such a forum. (I wrote previously about why you should use a forum rather than Slack/Discord/live chat.)
  • First, consider why are you going to run a forum? Lots of great reasons: ease a support burden, help with SEO, foster community, get product feedback. Get clear on what you are trying to build before committing, because it is a commitment.
  • Choose forum software carefully. Migration will be a pain. Common options include nodebb (what we use), discourse, and vanilla forums.
  • Seed the forum. This means gathering up questions as you see them pop up in other venues (support tickets, GitHub issues, customer calls). I did that religiously for a few months. I learned a lot about the product and the forum posts meant that folks were helped even when it was new. I’d recommend posting the question and then responding in-thread with an answer.
  • Forums will bubble up commonly asked questions. This can tell you where your docs should be improved.
  • You must groom the forum. It won’t be set and forget. You have to pay attention to it, answer questions, respond to responses. A forum full of unanswered questions is worse than no forum at all. Trust me, developers will notice (we’ve had customers mention that they appreciated how active our forum was).
  • Because we sell support, we don’t answer questions immediately or have engineering staff answer them. There are also questions that we can’t answer such as architecture recommendations. Immediate responses and answers requiring context and research are reserved for paying customers. This hurts my heart some times, but we are open about it. May not be applicable to in all cases.
  • Don’t be afraid to ban users. We ban anyone who spams, no questions asked. Delete the content and ban the user. We luckily haven’t had any abuse issues beyond spam.
  • Have a code of conduct. I grabbed GitHub’s (you can see ours here, and here’s GitHub’s)  but have something. We didn’t in the early days, but it’s a good thing to have out of the gate.
  • Don’t expect a lot of community to grow out of it. At least, I haven’t had that experience, most people just want their questions answered. May be because I’m extremely part time on it and haven’t fostered it, though. Slack/discord is much more likely to build community in my experience. But know what your users want: Google or Facebook?
  • At a certain point, I had to enable a post queue, where a team member approves every new user. We were getting a lot of spam accounts and then they’d post gambling ads and then direct a ton of traffic (1000s of pageviews) to the ads. I don’t know what the spammer endgame was, but approving each new post has solved the issue. I’d definitely look for that feature.
In general I love forums, and so do devs, but they do take some work.

Options for scaling written content as a devrel team

If you are in developer relations, creating content is often a big part of your job. Written content is one of type of content, and a common one at that.

Written content scales well, is easily updated, can be consumed on readers’ schedules, is fairly accessible, and can be reused. It also can serve as a foundation for other kinds of content, such as talks, example apps, or videos.

At FusionAuth, I’m part of a team that creates a lot of written content. I wanted to talk about a couple of ways you can scale written content creation. Note this focuses on creating more content, but don’t forget to write the right content, which is more important than sheer volume. (That’s a whole other blog post, though I feel a bit like Fermat even mentioning it.) This post also assumes you can’t hire more in-house talent, either because of budget or because finding good devrel folks is really hard right now.

Re-use

First up, re-use your content. You can take pieces and use them in different ways. For instance, write a great piece of long form content. Then, pick a few of the most interesting paragraphs or sentences, and share those in Twitter or on other social media. You can also use these excerpts as fodder for comments on online communities or forums, if they answer a question someone else is asking.

Finally, you can also combine articles. For instance, I lightly edited a number of articles, wrote a few pieces of original topical content, and ended up with an ebook about outsourcing your auth which has been useful to share with readers and possible FusionAuth prospects. The effort was far far less than if I’d set out to write a full book on the same subject.

The next two options require increasing amounts of money, so if you only have your time to spend, focus on this option.

Find freelancers

The next option is to find freelancers or community members who are willing to write articles. At FusionAuth, we paid money for these posts, which is typical. Our rates were between $0.25 and $0.50 per word, typically including an example app that we would host in our GitHub organization and open source.

Thee downsides of freelancers are:

  • it is hard to find good ones. I did find a couple who delivered multiple good posts, but they are few and far between.
  • you have to manage them and their delivery. This can include extensive editing depending on skill level.
  • you have to give them an outline. While I tried to get folks to ‘pitch me’ with interesting ideas, that didn’t turn up much at all.
  • they are not going to know your product or space as well as you do.

If you are larger, you might be able to pay less because it’ll be more of a plum for authors being published and associated with you, but you should pay something. Developers know the value of good content.

You may also highlight articles written by someone on their own blog, but that isn’t your content and You won’t be able to re-purpose it. You could, I suppose, reach out and see if the authors would be okay with you licensing it. Haven’t done that myself; I prefer to keep it simpler and share whatever someone writes about FusionAuth.

Content agency

The final option is to hire a content agency. The active ones that I know of are draft.dev (disclosure, FusionAuth is a current client), Ritza, and Hit Subscribe. (I am sure there are others.) These agencies have different strengths and approaches, but they all take some of the management burden off of you. Often you can come to them with just an idea and they’ll build out a content brief (an outline), find someone to write it, and do an technical editing pass before delivering it to you.

These are great if you want technical content frequently. It is also fantastic if you want posts written about technologies that aren’t in your wheelhouse.

For example, Joomla is used across 1.7% of all sites on the internet and we wanted an article about SSO and Joomla. I didn’t want to come up to speed on the. So draft.dev found a Joomla expert who was willing to write an article for us about SSO and Joomla. If not for them, I doubt that post would ever have seen the light of day.

The downsides of these agencies include:

  • you have less control over the freelancer selected.
  • they will not know your product or space as well as you do.
  • you’ll still have to do some quality control and checking. You can’t outsource this entirely, because of the above point.
  • it’ll cost more money. You can expect to spend between $1000 and $3000 for a post (at the time I write this).

These are options that I know of that let you scale up your written content creation.


Do you want to build a community where users search or hang?

Everyone wants to build community, especially developer focused companies.

A community helps your customers and users succeed, creates content that your team doesn’t have the time to do, and builds a competitive moat.

But what type of community are you building, or looking to build? Every community is different. Which should be no surprise.

After all, offline communities aren’t identical. Neighbors are one type of offline community characterized by certain expectations and interactions. Maybe you watch their dog, wave when you see them, and get their mail for them on vacation.

Friends and family are another. You invite them for parties and see them during the holidays, discuss politics, and stay in touch through the years. Depending on family bonds, you might even lend them money or donate a kidney.

Similarly, developer communities have different levels of engagement and commitment. These can serve different audiences and needs.

A community is not a community is not a community.

One easy way to think about the community is to ask the question: are you a “Facebook” or a “Google”?

No, I’m not talking about whether you should “move fast and break democracy” or “don’t be evil” and set up a panopticon.

What I mean is: “what does your typical user want to do: hang out or get a question answered and move on?”

Facebook is where people go to hang out. It’s the dominant social media site, even if the kids are moving on to something else these days. In this type of community people chat, hang out, and get to know each other better. The technology or software solution is often the original impetus and the source of much discussion, but there are other aspects to the community. Topics range widely. In some cases, people remain members through job and role changes.

The community may even have a real life component, such as a conference or members meeting up if they are in the same area.

In contrast, Google (the search engine) is where people go to get answers. This involves searching, then leaving Google as quickly as possible. Community on Google is tenuous. It really means “people there at the same time” or perhaps “people asking the same questions”. Anonymity is fine and even valued.

The point of search engines is to send people on their way as fast as possible so they can focus on solving the problem that they are faced with. When you are looking up an error string, you don’t want to chat with someone about their hobbies, you want to get your answer and go fix the bug.

This is also a crucial, often ignored, purpose of a developer community.

What are some examples of these two types of community?

Examples of developer communities that are “Facebooks”:

  • The Rands Engineering Slack
  • The Ruby community
  • Orbit.love’s discord

Examples which are “Googles”:

  • StackOverflow (for almost all participants)
  • The Elasticsearch forum
  • Almost any other forum, for that matter

What makes a community more likely to be a Facebook or a Google?

There are many reasons why a community might tend toward a hangout or a search engine. Consider:

  • How self contained is the technology? Components or tools snapped into an existing system, such as a security framework or logging library, are more likely to be a Google-type community. Frameworks and other solutions that are bigger and more self contained lend themselves to a Facebook approach. Few folks want to hang out and discuss the intricate details of logging, but a bigger project like Haskell or Rust will have more to discuss.
  • Are there events that happen in real life around the community, such as conferences? These are likely to make the community more of a “Facebook”. There’s a feedback loop; when I meet someone in real life, I want to hang out more with them online.
  • Is the community open source? Does it have a unifying philosophy? Or is there a strong common interest such as gaming? These all make a community more likely to be a Facebook, since there’s already more to discuss than simply problem solving.
  • How do members interact with the software supporting the community? If often, there’s incentive to invest in getting to know other members. If, instead, the tool is used once in a while, then there’s less incentive. This correlates to the tool vs framework point above.
  • How big is the community? The smaller the pool of members, the more likely any interaction will be personal, and hence similar to Facebook. This is especially true if combined with a philosophy, as mentioned above.
  • How long has the community been around? Longer lived communities have, by definition, more chances for members to interact.

All other things being equal, a community where people want to stick around and chat is more valuable. It’s also harder to build, and may be impossible. And it’s only part of the picture. People hear the word “developer community” and think of IRC or discords where developers hang out, but community is so much bigger than that.

What are the ramifications of this characterization?

As a community builder, when you are starting out, you are likely building a “Google” type of community. To help it succeed, provide the most help you can in the time you have.

Help builds trust. It shows you care about your community and their success. Offering help shows you value your users time and is foundational for any other type of community endeavor. Few community members will volunteer time to help answer questions on your forum/chat if the company doesn’t seem to care enough to provide good docs about the tool or software solution.

So, your job is to help developers using your software get the answers as quickly as they can. How?

  • Well structured documentation. If possible, allow users to suggest changes to it.
  • Publicly searchable question and answer archives. I like forums, myself.
  • A clear roadmap for the product. Yes, it’ll change, sometimes rapidly, but offer as much guidance as you can.
  • Multiple channels for community feedback. GitHub, StackOverflow, hosted forum, Twitter, email, Slack, Discord, conferences. Pick some to focus on, but support as much as you can. There are plenty of tools to consolidate these disparate sources.
  • Share the changes the community has suggested that are implemented. This can be as simple as a shout out in release notes.

You can help work towards a deeper community by helping members get to know one another. This can be done in a variety of ways, including:

  • Virtual or in-person meetups
  • Profiles of community members
  • Encouraging direct communication between members, if you see people with similar interests or problems
  • Synchronous chat platforms like slack or discord

Just like it takes time for a sports team or company department to gel, it will take time for a community to do so. In fact, it will take more time, since members spend less time in your developer community than they do in others. Prepare for a long journey with missteps along the way.

Why not both?

Of course, a community can be good for hanging out and getting answers. Different users can have varying expectations and experiences within a single community.

Stackoverflow is a good example. Most people arrive there via search engines, ask or answer a question, and then leave. But there is also a lively community, meta.stackexchange.com, where users get to know each other, hang out and argue over the rules and culture of the Stack sites. It is important to design and be aware of these different needs, including lurkers.

But, in general, most communities have a clear tilt toward one mode or the other. Either you are a watering hole where folks hang out or an encyclopedia where developers come for answers. When you are helping foster a community, you’ll want to have a clear understanding of which type of community you can realistically achieve.

Thanks to Rosie Sherry for her review of this post.


Online community power outside of devrel

I’ve been working in devrel for while and one of the key components is community–you want to support the developer community around your product or the larger ecosystem. I witnessed this same focus work outside of the developer community and still feel an online curated community is an under appreciated asset. Like all assets, you have to work to attain it, but then after you have it, it pays dividends.

The setting: a little startup in a decidedly nontechnical niche. I’m not going to be too specific because of agreements I made with the company after I left. They did the following:

  • Built up deep expertise in the field before they even started the community. This can’t be rushed, but if you spend a year or two focusing, that’s a a good start. (They’d spent 5 or 10, which is of course better.) This is a critical step that can’t be short cut. If you don’t have this, you’ll have a more difficult time with everything, because you won’t have foundational knowledge about the community for which you are trying to build an online presence.
  • Started an invite only Facebook group. The actual group software matters less than going to where people are. In this case, the target market already hung out on Facebook.
  • Invited people to the group. Not just clients, but anyone who was affiliated with the community.
  • Had a clear code of conduct, especially in relation to commercial activities (aka spam). Discussion of business related issues was encouraged, but unrelated commercial links were removed.
  • Seeded discussions with questions heard elsewhere. Answers were highlighted in blog posts and newsletters as well as shared with the group.
  • Spent time encouraging group members to share their experiences.
  • Promoted the online community to other offline communities with similar interests.

In time (years!, not months), this Facebook group became extremely valuable to the company, in a number of ways:

  • The questions people were asking in the forum could be turned into blog posts, which were helpful for SEO. That is, the company learned from the forum what kinds of questions people the company wanted to target were asking. (Ask if you can do this before you publish what community members may consider to be private! Just ask, sometimes people want their wisdom shared.)
  • The company could see if members were looking for the solution the company was selling. They could then reach out outside of the group and do a gentle ask. Member demand for services could be monitored over time, as group members shifted employers and/or situations.
  • When talking to prospective customers who were not in the group, a membership was an easy, free offer of value. The answers in the group provided insight and many prospects were happy to join, even if they didn’t want to purchase anything from the company.
  • People found the online community and then learned about the company supporting the community. A definite halo effect.
  • If the company has a new offering, they can do market research easily. They know where to find their target customer.

This onlinecommunity definitely isn’t free, even if you use a solution like Facebook groups with no hosting costs. (Facebook groups is not the best option, in my opinion, in terms of long term flexibility, because Facebook owns the user and you don’t have access to information like their email. But at the same time you have to go where the prospective members of your online community are, and anything you can do to reduce friction is crucial.) Moderation and content seeding are also crucial to getting the online community going.

But now that the community is up and running, it is a sustainable moat.

If you run an non-technical business, do you have an online community that you participate in? Do you know of one? If you don’t and can’t find one with a little bit of googling, think about setting one up. It can be a long term sustainable advantage for your business. Like any other assets, you have to invest, but it’ll pay dividends.


You should use forums rather than Slack/Discord to support developer community

Hot take after a year or so of trying to build a developer community. If you can pick only one, use forum software rather than synchronous chat software for community building around a developer platform.

While there are tradeoffs in terms of convenience and closeness, for most developer communities a public, managed forum is better than a private, unsearchable Slack.

There are a few key differences between forum software (which includes packages like nodebb, forem, discourse, and others) and chat software (like Slack, Facebook groups, or Discord).

First, though, it’s important to know what you are trying to accomplish. If you are trying to get immediate feedback from a small set of users, then synchronous solutions are better. You can be super responsive, your users will feel loved, and you’ll get feedback quickly. However, synchronous solutions go beyond chat and include phone and video calls. The general goal of validating user feedback at an early stage is beyond the scope of this post.

But as you scale with a chat solution, major problems for the longevity and value of the community emerge.

Problem #1: the memory hole

This occurs when there’s a great answer to a common question, but it isn’t available or is hard to find. This matters more for community Slacks than other synchronous solutions, since Slack limits free plans to 10,000 messages.

It still exists for solutions such as discord because older messages scroll up. Search isn’t great. As a participant it feels easier to just re-ask the question. If the community is vibrant and willing to help newcomers, such questions get answered. If not, they languish or are ignored, frustrating the new participants. Not good.

You can work around the memory hole as a community member by extracting and reifying interesting chat posts. I have done this by generalizing and publishing the messages as blog posts, to a newsletter, or even to a google sheet. But this is additional work that may not be done regularly, or at all.

Side note: for some communities, discussing current events or just chatting with friends, this is actually a feature, not a bug. Who needs to remember who said what six months ago when conversing with friends.

But for developer communities, friendly chat is important, but so is sharing knowledge; the memory hole actively thwarts the latter.

Forums, on the other hand, are optimized for reading. nodebb even suggests related posts as you begin a topic, actively directing people to older posts that may solve their issue without them ever posting.

And if published on the internet, forums are searched via Google.

Problem #2: Google can’t see inside chats

Google is the primary user interface for knowledge gathering among developers.

I hope this statement isn’t controversial. It is based on personal experience and observation, but there’s also some research.

I have seen many many developers use Google as soon as they are confronted by a problem. Youtube, books, going to a specific site and using that search: these all are far less used alternatives when a developer has a question.

Google has made it so easy to find so much good information that most developers have been trained when they face a problem to open a new tab, type in the search term and trust the first page of results.

Chat systems don’t work well with this common workflow, because all the content is hidden.

This means when you use a chat for a developer community, you don’t get compounding benefits when someone, either a team member or a community member, answers a question well or has an insightful comment that would be worth reading. Very few folks ever benefit in the future.

With chat, people who aren’t present at message posting or soon thereafter never learn from that knowledge.

Problem #3: synchronous communication is synchronous

When you are in a chat system, the information is ephemeral. This means that valuable comments can be lost if there is a flurry of other messages.

People can feel ignored even though the reality is that they just posted at an inopportune moment. This feeling can be intimidating; I’ve definitely felt miffed as a question or comment I posted was ignored or unseen and other people’s questions were answered. “Was it me? My topic? Are other people more welcome here than I am?”

People who like to answer questions may feel the need to do so quickly. This may interfere with time for deep work. The Pavlovian response is real; I’ve felt it myself. It feels “better” to write a response to help someone than it does to write a document that will help many, because the former is so concrete and immediate.

When you pick a chat solution, you are optimizing for this kind of response.

Problem #4: less capable moderation tools

Forums have been around a long time. It’s a well understood problem space. There’s a rich set of functionality in most of them for handling the more frustrating aspects of online community management (see also “A Group is its own worst enemy”).

Chat applications have uneven support for this aspect of community management; I have heard Discord is pretty good, but Slack is not.

Remember that when you are running a community, you will inevitably attract trolls and spammers. Make sure you have the tools to protect the community from abuse.

In addition, make sure you have the time/energy. The community may be able to police itself when it gets to a certain size, but initially and for a long while, with a chat solution you may need to be ready to jump in and moderate.

Forums still require attention, don’t get me wrong, but the tooling and the separation of topics means they aren’t quite as vulnerable. They are a higher value target, because of Google, however.

Problem #5: you’re missing out on long tail content

This issue is related to problem #2, but slightly different. When you are building developer tools, there is a wide surface area of support needed. Questions from developers help define that space. When they go to a chat, someone needs to capture the questions and make them public to help future developers. You can capture this knowledge in formal docs.

When using a forum, the answers are made available to the long tail of searchers without any effort at all. A company I worked for got about 5-6% of their traffic from their forum pages.

That traffic was essentially free because the time to answer the questions was required with either solution. (This assumes the question would have been asked in either a chat or a forum.)

Problem #6: questions can be flippant

When I am talking in person to someone and they ask a question, I don’t expect them to have done a ton of research or thinking about it. It’s a conversation, after all.

The same attitude occurs during real time chat.

For technical questions, this can be frustrating because you want to help immediately (see problem #3) and yet you don’t have all the information you need. In async discussions, because they are async, more context is typically provided by the questioner.

This makes it easier for people who want to help to do so.

Why do people use Slack/Discord/etc?

Wow, so many problems with chat and all these reasons are why forum software is better.

So why do so many folks building developer communities choose solutions like Slack or Discord?

There are two motivations that I can see.

One from the company perspective and one from that of the developer.

From the company side: it helps build community between members.

I don’t know about you, but I am much more likely to pitch in and help when I have had a conversation with someone than if some rando drops by with a question and leaves.

A Slack can begin to feel like a real community, where you know people. It doesn’t feel as transactional when I see a question in a Slack when I’ve seen the questioner post other messages or share a bit about themselves. This type of interaction can happen in a forum, but seems more common in a Slack. This type of interaction makes the community more sticky and people more likely to help. A minor benefit is that chat can be hosted elsewhere for free so the startup cost and friction is low.

From the developer’s side: when I run into an issue or problem, I want an answer as soon as frickin’ possible. It’s blocking me, otherwise I wouldn’t have asked it.

Sure, I can context switch, but that has its own costs. So there’s tremendous value from a knowledge seeker’s side to pick a synchronous method of asking questions.

If you had a burning question to ask, which would you prefer? Hopping on the phone or sending a physical email. That’s the allure of the chat platforms.

I will say that some forum software has built chat in, but that isn’t going to get you an answer immediately.

What’s right for you?

Well, what do you want to emphasize? Long term aggregation of knowledge and a culture of completeness, or community and a culture of immediacy.

As alluded to initially, you can of course use both tools at different times in your community’s evolution. I think the longer you build, the more you’ll move to a forum or other public knowledge sharing solution.

Here’s a tweet survey that I ran a month ago asking how developers wanted to get tech help. (Something else turned out to mostly be “well written documentation”, from the thread responses.)

 



© Moore Consulting, 2003-2021 | Twitter