chapter2.md

#Chapter 2

##What is On-boarding and Off-boarding?

On-boarding is how you get new team members up to speed with what the team is working on and what happens in the position. Off-boarding specifically deals with the documentation that one writes up before they leave a job and can help a new person on the team with understanding the ins and outs of their job. There are two checklists included here which include general practices for these processes. Please note: these processes will differ by size of the newsroom. I've broken this Gitbook into chapters, so you can find the chapter related specifically to the size of your newsroom (small, medium, large).

On-boarding: the process of getting someone acquainted with the day-to-day systems, projects, and people in a job they may experience or work on (ex: providing them with documents or information they may need while working)

Off-boarding: the documentation that one writes up, as well as any process that one goes through (ex: handing off projects or sources) when they leave a job

##On-boarding

On-boarding processes can/should differ by the size of the newsroom and the size of a team. Typically, there is an process that is done by human resources (HR), but there should be a process in place for the team members to help the new team member understand the ins and outs of the job.

For on-boarding, this process can include a number of things which I've included in a checklist here. This is by no means comprehensive, but it includes many of the things that people I surveyed often use in their on-boarding processes. The reporters, editors and developers I spoke to told me this checklist is often split up into weeks. For example, in the first week, one might have meetings set up with people on the team and key people that the person might work with. It's also helpful if the new person has a mentor or a guide who is there in case the person has questions and can help walk the person through the prior person's documentation or the documents the team put together for the new person.

Respondents to the survey also mentioned that the word "on-boarding" suggests it's only something that is done in the first week or so when the person starts the job, when it's actually a process that should be more than a few weeks. Documentation should be iterated throughout one's job.

If it's a new position in the newsroom and there isn't any documentation for the people who held the position before, the editor of the team can still create a small guide outlining what the expectations and common documents/sources are. This can be the jumping off point for the rest of the documentation that the person will write while they are in this position.

This process can also be used when someone is brought in temporarily, for example when someone is on maternity leave or goes on sabbatical. In these situations, it's important to have the contacts up to date for the person leaving and make sure they thoroughly write down their day-to-day duties as this will be a reference for the next person. It can also be helpful to have documentation written for remote workers and show them how you can support them.

Documenting these processes can also help with thinking through the weaknesses of the newsroom. If you have an on-boarding process and people feel acquainted with the flow of the newsroom, then you know that your documentation is thorough. If you have a process, but people struggle with reading through the documents and it's a huge pain to get people to actually write down things, then maybe it's time to rethink your strategies.

Another recommendation that was made which isn't necessarily something that one might think of is city recommendations. When a person moves to a new city for their job, it can be hard to navigate around the city and find good lunch places or have a good understanding of the layout of the area surrounding the office. An easy thing to do for this would be to make a Google map and drop pins on places that the team or newsroom often goes to for lunch and some important transportation points (ex: train or bus).

In general, documents should live in a central location. A good place for this would be a newsroom internal Wiki or a folder on a central server. In some cases, such as CMS training or other newsroom processes that people need to get trained on, it might be helpful to have documentation with screenshots of what the screen in the CMS or other software looks like in every step of the process. Alternatively, one may also have a video to train people.

##Off-boarding

Similar to on-boarding, this process can differ by newsroom and teams depending on their size. In general, it is important that the person who leaves the newsroom documents major projects they worked on. They should also go through the documents they started with and add their comments and questions to these documents. For off-boarding, it would also be nice to have an exit interview with the team. This can be in a formal meeting to talk through what went well, what went wrong and will also give the team time to ask any questions that are lingering. Ideally, the process would begin in the month before the person leaves.

For daily or breaking news reporters, this can include writing up notes about sources they regularly contact, the process for filing stories and the process for getting video or photos taken for their stories and any notes about the job (for ex: expectations or other information that the next person should know).

For reporters working on longer term projects, this process can include: documentation of a sample timeline for bigger projects, the standard process for having meetings and filing these types of bigger investigations and any information on how the pitching process for these projects work. This person can also keep notes on any documents they receive and what they did with them and keep them all in one place, so that someone doesn't have to submit a FOI for them later on. It might also be helpful to include a retrospective on projects including: what the impact of the project was, what went well in the project and what are some outstanding questions for future stories.

For developers/graphics reporters/data reporters, this process can include documentation of the data analysis and code (commented out), the process for filing/copy editing a graphic or a news app, questions or known issues for the project and general notes about the job. It's also helpful to have all the databases in one place (on a server or on Github). Similar to those working on longer-term projects, it might also be helpful to include notes on the retrospective of each project. Questions include: What went well in the project? What were some issues? What are some outstanding questions? What lessons did we learn? What are some opportunities for improvement?

##A Few Things to Note About Both Processes:

• People should be documenting their work as they go, so things don't pile up and forgotten.

• If you're working on a bigger project, have someone who knows what's going on. If you fall sick or are out of the office, they can pick up where you left off. Some people refer to this as the "bus factor" (in other words, document your projects well enough in case you get hit by a bus).

• If you have a question, write it down. When you learn the answer to that question, write that down too.

• For sources, write down any information that you know about the source or a public records officer. For example, if they can only be reached via phone or if they answer quicker by email. This can be helpful for yourself and for the next person in your position. I also would recommend writing down any personal information you learn about the person: for example, if they have a dog or children or went on a vacation. This can be helpful when you're following up via email or calling them to get information or need to set up an interview.