Why not create a StaffEng Slack or Discord?

I’m in the process of releasing Staff Engineer, and a really great question I’ve gotten a few times recently has been, “Are you planning to create a Slack or Discord server focused on creating a Staff-plus engineering community?”

The answer is no, but the longer answer is more interesting.

One of my focuses last year was learning more about creating new communities, and towards that end I did two experiments in community creation. In January, I created a handful of CTO/VPE/Staff Engineer learning circles, and then later in September I launched the TechWriters Discord, partnering with Gergely Orosz.

These are very different communities, and I learned a bunch from both, which I’ll summarize here to the extent that it relates to not creating a Staff-plus engineering community.

• Great communities have curated membership. This is probably a controversial belief, but the best communities I’ve participated in are heavily curated. A great community has folks with a significant degree of shared norms, values, and purpose. A good “code of conduct” raises the floor on how folks engage, but curating members moves you off the floor entirely. The learning circle that I lead is still running a year later, and has been a joy precisely because the people in it mesh together well.
• _Public and semi-public communities revert to the mean. _Many public and semi-public communities start out as wonderful places, but as the number of participants grow, they tend to lose that initial spark as the community grows. The distribution of your experiences within the community become wider and wider, even if everyone engaged is well-meaning and constructive.
• Activity-oriented communities remain healthy longer than identity-oriented communities. The TechWriters discord is a community of folks who are doing-the-work of writing and publishing online. Participation in the community is mostly predicated on folks who are actively creating new works. When folks are doing less writing/publishing, they tend to disengage for a bit, coming back when they are. This keeps the community focused around the shared activity of writing/publishing, rather than on the identity of being an author or writer. On the other hand, a “Staff-plus engineering” community would be more identity-oriented rather than activity-oriented, and in particular it would be oriented around a high-status identity. My experience with high-status, identity-driven communities is that the most active participants would be those with the highest confidence, rather than an even or representative sampling across the community. These aren’t inherently bad communities, but they’re not communities that I personally enjoy that much. Worse, the sorts of folks that I want to be in a community with tend to not enjoy them much either.

Putting that all together, I think a small, curated community of Staff-plus engineers would be a phenomenal community, but would necessarily exclude most folks who want to participate. On the other hand, a semi-public community would start out great but seems very likely to degrade over time as it grew. My goal with staffeng.com and Staff Engineer is to advance the industry’s conversation around Staff-plus engineering, and given my beliefs around these communities, I don’t think either of those outcomes would do much to that effect.

If you find that answer unsatisfactory and you still want a Staff-plus community, my first recommendation would be to start your own learning circle of Staff-plus engineers. If you’re still dissatisfied then I’ll end with this: if a group of folks are interested in launching and maintaining an inclusive community of Staff-plus engineers, I’d be more than glad to join and direct folks towards it, even if I’m uncertain of such a community working well long-term. (I think if you can find a way to require membership to require “doing work” then you could address most of my concerns.)