Onboarding
Project Management for TTRPGs
TL;DR: This post is a checklist of steps I used for Encounters in the Radiant Citadel to onboard collaborators. It includes a template for your first meeting and an example of the reading materials I gave collaborators.
This is part of a series on Project Management for TTRPGs. Stay up-to-date on this series by subscribing:
Getting People Excited
You’ve found creators interested in working with you! Now what? “Onboarding” is the act of familiarizing a new collaborator with how you run things and getting them set up to work. Whatever tone or impression you want folks to have about your project starts with onboarding.
For me, I want new collaborators to feel excited, supported, and connected with everyone else on the project. By “supported”, I mean that collaborators are clear on what they need to do, have all the information they need to do it well, and feel empowered to ask questions.
How you get people to “feel” a certain way about a project is partially leadership and soft skills—it’s the work environment and culture you set up. It’s helpful to reflect on what teams you’ve liked the most and what was true about those working environments. What did the folks in charge do? What was successful? What additional support could you have used?
Onboarding Checklist
With all that in mind, here is a checklist based on what I did for Encounters in the Radiant Citadel, with a few tweaks from learned experience. This is my current process for the type of team I want to work on and lead. It’s not one-size-fits-all but should be a good jumping-off point for your own team coordination:
First Contact: Reach out to someone to offer them a role on your team.
Video Call: Grab them for a 1:1 video call. Answer questions and share documentation.
Sign Something: Once the collaborator is 100% in, sign a basic agreement with them.
Shared Space: Create a shared space for folks to hang out, ask questions, and get updates.
Required/Suggested Reading: Document anything you want collaborators to read or know.
Introductions: Create ways for folks to meet one another.
1. First Contact
This was covered in the last post, Finding Collaborators When You’re New, which includes a sample email for reaching out to folks.
2. Video Call
In my humble opinion video calls are better than text in situations when:
There is an explanation or discussion needed: any situation where someone might have questions or need clarification.
It’s important to connect on an emotional, creative, or expressive level.
When someone has the basic details of your project and is interested, that’s a great time to grab them for a call. You’ll get a read on them as a person, express your excitement, and be able to answer and ask any questions. I grabbed everyone for a 1:1 video call early in the process for Encounters.
Have an Agenda
My one big tip: Have a plan for the meeting.
Folks hate meetings because they’ve been in a lot of bad ones: meetings that seem pointless, could have just been an email, or that drag on with no new information. Having an agenda combats this by forcing you to plan what information you need to share and what questions you need to ask. Using the same agenda ensures you’ll cover the same information for everyone. If you’re strapped for time, time out how long you plan to spend on each topic.
If you get along well and go off-topic, that’s totally fine. Vibing is great. But having a plan shows that you went into the meeting with some forethought so as to not waste your new collaborator’s time.
First Meeting Agenda Template
The agenda template above encourages you to do the following:
Repeat expectations: Everyone’s different, but some folks will inevitably skim whatever project documentation you provided. I had this happen in the middle of a call for Encounters. Having someone realize they don’t have time for your project or can’t complete an expectation stinks in the moment, but it’s so much better than coming to this realization in the middle of the project.
Express interest in who’s on the other side of the screen: I’m going to assume you care about your collaborators as creatives and as people (if you don’t then please don’t lead a project 😥). Asking what someone’s TTRPG goals are and why someone is interested in your project does a lot of things: It shows you care about this person and their work beyond this one project together. It gives you valuable information about what someone’s strengths and motivations are. Other things that express care proactively: asking folks if they need any scheduling or communication accommodations for working on your project. It’s possible you can’t make those scheduling or communication accommodations, but they’re good to know. Simply asking folks if they have questions encourages them to communicate when they’re confused or worried.
Take notes: When asking question, make sure to record the answers. I just copied the same agenda nine times and took notes as I was talking (or right after the end of the meeting if typing was getting too distracting).
3. Sign Something
Always have some sort of contract “signing” process before any work starts on your project. This can be done via:
A Google Form (which is what we did for Encounters)
A clearly worded email, acknowledged by both parties
A Google document that you both digitally sign
I am not a lawyer, and this is not legal advice, but multiple freelancers have told me that a clearly worded email, where both parties agree to the terms, is permissible in court if Eldritch entities forbid you ever end up in a licensing/ownership/money dispute.
For me, a contract is less about imagining a lawyer waving my Google Form around in court. Instead, I like contracts because human memory (my own included) can be iffy and at the very least it makes sure that everyone is on the same page about expectations and compensation. As someone who’s now doing freelance work, I always ask for a contract. It belays a level of professionalism and seriousness to have one.
Agreement Wording
Below is an example of language I’ve used on an agreement. Again, I am not a lawyer and none of this is legal advice. To create my sign-on agreement, I took the Roles and Responsibilities from my project plan and turned each one into a question in a Google Form that collaborators agreed to. Here is an example question:
Writing Commitment: I will pitch 5 encounter ideas, write an outline, and write a 500-750 word encounter that takes place in the Radiant Citadel. I agree to complete these tasks no later than the dates indicated on the Milestone Schedule. If I require an extension, I understand that I can request one from the Project Manager ahead of time.
And this is what it looked like in the Encounters Collaboration Agreement form:
Include your Code of Conduct in whatever document you sign, especially if you’re creating a team of collaborators that will interact with one another. If you’re wondering what a Code of Conduct is, see here.
For artists, I recently signed a commission contract based on the wording from this website: https://artpact.artisfy.com/Contracts/
4. Shared Space
You should answer and set up two things for your project:
Where will collaborators congregate to ask questions, chat, and get announcements? Discord is popular, but you could use Slack, or do everything via an email listserv. If everyone lives nearby, you could meet in a living room. Regardless of what you pick, you should have some space where folks can communicate with one another.
Where and how will collaborators access documents and files? We used Google Drive and Google Documents/Sheets for Encounters. I also used google groups to manage permissions, which is a process I’ll talk about in a future post.
Once a collaborator has officially signed on to your project, you should give them access to wherever you’re congregating and access to where you’re uploading and working on documents. For example, this might involve sending a Discord link and sharing a Google Drive folder.
5. Required/Suggested Reading
If there are documents or other “setup” steps that collaborators need to do to start work, put those steps in a list and give that list to collaborators. This might include source material collaborators should read or tutorials or articles that will help them get up to speed on some aspect of adventure design, writing style, or technology usage.
For Encounters, I had just read through Journeys through the Radiant Citadel and knew that collaborators would need to do some reading before they could get started writing. Here’s an example version of the document I provided:
6. Introductions
Figure out how to introduce folks to each other, especially if they’ll be working closely together. It can be a little awkward to be plopped in a Discord channel without any further context.
Lessons learned: I was a little shy about requiring that folks share information about themselves and do introductions. One of the pieces of feedback I got was that folks didn’t feel fully connected.
Here are a few ideas:
Have everyone provide or share a bio about themselves. Giving folks a format helps. We did this for Encounters: I had a Google document where folks could post a little bio about themselves with a picture.
If you’re on a Discord server (or something similar) tell folks to change their displayed Discord name to their name (as opposed to a screen name). If you’ve got different job roles, you can also tell folks to add what they’re working on.
Get everyone on a video call and do a kick-off. This is my plan for future projects.
Offer to optionally organize a D&D one-shot for folks to play together – I’d never make this “required” for collaborators, but I think D&D (and other roleplaying games) are a great way to build rapport.
Providing a way for folks to introduce themselves is a small thing you can do as a leader to make folks feel like they are on a team, that they know each other, and that they are safe to creatively collaborate.
Final Thoughts
Onboarding can easily get more or less complicated than the steps above. For a few of my full-time jobs, we’d have new engineers spend months onboarding and getting used to the team and technologies. I’ve always liked developing onboarding processes because it’s about investing in others and inclusion—it’s about teaching someone new how to be a part of your team and it’s welcoming someone to your team. Feeling welcome and having the information needed to succeed is especially important for anyone new to an industry. It’ll be good for your collaborators, and that’s good for you and your project too. So even if the steps above aren’t exactly what you need for your project and your team, I hope I’ve provided some inspiration and ideas that you can work off of.
Game and Life Updates
As mentioned, most of May was spent in Japan with the family. For long-time readers: My last day in Japan involved running around Tokyo, looking for a cheesy tanuki statue as an Out of Luck momento:
Here are a few more nerdy pictures from Japan:
I’ve also been hard at work on Jukebox: A Musical Roleplaying Game version 2—my karaoke TTRPG that is an homage to Broadway and stage musicals. If all goes as expected, it’ll go to Kickstarter in October. In addition to finishing up Project Management for TTRPGs, I plan to start posting a dev log about Jukebox. The idea with this series is to journal about crowdfunding and hopefully 🤞🤞🤞🤞🤞 printing my first zine-sized TTRPG.
Expect more soon and thanks for reading!
A huge thank you to Tamara Grasty for editing!
Over and out,
- 🫙 👁️ 👁️