A community of technology community managers, leaders, and builders.

Barriers in communities can be good


A topic I am keen to discuss at CLS is about barriers in communities being a good thing.

Many communities try to make things as simple and effective as possible for new contributors to join, but the challenge with this is that often the quality of those contributors is low, and they need more “baby-sitting” than others. Sometimes putting up barriers can get a higher quality, more professional grade community member.

I would love to share this in more detail at CLS, and then kick off a discussion about:

  • Am I on crack or does this make sense?
  • What kind of barriers are good?
  • How do we avoid putting up the wrong kind of barriers.

Anyone interested in this?


Not crazy at all, I love it. What if we thought about it in terms of “friction” instead of barriers?

I’ve jotted some notes below from a few things I’ve written about before - is this the kind of thing you’re talking about, @jonobacon?

Our goal at Indy Hall is for somebody to go from door to sitting down and working as quickly as possible, with as few things to do/review as possible. That said, over the course of the day, needing to ask where the bathroom is, how to make a cup of coffee, etc, are social interactions that new members actually gain immense value from.

We look at every interaction carefully and determine if it’s valuable from a socialization perspective. If not, we try to automate. If it is, we work to preserve it (even if it’s more difficult than the streamlined alternative). That friction creates opportunities for people to share experiences. That’s the value we provide.

Also, this piece that connects some dots between analog and digital process in the music production world, and the kind of work we do.


The problem we have with room scheduling tools is that they create an interaction that commoditizes the use of space in favor an efficient transaction rather than an interaction between humans that could yield unrealized or under-realized value.

In our case, scheduling a conference room is as simple as sending an email or better yet, speaking to one of our team members about marking the space off as yours for a session. This subtle difference creates just a little bit of friction that allows for a conversation, no matter how brief, between the member and the person now responsible for their reservation. What happens next could still be nothing, but we’ve made sure that potential hasn’t been extracted before it has a chance to be realized, prematurely optimized for a short-term gain in efficiency.

Don’t throw the baby out with the bathwater

When intentionally decreasing the efficiency of a workflow, you need to look closely at what you’re drecreasing. It’s easy to become dogmatic about a purpose, and ignore the practicality of what you’re trying to accomplish.

Inefficiency does not mean being a martyr for your purpose.

Instead, the goal is to seek inefficiencies that make you more effective.

This means getting close to the problem that you’re actually trying to solve and often breaking it into smaller problems, rather than looking for one “fix-it-all” solution.

In our case, the choice is to prioritize our interaction with members ahead the use of space because we know the difference it makes in our experience as well as theirs. We look at each interaction individually and consider the value of keeping it “analog” versus making it more efficient. We’re careful to make sure that our sacrifices don’t put the business or the community at risk.

** Experience is a melody**

It should go without saying that this isn’t about reserving conference rooms. That’s just one choice, which alone isn’t responsible for the entirety of the Indy Hall experience.

In music, a melody is a succession of notes that the listener perceives as a cohesive experience.

It’s the many deliberate choices, like the notes being strung together and sometimes a library of analog gear and talented people operating it, that allow us to create unique experiences that can’t be duplicated with a plugin or a piece of software.


I’ve thought about this problem quite a bit early in my time at Meteor, especially since Meteor inherently has a beginner-friendly learning curve, and a lot of people were making their very first web apps.

The problem is not too many novices total, but the novice-to-expert ratio that makes sure people’s questions get answered at a reasonable rate.

The solution I preferred is doubling down on growing number of experts rather than dissuading novices in order to keep the ratio reasonable. Maybe ease up on the gas pedal a little bit on getting more beginners, but always keeping it welcoming to them. Everyone has to start somewhere.

For instance, at Devshop SF, our monthly miniconference, we have a co-working session where experts can answer questions in real life and help people get un-stuck on the app or package they’re working on. We even made an app for handling the question queue with the asker’s location so the answerer can easily find them.

Granted, this comes with the caveat that the contributions we’re talking about are like comparing apples and oranges. Most folks in the Meteor community are working on their own apps that use the framework, rather than hacking on the framework itself. And in the course of writing their apps, many of them produce packages that they put on Atmosphere. But my short answer is, I don’t really put up barriers. As long as I invest in getting more experts on board, the ratio will be just fine.


At OpenHatch we work to make a lot of beginner learning tasks into self-serve tasks. When simple repetitive stuff is poorly documented (or, ahem, not documented at all…) then it makes your experts feel like they aren’t making the best use of their time when they answer questions. When you compound that with “casting a wide net” and having only a few fish stick around, that can feel pretty inefficient.

I don’t think the barrier needs beefing up so much as the docs and the resources that can help a person help themselves. Another key thing that can lower the mileage on your experts is empowering people who were new last month to help the folks who are new today. Honestly, they probably have a better recollection of some of the things your super-new person is struggling with anyway.


I like “friction” as Alex said. Otherwise, I agree too, this can be positive.

I think the ideal is to be intentional. There’s friction you put in place in order to mediate and build a positive culture (such as things that discourage rudeness), and then there’s friction that exists because you haven’t addressed it. We don’t want to make excuses for friction. I think every bit of friction should be questioned, but we shouldn’t assume all friction is bad.

EDIT: just thought of a great concrete example: forced previews. I am sympathetic to systems that make you preview a comment before you finally submit. It can lead to a sort of preview-blindness in worst cases, but I think it probably catches a decent amount of things where people post something and later feel they could have said it a little better…

Thanks to for being the kind sponsor for this forum!