Getting started and onboarding#
This is a short guide for welcoming new team members to the 2i2c team. Its goal is to give newcomers an idea for where to look for information and how to familiarize themselves with our structure and processes.
Don’t try to learn all of this at once!
2i2c is a distributed organization, which means that we rely heavily on documentation. Don’t worry about figuring it all out immediately - this guide will try to focus on the most important parts to get started.
As with many things at 2i2c, our onboarding process involves a lot of documentation as well as asynchronous communication with other team members. Here’s a rough breakdown of the process:
An onboarding champion will help welcome you and assist you through the process.
You should get the right accounts and access to be able to start working with our team.
You should read about our approach to documentation so that you know what to expect and where to find information.
You should read about about our workflows to be able to start working with us.
To-do for the hiring manager
The hiring manager that led somebody’s hire is in charge of setting up the onboarding process for them. These are the steps that you need to follow:
Identify an Onboarding Champion. This is somebody that will help guide the onboarding process for our new team member. Their job is to carry out the process described in the onboarding issue template.
Open an onboarding issue in the Team Compass. This issue will track the onboarding process, and serves as the Source of Truth for steps to take in order to onboard a new team member.
Get an onboarding champion#
You should have an onboarding champion that will help you navigate the onboarding process. Feel free to ask them any questions that may come up, especially if something is unclear or under-documented. We usually improve our onboarding documentation while onboarding a new team member.
For the 2i2c hiring manager
The hiring manager that led the new hire is in charge of finding an onboarding champion for the new team member. Reach out to them if you’re not sure who is your onboarding champion.
Get access to the right accounts#
Our documentation structure#
Documentation is very important to 2i2c, because it is the way that we share information across our asynchronous and distributed team. Anything worth sharing once is worth documenting for all.
Our documentation all uses the same set of tools, which all team members need to be familiar with.
See our documentation guide for an overview of our documentation workflow and our major sources of documentation.
How our team compass is organized#
Our team compass is the source of truth for all of our practices. It is roughly divided into three sections:
Organization-wide sections cover information about 2i2c itself. They are generally managed by our
Executive Director.Functional areas focus on particular aspects of our operation, and are usually managed by a functional lead.
Managed JupyterHub Service is a special section that has a lot of cross-area documentation focused around our hub service. It’s in a dedicated section because it doesn’t really belong in any one functional area.
Reference documentation is a place to collect many pieces of information in one place, and for extra documentation that is useful across the organization.
Sections of our Team Compass should roughly follow the same high-level structure. For example, most of our functional areas have a “Structure” section that describes their roles and team structure, as well as a “Workflow” section that describes their workings in more detail.
Where to learn about our workflow#
As a distributed team, we have a few practices that are geared towards keeping everybody on the same page given that we’re in many different time zones. Here are the right places to learn more about our workflow:
Our organization-wide section has an overview of our mission, structure, and strategy.
Our team operations section has an overview of our organization-wide practices and workflow.
Our types of meetings page describes the kinds of meetings we have across 2i2c. Different teams each interpret these in a different way, but this covers the basics.
Beyond these, your workflow will likely depend on the functional area where you work. For example, the engineering team tends to work heavily on GitHub and uses many GitHub Issues tickets to track its work.