Open discussion: helping breakout groups make onboarding less stressful

Yeah, I totally appreciated the boundary they were setting there--as a group leader, I heard, "we're working on stuff and need to move forward tonight." And then a bunch of new people came to my group, and while I got zero done, personally, new folks volunteered themselves for pieces of what I had planned to work on.

I think the approach to meeting this need could use some tweaking. That announcement did not sound very welcoming, to my ears. And reading a pile of docs is not a very good experience (for many--some people find this to be a good entry point, I know).

I'll throw this idea out here before I have to log off for work: what if someone in a group took responsibility for sharing background info with new people?

We could offer groups several ideas and let them pick what works for their group.

In the registration form for the weekly meetings is there a link or message saying "click here to get familiar with breakout groups". Or could that be included in the confirmation email?

Yeah, I'm thinking that there's a balance that needs to be struck between groups being welcoming/fun and explaining key information to new people efficiently so work can progress. Having a point person in each breakout group responsible for onboarding new people is a good idea (and is probably used by a few teams already), but it seems like it's really up to the individual group and the availability on their team.

I think that the key problem here is that the cost to a group of welcoming a new person is relatively high, and the risk that the person might not show up again is also high. So the key to the solution here may be asking:

How do we make that cost seem lower?
How can we reduce the risk of people not showing up again after the group takes the time to welcome them?

What if we facilitated a "group onboarding" session immediately after Civic Tech 101? The idea here would be to encourage people interested in participating in groups to read documentation together and ask questions in a friendly environment that more new people can benefit from simultaneously. Ideally, this session would be led by one or two facilitators knowledgeable about some of the breakout groups and who would do their best to answer questions. Since new people would all be together as they are in 101, it would reduce the "cost" of onboarding to the individual breakout groups.

In doing this, we might also be able to figure out a way for new participants interested in groups to share a little bit about themselves at the end of the session so that breakout group leaders can plan for them to attend the following week. In addition to reducing risk of people not showing up (the "group onboarding" would try to get them to invest time in reading documentation, asking themselves if they're ready to contribute, and introducing themselves to breakout group leaders via email), this also satisfies a need that was identified in some research about Chi Hack Night that was done a few months ago but was more recently published about how breakout group leaders would like to know a little more about the skills and interests of their newest members: https://drive.google.com/drive/folders/0B9NynO8v_uIiSl93UFlfVWJFeEE

I'm happy to try facilitating this in another week or two if people think it's worthwhile, but would love to hear more thoughts first.

Also, I like Dan's idea about pushing people to check out the breakout groups after they register, seems like an easy little hack that will give our groups more visibility.

I like this idea - the issue would be that I'd have to somebody from each group that needs onboarding attend the 101. Since the session has a flexible ending time depending on questions, sometimes I can let people out in as little as 15 - and sometimes it's closer to 30. At minimum, they could come in right around 15 after once the breakouts get started and the timing might be better.

It's harder for me to answer questions about the breakouts myself because I'm always at the 101 and never go to any breakouts.

The way the Invisible Institute has dealt with this is having a point person for onboarding who explains everything. It's an exhausting job and not entirely satisfying for that person so we're working to replace them with an easy document (a manifesto, if you will). Still drafting but here's the sneak preview: https://docs.google.com/document/d/1ULmaceIT-1KIm8RBlpxaGP7ou2YoVEvX8CRurQ2bixo/edit

I think this also speaks to the larger question of imposing culture. ChiHackNight is open - groups get to pick what works for them which is awesome. However, there are places where standardization helps (like this). We should work to ensure that every group has some basic elements (a plan, an onboarding doc maybe? in addition to their Github issue) to make this curve easier.

A one-pager to introduce you to the group and their work is one thing. Expecting someone to read a whole bunch in order to work with you is another.

New people, people who are new to an issue or topic, a rotating cast of volunteers--these are the reality. Hack Night is a learning environment. It may be that we have some groups who would prefer to have less casual, less novice participation. It will help us support different types of groups better if we acknowledge those different preferences.

In general, tho, we'll do ourselves a service if we minimize jargon and acronyms, give a little background on whatever we are discussing at the moment, keep in mind the types of tasks that we can invite new people to take on, make quick introductions a habit (if you're working with a community partner, esp).

That said, people coming in 10 or 20 mins into a working session is rough. And so is digging through a pile of whatever the group has previously compiled in Slack and Google docs. Maybe a volunteer squad that spends a night with each group doing a version of Clean Sweep on their Google doc folders. :)

As far as introducing people to the group and topic in person, I think from now on I'm gonna keep the intro we have in Github for Access to Justice in mind as a general elevator pitch, as well as an intro to the current project at hand, and then just leave it that. Have some tasks in mind newbies can jump in on, and let them jump in.

I love the onboarding doc Ben, thanks so much for sharing. I also really like your idea of the volunteer squad that spends a night with each group cleaning up Google doc folders, Kristi. It might be fun to have this as one of the things that the "How to Hack Night" group does. I'm up for making a pitch to groups to help them tonight with this if they need it.

Thanks, but I think you have the wrong Ben! Wasn't me.

Ben

Yep, I was thanking Ben Cooper! You should check out his group's onboarding doc, it's pretty awesome: https://docs.google.com/document/d/1ULmaceIT-1KIm8RBlpxaGP7ou2YoVEvX8CRurQ2bixo/edit

Ok so I'm starting a document on how, when and why to create an overview doc for your breakout group. Feedback, edits and suggestions welcome!

https://docs.google.com/document/d/1ax0mdFBDtoLCIsGOZ4zA2PMGMCfiOrc1Z0Pcv4Q7DIc/edit#