People that show up and do work on anything deserve two really important things in my opinion:
- A clear path to see all knowledge related to the work, and the freedom to consume it in a way that works for them, and,
- A clear path to pass the torch to someone else, and provide feedback to the rest of the group about their experiences as a contributor.
This post is more about the second item.
When I recently chimed in on a conversation about community on-boarding and mentioned off-boarding in the same sentence, it seemed novel to others and I think its worth explaining in meta terms.
When you think about joining a community, you have questions, right? Is it relevant? Is it safe? How much time will it occupy? What's it like to contribute? All of these neatly fit into structured on-boarding materials that can come in many forms.
But what about when you think about leaving a community? Don't you have questions then, too? Did you make a difference there? Did you reach a lot of people? Is there a way you can hand-off information others should know, or even ideas that you wished you could have explored more? This is structured off-boarding, and it's super important to have.
People sometimes stay way longer than their generosity just because they don't know what an exit would look like, so they keep putting it off. This is no less true in communities than it is in companies, and the toxicity it can cause is just as real.
People also deserve to be reminded of what their part is in something, not just when they're leaving, but especially when they leave. This inspires them to pass on knowledge that would otherwise be lost, and plant their ideas somewhere to grow rather than letting them eventually be forgotten.
Finally, what could have been better? If you're not surveying anonymously you're probably in danger of having your head in the sand and not even know it. You should at least have a well-conceived exit survey.
How this is implemented is going to depend vastly on the size of the community and goals of those that manage it, but at the minimum, you should have a way to show people how something is better for them having been there, and some place to not let knowledge leak, even if it's anonymous insight on how the community needs to grow.
This concept (structured off-boarding) is relatively new to engineering teams, and is gaining popularity among micro-service engineers that change teams frequently. However, the practice is no less wise for any kind of community, at least that I can think of :)
Top comments (0)